[vtkusers] Rendering performance
David Gobbi
david.gobbi at gmail.com
Wed Nov 24 18:55:30 EST 2010
Hi Gib,
Glad to hear the good news. I'm sure that you've also figured out that you
can use glyphs for your spheres.
Changing the number of glyphs is possible, but a bit tricky. You have to
re-initialize the input polydata when changing the number of points or
cells. So going back to my example code, you would do something like this:
input->Initialize();
input->SetPoints(new_points);
input->SetVerts(new_verts);
Generally you will have to re-build the points and the verts arrays from
scratch if you want to remove elements. You can call Initialize() on the
arrays to clear them before rebuilding them. The VTK arrays don't have an
erase() method like C++ vectors do.
David
On Wed, Nov 24, 2010 at 4:34 PM, Gib Bogle <g.bogle at auckland.ac.nz> wrote:
> Great success!! The glyphs render so fast that the extra time is
> negligible. Thanks again. It isn't needed for this application, but for
> future reference: is it possible to change the glypher input on the fly,
> i.e. the number of cells?
>
> Hi Fred, are you still interested in seeing the code that runs slowly?
>
>
> Gib
>
> On 25/11/2010 9:20 a.m., David Gobbi wrote:
>
>> Hi Gib,
>>
>> Even though a programmable source like that wiki example is probably the
>> "cleanest" way to do things, there is a simpler way to build a dataset for
>> vtkGlyph3D.
>>
>> The vtkGlyph3D filter needs two inputs: one input for the positions of
>> each
>> glyph (i.e. one point per glyph) and another input for the glyph shape
>> (i.e. the
>> square that you already made).
>>
>> The first input is just a list of points, you can build it as a polydata
>> just
>> like you did with the squares, except that you want to use "verts" as your
>> cells:
>>
>> vtkSmartPointer<vtkPoints> positions = vtkSmartPointer<vtkPoints>::New();
>> vtkSmartPointer<vtkCellArray> dummycells =
>> vtkSmartPointer<vtkCellArray>::New();
>> positions->SetNumberOfPoints(npos); // number of squares
>> dummycells->InsertNextCell(npos); // size of dummy "verts" array
>> for (int ipos = 0; ipos < npos; ipos++)
>> {
>> positions->SetPoint(ipos, x, y, z); // square positions set here
>> dummycells->InsertCellPoint(ipos);
>> }
>>
>> vtkSmartPointer<vtkPolyData> input = vtkSmartPointer<vtkPolyData>::New();
>> input->SetPoints(positions);
>> input->SetVerts(dummycells);
>>
>> vtkSmartPointer<vtkGlyph3D> glypher = vtkSmartPointer<vtkGlyph3D>::New();
>> glypher->SetInput(input);
>> glypher->SetSource(polygonPolyData);
>>
>> Then feed the output of the glypher into the mapper, and it will
>> automatically
>> draw a square at each position. To change the positions, you would do
>> this:
>>
>> positions->SetPoint(idx, x, y, z); // set point idx to (x,y,z)
>> glypher->Modified(); // tell glypher that the data has changed
>>
>> Then re-render, and the squares will be at their new positions. I have
>> not
>> tested the code above, but I've done similar things in the past.
>>
>> David
>>
>> On Wed, Nov 24, 2010 at 12:52 PM, Gib Bogle <g.bogle at auckland.ac.nz
>> <mailto:g.bogle at auckland.ac.nz>> wrote:
>>
>> Seb, if this is what you are referring to:
>> http://www.itk.org/Wiki/VTK/Java_Code_Samples
>> it might require skills a bit beyond my rather primitive level of C++
>> expertise.
>>
>>
>> Gib
>>
>> Quoting Sebastien Jourdain <sebastien.jourdain at kitware.com
>> <mailto:sebastien.jourdain at kitware.com>>:
>>
>>
>> You can use a single actor, you will need to have a programable
>> source
>> that update the output dataset that has the location of each center
>> of
>> the square.
>>
>> Pipeline: Actor(Mapper(Glyph(CustomSource, Square)))
>>
>> To change the position of a square, you can have something like
>> that...
>>
>> customSource.SetSquarePosition( suquareId, xyz )
>>
>> Seb
>>
>> PS: I think I wrote a sample code in Java for programmable source
>> on the
>> wiki...
>>
>>
>> On Wed, Nov 24, 2010 at 1:41 PM, Gib Bogle <
>> g.bogle at auckland.ac.nz
>> <mailto:g.bogle at auckland.ac.nz>> wrote:
>>
>> Hi Seb,
>>
>> Although I referred to a simplified case in which the squares
>> don't
>> change,
>> in general I need to allow for their movement. Therefore I
>> don't
>> think it
>> will be possible for me to use a single actor. If I'm wrong,
>> could you
>> please provide a bit more detail?
>>
>> Thanks
>> Gib
>>
>> Quoting Sebastien Jourdain <sebastien.jourdain at kitware.com
>> <mailto:sebastien.jourdain at kitware.com>>:
>>
>>
>> Hi Gib,
>>
>> My first question will be. Are you using one actor for each
>> of your
>> 10000 flat squares ?
>> If so, the performance limitation may come from the number
>> of actors
>> involved. One solution to that is to create only one
>> dataset
>> with all
>> the squares that has only one mapper and actor. To do so,
>> you can
>> build it by hand or simply use the Glyph filter with your
>> square
>> as a
>> glyph and another dataset that has the location of those
>> squares.
>>
>> Seb
>>
>>
>> On Wed, Nov 24, 2010 at 12:44 AM, Gib Bogle
>> <g.bogle at auckland.ac.nz <mailto:g.bogle at auckland.ac.nz>>
>>
>> wrote:
>>
>>
>> I asked about this before, but didn't attract any
>> responses.
>> I have a
>> better understanding of the issue now, so perhaps my
>> questions will make
>> more sense.
>>
>> At regular intervals as my simulation program executes,
>> I am
>> rendering a
>> scene that contains mainly about 1000 small spheres
>> (which
>> move) and
>> about
>> 10000 flat squares (which do not move). I have
>> discovered
>> that the
>> surprising slowness of the the rendering is caused by
>> the
>> squares, even
>> though the spheres have ThetaResolution and
>> PhiResolution
>> both equal to
>> 12,
>> which I guess means 144 faces per sphere, i.e. a total
>> of
>> 144,000 faces.
>> By
>> my calculations rendering the scene 288 times with
>> spheres
>> alone takes
>> about
>> 4 sec, with the squares alone takes about 20 sec, and
>> with
>> both spheres
>> and
>> squares about 24 sec. That is, 10,000 squares take 5
>> times
>> as long as
>> 1000
>> spheres with 144,000 faces.
>>
>> Apparently there's something very inefficient about the
>> way I am
>> rendering
>> the squares. Here is the code for tileMapper (which
>> makes
>> squares):
>>
>> // Create the square
>> // Setup points to draw a unit square in the XY plane,
>> at y=0
>> vtkSmartPointer<vtkPoints> points =
>> vtkSmartPointer<vtkPoints>::New();
>> vtkSmartPointer<vtkCellArray> vertices =
>> vtkSmartPointer<vtkCellArray>::New();
>> points->InsertNextPoint(-0.5, 0.0, -0.5);
>> points->InsertNextPoint( 0.5, 0.0, -0.5);
>> points->InsertNextPoint( 0.5, 0.0, 0.5);
>> points->InsertNextPoint(-0.5, 0.0, 0.5);
>>
>> vtkSmartPointer<vtkPolygon> polygon =
>> vtkSmartPointer<vtkPolygon>::New();
>> polygon->GetPointIds()->SetNumberOfIds(4); //make a
>> quad
>> polygon->GetPointIds()->SetId(0, 0);
>> polygon->GetPointIds()->SetId(1, 1);
>> polygon->GetPointIds()->SetId(2, 2);
>> polygon->GetPointIds()->SetId(3, 3);
>>
>> //Add the polygon to a list of polygons
>> vtkSmartPointer<vtkCellArray> polygons =
>> vtkSmartPointer<vtkCellArray>::New();
>> polygons->InsertNextCell(polygon);
>>
>> //Create a PolyData
>> vtkSmartPointer<vtkPolyData> polygonPolyData =
>> vtkSmartPointer<vtkPolyData>::New();
>> polygonPolyData->SetPoints(points);
>> polygonPolyData->SetPolys(polygons);
>>
>> //Create a mapper and actor
>> tileMapper = vtkPolyDataMapper::New();
>> tileMapper->SetInput(polygonPolyData);
>> tileMapper->ScalarVisibilityOff();
>>
>> The square actors are made like this:
>>
>> actor = vtkActor::New();
>> actor->SetMapper(tileMapper);
>> actor->GetProperty()->SetColor(boneColor);
>> actor->GetProperty()->SetAmbient(0.5);
>> actor->GetProperty()->SetDiffuse(0.2);
>> actor->GetProperty()->SetSpecular(0.5);
>> actor->SetPosition(pos);
>> ren->AddActor(actor);
>>
>> then not touched again (in the simulations I report
>> times for.)
>>
>> I'd be very grateful if someone could give me a clue as
>> to
>> what I'm doing
>> wrong to make the rendering so slow.
>>
>> Thanks
>> Gib
>> _______________________________________________
>> Powered by www.kitware.com <http://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
>>
>>
>>
>>
>>
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging
>> Program.
>> _______________________________________________
>> Powered by www.kitware.com <http://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
>>
>>
>>
>>
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>> _______________________________________________
>> Powered by www.kitware.com <http://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/20101124/a86efc24/attachment.htm>
More information about the vtkusers
mailing list