[osg-users] ViewerBase::frame() method slow after changing the color of a geometry

Robert Osfield robert.osfield at gmail.com
Fri Jul 21 02:33:27 PDT 2017

Hi Gianni,

As Lionel explains if you have display lists enabled (they are by default)
then rebuilding the display list will create a big cost.  Not using display
lists will avoid this one off cost, but it will increase the cost of
rendering on some drivers.

However, I would recommend you take a step back and learn a bit more what
you are expecting your computer to do with your dataset and how the
drivers/hardware will be handle the type of dataset you are working with.
>From what you describe of your data and how you are doing things you should
absolutely expect things to crawl along.  When you are dealling with big
data you need to be smarter how you deal with your data.

Your dataset is very heavy on vertices and triangles. The 3:1 ratio between
vertices and triangles suggest that no vertices are shared.  This itself
suggests that the dataset may well be poorly optimized as well - with this
size of dataset you should be doing everything you can to remove duplicates

The second observation I'd make is that with huge datasets modern
hardware/drivers perform far better when you break them down into small
chunks, so rather than a very small number of very large osg::Geometry, you
have a moderate number of moderately size osg::Geometry.  This will help
the OSG with culling and will help the graphics hardware handle this amount
of data far better.  Using VBO's instead of Display Lists will also provide
a big improvement.


On 21 July 2017 at 10:11, Gianni Ambrosio <g.ambrosio+osg at gmail.com> wrote:

> Hi All,
> I build a huge geometry (27 milion vertices, 9 milion triangles) as
> follows:
>         osg::Geometry* geometry = new osg::Geometry;
>         geometry->setDataVariance(osg::Object::DYNAMIC);
>         geometry->setVertexArray(buildVertices(count));
>         geometry->setColorArray(buildColors(count),
> osg::Array::BIND_PER_VERTEX);
>         geometry->addPrimitiveSet(buildElements(count));
> On mouse event, after getting an intersection with the graphics, I do:
>         osg::Geometry* geom = dynamic_cast<osg::Geometry*>(
> intersection.drawable.get());
>         osg::Vec4Array& color = dynamic_cast<osg::Vec4Array&>(
> *geom->getColorArray());
>         color[intersection.indexList[0]] = selectedColor;
>         color[intersection.indexList[1]] = selectedColor;
>         color[intersection.indexList[2]] = selectedColor;
>         geom->dirtyDisplayList();
>         color.dirty();
> The problem is that after these lines there is a delay of at least one
> second before seeing the triangle with the updated color on my 3D viewer.
> Debugging OSG code I found that "ViewerBase::frame()" is called twice
> before seeing the new color. Moreover the first time "frame()" is called
> "renderingTraversals()" takes a lot.
> I will debug the OSG code deeper but is there a way to prevent the delay I
> see in my application?
> You can find the full example in attachment.
> Thanks for your help,
> Gianni
> ------------------
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=71295#71295
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20170721/08ad096c/attachment.htm>

More information about the osg-users mailing list