Hi Viggo, Unfortunately the .ive format just isn't extensible/nor forwards compatible. A new binary format replacement for it would take quite a bit of work so isn't something that can be easily added. Personally I'd like to have a single scheme for both the ascii and binary forms of serializing osg scene graphs. The amount of work this will require is not trivial so isn't something that can be addressed soon.
The .osg format is extensible so this is route right now for extensible serialization of the scene grpah. As for StateSetSwitchNode and Layer initialization costs, I would have expected the same StateSet representation would cost the same to initialize. I don't know how you've implemented either at your end so I just can't say why their may be differences. W.r.t CompsiteViewer vs Viewer initialization - this should be the same as its the same rendering and threading code under the hood, the only real difference is the high level management of views/cameras, at the low level is just the same osgViewer::Renderer and threading models at play. Again as I don't have your code in front of me to test I really can't say too much. Robert. On Mon, Nov 24, 2008 at 8:08 AM, Viggo Løvli <[EMAIL PROTECTED]> wrote: > 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 > > > ________________________________ > Windows Live SkyDrive. På tide å glemme minnepinnen. > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
