[vtkusers] Moving an actor programmatically - performance issues

[David Gobbi]

Hi Richard,

Yes, using a single actor for the stationary object should definitely speed
things up, but I don't think you'd need to subclass vtkActor.

You should be able to append all the stationary data into just one or two
data objects (via vtkAppendPolyData) and display that data with one or two
actors (you can append data even if the data is not contiguous).  If there
are many repeated shapes, you can use vtkGlyph3D to do the replication.

I haven't used vtkAssembly much myself.

 - David


On Wed, Jan 13, 2016 at 4:24 PM, Richard Frank <rickfrank at me.com> wrote:

> Hi David,
> It seems like the culprit, upon further investigation, is that my
> stationary actor is actually an assembly of approximately 100 vtkOpenGL
> actors. This was the result of porting OpenGL code that rendered a
> complicated structure, and many of the pieces are not connected together,
> but need to be at being as "one".
> Each actor is either a triangle Strip surface or a spline. The number of
> triangles aren't that many on each surface. However as I move the movable
> actor across the screen what would cause or not cause the entire assembly
> to redraw? For example if I add a clip box widget to the assembly the
> performance of that seems "real time" but when I move my small Actor across
> the rendering seems slower. It's clearly the stationary actor because when
> I make it invisible the movable actor is "real time". I'm using VTK 6.3. We
> did try seven but it crashed and we're on a tight deadline so were using
> the older render code. I have a quadro K 5200 and a quadro m5000 so plenty
> of juice. Immediate mode is off. I tried changing the opacity of the
> stationary actor but that had no impact.
>
> One idea I have is to subclass VTK actor for this stationary model. With
> that make sense? This single actor would be rendering all the pieces rather
> than multiple actors rendering each piece.
>
> Thanks for any suggestions!
>
>
> Rick Frank
>
> On Jan 13, 2016, at 5:47 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>
> Hi Richard,
>
> Does your OpenGL implementation do anything special to "clip out" the
> stationary data?
>
> I'm wondering whether the slowness is due to 1) the time taken to load the
> data onto the GPU or 2) the time taken for the GPU to render the polygons
> after they're in GPU memory.  I'm assuming that both VTK and your OpenGL
> implementation do #2 on every render, since that is typical.
>
> VTK only reloads data onto the GPU when the data changes, but if something
> goes wrong and static data is re-loaded on every render, there is a huge
> performance hit.  I believe that VTK's new OpenGL2 backend temporarily had
> some issues with unnecessarily reloading data, but those issues were fixed
> for VTK 7.0.0.rc1.  Are you using the OpenGL2 back end?  And what version
> of VTK?
>
> The vtkActor::Render() method should only be called by VTK itself.
> Applications call vtkRenderWindow::Render().
>
>  - David
>
>
> On Tue, Jan 12, 2016 at 9:32 PM, Richard Frank <rickfrank at me.com> wrote:
>
>>
>> Hi,
>>
>> We are moving a small arrow actor around 3D space driven by data from a
>> sensor, with another somewhat dense polygon model held stationary. We are
>> moving the actor with setusertransform.
>>
>> We are only getting about 10 fps. An OpenGL implementation with the same
>> data gets 50fps.
>>
>> What might we be doing wrong? It seems that the call to
>> renderwindow->Render() is just drawing everything without clipping out data
>> that doesn't need to be updated.....
>>
>> Also, what is the vtkActor::Render() method for? It seems to perform all
>> the OpenGL calls but at the end nothing is drawn on the screen. Is that
>> only to be called from within renderwindow->Render()?
>>
>> Our code uses a timer to read the data from the sensor, and parse the
>> data, and then move the actor.
>>
>> Thanks,
>>
>> Rick
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160113/7a2075e5/attachment.html>