[Paraview] Re: Even more Questions about ParaView on a Tiled Display

Mon Aug 7 18:05:02 EDT 2006

The default composite mode of IceT is to composite using z-buffer
comparisons.  Because nothing is written to the z-buffer when rendering
transparent geometry or volumes, the z-buffer comparisons are invalid.

New with ParaView 2.4, there is a view option to perform "ordered
compositing."  When you do that, ParaView will, under the covers,
redistribute your data (yet again) very carefully so that IceT can
perform a front-to-back color blending compositing.  Note, however, that
there is a pretty high overhead for redistributing your data if you are
planning to make a lot of changes to your pipeline.  Also note that
there is a bug in the way OpenGL blends the alpha channel that makes the
blending incorrect (Bug #2347), but at least it is visible.

-Ken

________________________________

From: paraview-bounces+kmorel=sandia.gov at paraview.org
[mailto:paraview-bounces+kmorel=sandia.gov at paraview.org] On Behalf Of
Randall Hand
Sent: Monday, August 07, 2006 2:31 PM
To: Paraview List
Subject: [Paraview] Re: Even more Questions about ParaView on a Tiled
Display

Oh, I almost forgot this one..

#5: Is there a known problem with Opacity & IceT?  I tried setting one
of the isosurfaces at 50% transparent, but it simply vanished.  Where it
overlapped with the other (fully opaque) surface it could be seen, but
the rest of the area was blank. 

I saw a similar effect with attempting to Volume Render a different
dataset.  I could see the volume effects where they intersected solid
polygonal geometry (bounding box, etc) but nowhere else.

On 8/7/06, Randall Hand <randall.hand at gmail.com> wrote:

Ok, so I've got my Mullions code (still looking for any comments about
that) working on our RenderWall and I'm noticing some interesting
behaviour that i've got some questions about.

In this cluster, we have 12 nodes + 1 head node, each one connected via
a GeForce 7800GTX to a 1600x1200 LCD Display.  Each node has 2
single-core Xeon processors Hyperthreaded, for an "effective" 4 cores,
and 8G of ram.  All connected via Infiniband.  I've loaded up 2 PVTP
datasets:  
   a) Dataset A is a 52Million Triangle 24-part surface, RGB per point
   b) Dataset B is a 67Million Triangle 12-part surface, no data per
point (Geometry only)

(Both datasets were load-balanced with Paraview's D3 filter.) 

Now when I load them in Paraview, with a Tiled Display, they both load
and I'm able to interact with them beautifully.  119Million Triangles
rendered in 1s (for a still frame).  I applied a cutting plane to one of
them, and then another D3 (to balance the newly cut surface, right?),
and the results are still fabulously interactive.  But a few things i've
noticed: 
1) Even tho the results are now "load balanced" again (via the D3), my
memory usage is still fairly varying.  I'm seeing numbers ranging from
1.8G to 3.8G on various nodes.  Is this because the memory isn't really
freed-up from the Cut operation? 
2) One of my 12 nodes is basically "idle".  While the other 11 nodes
show runtimes of over 250minutes on the pvserver process, one node shows
less than 5.  Images are visible on all 12 displays.
3) On every node I have 3 processes.  4 I would understand, and 1 I had
expected.  But 3?  It seems one is for the Rendering & MPI work, while
the other 2 are for computations (one has the usual spinlock runtime of
250+minutes, while the others have 0.00).

An example:

[rhand at plasma proc]$ pdsh -a top -b -n1 | grep pvserver | sort
plasma01ib: 18580 rhand     25   0 1969M 1.9G 21052 R    25.0 25.0
275:25   1 pvserver
plasma01ib: 18581 rhand     25   0 1969M 1.9G 21052 S     0.0 25.0
0:00   3 pvserver
plasma01ib: 18582 rhand     25   0 1969M 1.9G 21052 S     0.0 25.0
0:00   3 pvserver
plasma02ib: 18367 rhand     25   0 1926M 1.9G 21052 R    25.0 24.5
275:22   1 pvserver 
plasma02ib: 18368 rhand     25   0 1926M 1.9G 21052 S     0.0 24.5
0:00   0 pvserver
plasma02ib: 18369 rhand     25   0 1926M 1.9G 21052 S     0.0 24.5
0:00   0 pvserver
plasma03ib: 18407 rhand     25   0 3268M 3.2G 21052 R    25.2 41.7
275:20   1 pvserver
...(snip)...
plasma11ib: 20771 rhand     25   0 1997M 1.9G 21060 S     0.0 25.4
0:00   3 pvserver
plasma12ib: 18301 rhand     18   0 4161M 4.0G 21164 S     0.0 53.1
6:38   1 pvserver
plasma12ib: 18302 rhand     25   0 4161M 4.0G 21164 S     0.0 53.1
0:00   1 pvserver
plasma12ib: 18303 rhand     25   0 4161M 4.0G 21164 S     0.0 53.1
0:00   1 pvserver 

4) While interacting, the 2D Scalar Bar seems to resize/move down to the
display closest the origin (lower-left corner), and then return to it's
desired location when the full-res image is rendered again.  Is this a
glitch, or by design? 

So can someone explain to me a bit of what's going on "behind the
curtain"?  I've also had no luck chasing down what's going on with the
Slow Renderings &mangled options on tiled Displays (On the production
2.4.4 release, not my customized mullion-enabled one)

-- 
----------------------------------------
Randall Hand
Visualization Scientist
ERDC MSRC-ITL 

-- 
----------------------------------------
Randall Hand
Visualization Scientist
ERDC MSRC-ITL 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/paraview/attachments/20060807/f36f9d25/attachment.html