[vtkusers] Animation of multiple input files in VTK

[Tijmen Klein]

I currently have multiple vtkMarchingCubes, but with one mapper/actor. I
switch the input of the mapper, which is already a lot faster than switching
the input of the vtkMarchingCubes. There is still a noticable delay. Would
hiding/showing multiple actors remove this delay? A wouldn't this introduce
a lot of overhead?
When I load this sequence in Paraview, it is able to run very smoothly
(after the first run, which takes some time) while still allowing the user
to interact. Does anyone know how Paraview does this?

Tijmen

On Wed, Jul 6, 2011 at 5:46 PM, Shashwath T.R. <trshash at gmail.com> wrote:

> Why not have multiple vtkMarchingCubes instances - one for each input, and
> then multiple mapper/actor sets? You could select which one you want to work
> on, and make the rest invisible...
>
> Shash
>
>
> On Wed, Jul 6, 2011 at 4:37 PM, Tijmen Klein <T.R.Klein at student.rug.nl>wrote:
>
>> This is what I do. I set up the whole scene, load in all the different
>> readers, and connect the first reader to the vtkMarchingCubes. Then I use a
>> timer that calls an update function every second. This update function sets
>> the inputconnection of the vtkMarchingCubes to the current reader
>> (contours->setInputConnection(reader[current]->getOutputPort()). This is
>> working, but results in small (but very noticable) hickups in the
>> interaction. I think this is because the isosurfaces have to be
>> re-calculated every time. That's why I think that I will need an array of
>> vtkMarchingCubes too.
>>
>> Tijmen
>>
>>
>> On Wed, Jul 6, 2011 at 11:02 AM, Dominik Szczerba <dominik at itis.ethz.ch>wrote:
>>
>>> You should update your reader only from a callback function once you
>>> have your scene/camera/etc set up...
>>>
>>> Dominik
>>>
>>> On Wed, Jul 6, 2011 at 10:51 AM, Tijmen Klein <T.R.Klein at student.rug.nl>
>>> wrote:
>>> > Thank you for the reply. First of all, I'm not trying to export a
>>> animation;
>>> > it should be realtime and allowing the user to navigate the scene.
>>> >
>>> > I'm currently applying the fist technique (update the reader in a
>>> loop).
>>> > Technically this works fine, but it is really slow and also blocks the
>>> mean
>>> > thread of the program (the program simply freezes when switching
>>> between 2
>>> > frames). A possible solution that I came up with is the following:
>>> create N
>>> > pipelines (up to the mapper), where N is the number of frames. This
>>> mean I
>>> > can load the data first, create the isosurfaces and then based on the
>>> > current time let the actor point to the corresponding mapper. This
>>> would
>>> > mean that all the calculations are already completed.
>>> >
>>> > Is this a viable solution? It feels a bit hack-ish to do it like this.
>>> >
>>> > Tijmen
>>> >
>>> > On Tue, Jul 5, 2011 at 4:00 PM, Dominik Szczerba <dominik at itis.ethz.ch
>>> >
>>> > wrote:
>>> >>
>>> >> There are a few possibilities. The simplest would be to update the
>>> >> reader in a loop and dumping screen renderings. More sophisticated
>>> >> would be to import them first into a temporal dataset and then request
>>> >> a specific time value.
>>> >>
>>> >> Dominik
>>> >>
>>> >> On Tue, Jul 5, 2011 at 2:57 PM, Tijmen Klein <
>>> T.R.Klein at student.rug.nl>
>>> >> wrote:
>>> >> > I'm trying to animate multiple input files. These files are in the
>>> >> > legacy
>>> >> > VTK format (.vtk), and named filename[x].vtk, where [x] is an
>>> integer. A
>>> >> > contourfilter is used to generate isosurfaces, and these isosurfaces
>>> >> > should
>>> >> > be animated.
>>> >> >
>>> >> > This is behaviour that is quite easy to achieve in Paraview (open
>>> the
>>> >> > files,
>>> >> > apply contour filter, choose a frame or click play). How can
>>> something
>>> >> > similar be achieved in VTK? It should be possible to create a
>>> >> > time-dependent
>>> >> > animation, but also manually set the current frame. I thought of
>>> >> > creating
>>> >> > multiple InputReaders, and have the 'current' reader's outputport
>>> >> > connected
>>> >> > to the input port of the contour filter. But I think this would not
>>> be
>>> >> > very
>>> >> > efficient, since it's not possible to cache the results in this way.
>>> >> > This
>>> >> > would mean that all the calculations happen again when the
>>> animations
>>> >> > restarts from frame 1. What would be a better solution?
>>> >> >
>>> >> > Cheers,
>>> >> > Tijmen
>>> >> >
>>> >> > _______________________________________________
>>> >> > Powered by www.kitware.com
>>> >> >
>>> >> > Visit other Kitware open-source projects at
>>> >> > http://www.kitware.com/opensource/opensource.html
>>> >> >
>>> >> > Please keep messages on-topic and check the VTK FAQ at:
>>> >> > http://www.vtk.org/Wiki/VTK_FAQ
>>> >> >
>>> >> > Follow this link to subscribe/unsubscribe:
>>> >> > http://www.vtk.org/mailman/listinfo/vtkusers
>>> >> >
>>> >> >
>>> >
>>> >
>>>
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the VTK FAQ at:
>> http://www.vtk.org/Wiki/VTK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtkusers
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20110707/988ca34f/attachment.htm>