Am 22.07.2015 um 14:26 schrieb Trajce Nikolov NICK:
Hi Sebastian,
Yah, this is off topic now, but once here: re: trees, I am getting on
older card ~3 mil @ 60Hz with geometry shaders :-). Static though. Why
you are using Matrices in Image/Texture for vegetation, or you have
SpeedTree like vegetation?
I'm not doing billboards but instanced models(smallest have around 20
Vertices + normals + tex-coords) . So i need apart from ground color,
scale, index into an TextureArray (for diversity) and rotation some
position of course. A no I'm not using matrices but the angle of
rotation around my up vector.
Using billboards and geometry shaders your figures are of course
absolutly okay. I'll try the vertexDivisor if I have the time. I guess
for dynamic streaming it will outperform classical texture objects (I'll
have to test this for particle effects anyways)
But anyway, thanks for disabling resize/mipmaping .. not sure (getting
old :-)) can not recall if we did these for the instancing, but for
sure I will try it in the lighting system I am working on now ..
Thanks a bunch for these hints !
You're welcome.
Nick
On Wed, Jul 22, 2015 at 2:17 PM, Sebastian Messerschmidt
<sebastian.messerschm...@gmx.de
<mailto:sebastian.messerschm...@gmx.de>> wrote:
Am 22.07.2015 um 14:12 schrieb Trajce Nikolov NICK:
Hi Sebastian,
few months ago I tested something (was the lighting system)
implementation with updates via osg::Image and osg::Texture - not
related to instancing at all, but the mentioned method. My
colleague then did benchmarking and the update of the Image (and
the texture) by OSG was terribly slow - the same thing using raw
OpenGL calls out-performed the one from OSG. I also remember
Robert implemented then the Vertex Attribute Divisor wrapper for
OSG so it might really need example of these with various
techniques ...
Thats right for data dynamically changed via texture. Static data
is incredibly fast however (I'm talking ~1mio trees @30Hz min) .
Getting slightly off-topic here, but:
Are you sure you had resizing and mipmapping disabled for the
texture/image? That is certainly a performance killer.
Thanks for the ping :-)
Nick
On Wed, Jul 22, 2015 at 1:59 PM, Sebastian Messerschmidt
<sebastian.messerschm...@gmx.de
<mailto:sebastian.messerschm...@gmx.de>> wrote:
Hi Nick,
The implementation is almost to complicated. Using instancing
with osg::Image and a texture almost beats all other
implementations I've tested so far in terms of complexity and
performance.
Maybe we should some more examples for this to osg.
Cheers
Sebastian
Hi Luo,
have a look at this paper - it is OSG related with GL calls
(In the latest OSG release there are OSG wrappers for most
of them). It will help you with large number of instancing
and controlling each instance separately
http://3dcgtutorials.blogspot.com/2013/09/instancing-with-openscenegraph-part-ii.html
Hope it helps
Nick
On Wed, Jul 22, 2015 at 9:25 AM, Sebastian Messerschmidt
<sebastian.messerschm...@gmx.de
<mailto:sebastian.messerschm...@gmx.de>> wrote:
Hi,
Hi,
I need to use cylinder to simulate the “ladder”. So
there are many cylinder to create. I new a
osg::Geode , and then use it to new 10000
osg::MatrixTransform, all these osg::MatrixTransform
were added to one group.
But the program runs very very slow.
Are you testing in debug mode?
In fact I create the same scene using opengl, the
program runs quickly.
Are you using the osg::Shapedrawable for the cylinder
shape? Try to replace it with a simple triangle for
testing to see if the geometry or the transforms are
your bottleneck.
I'd use hw-instancing for this amount of copies of a
simple geometry or bake the transformations into big
geometries representing hundreds of cylinders each.
Also if the 10000 elements are spatially separable and
thus not all of them in the view at the same time you
should use some grouping to balance your scenegraph.
Simply putting 10000 transforms into one group most
likely will kill performance, as all children will have
to be traversed each frame.
How can I upgrade my program?
thanks.
Can you provide a more detailed description or an
example? Your question is too open to get you specific
answers.
Thank you!
Cheers,
LUO
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=64386#64386
Attachments:
http://forum.openscenegraph.org//files/mfc_osg_124.cpp
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
trajce nikolov nick
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
trajce nikolov nick
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
trajce nikolov nick
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org