Hi Robert,
> Thanks for the explanation. I don't think your needs are particular>
> different from most who are writing games/simulators with the OSG.> While
> large scenes LOD's is crucial, and for massive scenes Paging is> also
> crucial. The OSG supports both so should scale to larger scenes.>
Paging would require that all custom nodes we create is part of the IVE file
format. Inserting the custom nodes that we need is done as a pre-processing
step which result in an .ive file. Today we have to insert our custom nodes
post load. It it therefore nice if we can extend the IVE format. You told me in
an earlier mail that you are thinking about making the IVE format extendable.
Doing that would be a great thing at least for us. It would make it much easier
to implement and use custom nodes.
Is there currently (OSG 2.6) any way to extend the IVE format without doing the
implementation directly in OSG?
(We want to avoid that in order to make future OSG upgrades as easy to do as
possible.)
> The other approach you could take is having custom nodes or drawables> that
> wrap up a the whole rendering of a class of object, or a how> collection of
> objects. The later is something would suit> trees/forests.>
One of my future tasks is to combine large ammount of very simple trees into
one drawable. Our tree rendering does not require alpha-blending and thus not
depth sorting either, so we will most certainly gain a lot on both cull and
draw by combining this kind of geometry.
> These approaches would all reduce the number of objects in your scene> graph
> in memory and in the view frustum on each frame and thereby cut> the update,
> cull and draw dispatch costs. If your switch node helps> in keeping the
> number of objects down then thumbs up for it.>
I chosed the StateSetSwitchNode approach and not the LayerNode approach because
of the following reasons:
- It is much faster on initialization. (But, I am going to figure out why, and
maybe then we wont need it after all.)
- It is robust against node-visitors that has too many node-mask-bits turned on.
- It is easier to work with.
> W.r.t init time, typically this is pretty low. Shaders can be> expensive.
> Texture objects and drawables aren't typically too> expensive - the
> osgmemorytest example illustrate this.>
My understanding on shaders is that they are compiled at the time they are
needed to be used (runtime). If that is correct then I doubt that the shaders
would take a lot of time during OSG's initialization process. I only see this
initialization problem when working with the compositeViewer. Other viewers are
fast on init.
Viggo
_________________________________________________________________
Få Windows Live Messenger på mobilen.
http://windowslivemobile.msn.com/Homepage.aspx?lang=nb-no&ocid=30032
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
