[vtkusers] time varying data speedups

[John Clyne]

Hi,

I'm trying to speed up an app that visualizes time-varying data by
trading off memory for cycles. Ideally, i'd like to do preprocess my tv
data as much as possible and store in RAM only the graphics primitives
and attributes representing each time step. Hence, after the
preprocessing was performed, rendering subsequent time steps in a time
evolution would only involve loading from RAM the geometry representing
the desired time step.

My basic "non-preprocessed" vtk pipeline looks like this:

	  sphere
		\
	reader -> glyph -> mapper -> actor

In the above config, loading a new timestep requires each node to 
execute - a process that's too expensive for interactive performance
with the data i'm using.


What i've attempted to do is represented in the diagram below. The 
intent is that each actor[0-n] holds data for time step i. Initially,
all but the actor representing the current time step have their visibility
turned off. Changing time steps simply requires turning on/off the 
appropriate actors visibility. Unfortunately, I haven't been able
to figure out how to force an actor to retain it's data once it has
loaded it from the upstream mapper during the preprocessing step. What
I speculate happens when I try to render is that the actor's update
themselves and loose the data they previously had.


				    actor0
				  / 
	  sphere
		\
	reader -> glyph -> mapper -> actor1
				 \
				  \
				    actorN



To address the update problem, I've taken the approach shown below: I
create a separate node of each type in the pipeline for each time
step.  This seems to achieve the desired result. I get a performance
increase of about 10x. However, there are two problems: 1) Each node
presumably stores a copy of its own data, making this approach a real
memory hog, and 2) If I load more than 50 or so time steps the
application is killed by the OS (Irix) to "prevent infinite loops". So
clearly some resource is being exhausted.


	reader0 -> glyph0 -> mapper0 -> actor0
	reader1 -> glyph1 -> mapper1 -> actor1
		.
		.
		.
	readerN -> glyphN -> mapperN -> actorN




So, any ideas on how I might make either of the above work? Is there
some other way to accomplish what I want to do?

Thanks for any pointers.


Regards,



John Clyne 	(clyne at ncar.ucar.edu)	
National Center for Atmospheric Research
P.O. Box 3000, Boulder, Colorado 80307	
(303) 497-1236	FAX (303) 497-1298