[vtkusers] Too many actors?

[Gib Bogle]

Dr. Gib Bogle
Senior Research Fellow
Auckland Bioengineering Institute
University of Auckland
New Zealand

http://www.bioeng.auckland.ac.nz

g.bogle at auckland.ac.nz
(64-9) 373-7599 Ext. 87030

On 2/11/2010 8:09 p.m., Gib Bogle wrote:
> I've run into a problem that probably implies that I'm doing something in a bad
> way. I'm repeatedly rendering a scene that has things that move, and things that
> don't. About 2000 small spheres move around. There is also a planar surface that
> is mostly unchanging, but because I need to be able to create dynamic eroded
> features on the surface, I represent it by a grid of square tiles.
> Interestingly, the problem I've encountered occurs when there is no erosion,
> i.e. when the grid of tiles is not changing from one render to the next. The
> program crashes after rendering the scene a variable number of times, typically
> about 300.
>
> The spheres are of course actors made with sphereMapper. If I turn off the
> rendering of the tiled surface the program runs correctly. I am also using
> actors for the tiles, made with my own tileMapper, which just makes a square
> using vtkPolygon, vtkPolyData and vtkPolyDataMapper. These actors are created
> and added to the renderwindow when the scene is rendered for the first time,
> then they are not touched again (in my simplified test case). The trouble is
> there are quite a few of them - 100x100 = 10000. If I halve the number, making
> the grid 50x100, the crash does not occur. If I suppress the sphere rendering
> the program still crashes.
>
> I guess I have two questions. What is the limit that is being exceeded and
> causing the crash (which occurs while iren->Render() is being executed)?
> Assuming that I have to reduce the number of actors, what would be a better
> method of handling the plane surface, given my need to make parts of it move to
> create depressions that grow?
>
> I'm using MSVC on Windows 7. The graphics card is ATI Radeon HD5400.
>

I probably didn't explain this clearly enough.  I have more info now.

Effectively my Qt program runs two threads.  One computes position info, then 
sends a signal to the main thread that uses QVTK to render the scene.  In my 
simplified test case the scene that is being rendered is unchanging, and has 
about 10,000 actors (my tiles).  When I said the program crashed I was being 
inaccurate.  Actually I get the hourglass, and a message that the program isn't 
responding, forever.  I've now ascertained that a small delay (sleep) in the 
thread that sends the signal to render the scene is sufficient to avoid the 
hangup.  It seems that for this case anything greater than 2 ms is enough (this 
is of course in addition to the computational time in that thread between these 
display events, which I haven't measured).  I'd be grateful if someone could 
explain to me what is happening here.  If it is a problem with a pipeline 
overfilling, is there a way to detect this, in other words, is there anything 
better than trial and error with sleep()?

If while the scenes are being rendered the mouse is used to zoom or rotate it, 
the same hangup can occur (not surprisingly).  I'd like to stop the user from 
being able to interact with the renderwindow while the execution progresses.  I 
have a "pause" button that freezes the action, which is fine, but I'd like a way 
to disable the QVTKwidget transformation capabilities when the program is not 
paused.  Is this possible?

Thanks
Gib