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?
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 ! Nick On Wed, Jul 22, 2015 at 2:17 PM, Sebastian Messerschmidt < 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>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> 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 >>>> >>>> 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 >>> >> >> >> >> -- >> trajce nikolov nick >> >> >> _______________________________________________ >> osg-users mailing >> listosg-users@lists.openscenegraph.orghttp://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 >> >> > > > -- > trajce nikolov nick > > > _______________________________________________ > osg-users mailing > listosg-users@lists.openscenegraph.orghttp://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 > > -- trajce nikolov nick
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
