[vtkusers] Rendering performance
Sebastien Jourdain
sebastien.jourdain at kitware.com
Wed Nov 24 22:35:02 EST 2010
Hi Gib,
I'm glad that you managed to do it and that you solved your performance issue.
Seb
On Wed, Nov 24, 2010 at 7:45 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> The same input polydata that controls the positions of the glyphs can also
> control the color, size, and orientation of each glyph. This is done by
> calling input->GetPointData()->AddArray(...) to add scalar arrays that
> control the parameters. Look at the documentation for vtkGlyph3D for more
> info.
>
> David
>
> On Wed, Nov 24, 2010 at 5:37 PM, Gib Bogle <g.bogle at auckland.ac.nz> wrote:
>>
>> There is just one limitation (as far as I can see). One can't specify the
>> glyph colours individually. My spheres change colour as the state evolves.
>> I'd like to be able to control the square colours individually too, but
>> that's less important.
>>
>> Cheers
>> Gib
>>
>> On 25/11/2010 12:55 p.m., David Gobbi wrote:
>>>
>>> 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
>>> <mailto: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>
>>> <mailto: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>
>>> <mailto: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>
>>> <mailto: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>
>>> <mailto: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>
>>> <mailto: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>
>>> <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>
>>> <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>
>>> <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 <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
>
>
> _______________________________________________
> 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
>
>
More information about the vtkusers
mailing list