I just finished some more research and it seems that this glitch is not related to the Change I made.<br><br>I just reverted back to a standard 2.4.4 compile (Straight from Source downloaded from the website) and the problem persists. If I delete my .ParaViewrc, so I start fresh, then my 60+ million triangle dataset loads and renders a still frame in about 1 second (Across my 12-screen renderwall). Once I close/kill paraview and restart it, however, the Client Collect option has changed and rendering (No matter what I set it to) takes about 5 seconds. Looks like it's a legitimate bug in Paraview, or some strange glitch in our cluster. Any advice on tracing this down?
<br><br><div><span class="gmail_quote">On 8/4/06, <b class="gmail_sendername">Randall Hand</b> <<a href="mailto:randall.hand@gmail.com">randall.hand@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Attached to this email, find the diff patchfile of the Servers
directory (the only directory affected by this change). From my
testing here it seems to work great. Took a little while to get
the mullions computed correctly during the subsampled rendering, but it
seems to work now.<br>
<br>
The one issue I've been unable to figure out is that, for an unknown
reason, the Client Collect gets mangled when Mullions are
Enabled. I've looked all over the place and I can't figure out
how this parameter gets passed around. When starting paraview the
parameter is read correctly from the .ParaViewrc and properly used, but
when it's written back to the .ParaViewrc file it's mangled (Originally
it was writing it as 43676546, and now after a full recompile it's
writing it as 6, when both times it should be 100). Also, when it
comes in mangled like that, of course the first thing I do is reset it
to 100. Unfortunately, the rendering is significantly slower, as
if it's still computing the reduced geometry & transmitting it to
the client (Although the client does not render it). Manually
resetting the parameter in the .ParaViewrc & restarting paraview
fixed it (for that 1 run).<br>
<br>
Any ideas?</div><div><span class="e" id="q_10cdac9bc2a04bb0_1"><br><br><div><span class="gmail_quote">On 8/4/06, <b class="gmail_sendername">Randall Hand</b> <<a href="mailto:randall.hand@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
randall.hand@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Ok, with the info from Kenneth, I made the change and it's working great! <br>
<br>
So, how should I return this patch back to you? I just tried
doing a 'diff -Naur' to generate a patch for you, but it started
including almost every single file. Seems an "out of core" build
isn't completly "out of core" afterall. <br><br><div></div><div><span><span class="gmail_quote">On 7/28/06, <b class="gmail_sendername">kmorel</b> <<a href="mailto:kmorel@sandia.gov" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
kmorel@sandia.gov</a>> wrote:</span></span></div><div><span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> But is there any way to account for the Bezel width? Is there any<br>> configurable parameter to define a "gap" between tiles?<br><br>This request is already captured as bug #1132:<br><a href="http://www.paraview.org/Bug/bug.php?op=show&bugid=1132&pos=1" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://www.paraview.org/Bug/bug.php?op=show&bugid=1132&pos=1</a><br><br>This actually should not be too hard to implement since the underlying<br>parallel rendering code already supports mullions. It's just a matter of
<br>adding some new parameters to pvserver and spacing the tiles out<br>differently.<br><br>This bug has been on my to-do list for, gosh, over a year now. But, since<br>we rarely use tile displays anymore and the tile displays that we do have
<br>don't have any spaces or overlap, this has been the lowest priority and I<br>never get to it.<br><br>If someone would like to implement this (hint, hint) and make sure<br>everything (rendering and annotation) is working correctly, I am perfectly
<br>happy to point to the correct sections of code to change.<br><br>-Ken<br><br><br></blockquote></span></div><div></div><br><br clear="all"></div><div><span><br>-- <br>----------------------------------------
<br>Randall Hand<br>Visualization Scientist<br>
ERDC MSRC-ITL
</span></div></blockquote></div><br><br clear="all"><br>-- <br>----------------------------------------<br>Randall Hand<br>Visualization Scientist<br>ERDC MSRC-ITL
</span></div><br clear="all"></blockquote></div><br><br clear="all"><br>-- <br>----------------------------------------<br>Randall Hand<br>Visualization Scientist<br>ERDC MSRC-ITL