Hi Tim, You could try tweaking the FindCompileableGLObjectsVisitor or the Drawable::compileGLObjects() to avoid recompile, see how much difference this makes.
Using compressed texture when doing paging also makes a huge difference. Also what hardware/OS are you using? Robert. On Nov 8, 2007 3:01 PM, Tim Moore <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > I've converted FlightGear to use OSG's database pager. While I'm happy that > it works at > all, I've noticed that it can take a very long time (several seconds) to load > in a single > terrain tile which does not have very much data by modern standards. I > believe the > problem is excessive (re)compilation of GL objects. > > Some background: I'm not using PagedLOD, but am making explicit > requestNodeFile calls from > FlightGear's existing tiling code. Actually, I've subclassed DatabasePager to > support > explicit delete requests too. I don't think that this usage pattern changes > much with > respect to the behaviour I'm seeing. > > When I set OSG_DO_PRE_COMPILE=no the tile times are much more reasonable (300 > - 500 ms). > Also, setting OSG_MAXIMUM_OBJECTS_PER_FRAME to higher values lowers the tile > time. Both > these changes produce noticeable jerks in the visuals. I think it's clear > that the > slow load times are caused by a storm of GL compile operations building up on > the > DatabasePager's queue. > > The terrain in FlightGear is polygon meshes with textures from a material > library plus models > loaded from the file system. Most of these models are shared with other > tiles, so there > is a lot of potential for sharing. We use the object cache in the file loader > for these > models, and the subgraph for the whole tile, including terrain and models, is > built in > the ReaderWriter::readNode method for the top-level tile file. > > So... I notice that DatabasePager::FindCompileableGLObjectsVisitor doesn't > check if the > object is already compiled, so I think our shared models and textures are > being recompiled > in every new tile that is loaded. This might not be very expensive for > textures, but > by default only 4 objects are compiled per frame, so it slows down the > loading of the tile. > The compileGLObjects method for osg::Drawable doesn't check if its object is > already > compiled (probably by design), and I imagine that compiling display lists > could be > expensive. > > Also, I've noticed that the SharedStateManager is called in the update > traversal late > in the loading process, after objects have been compiled. Is there any reason > that this > can't be done earlier, in the pager thread, potentially eliminating the need > for some > compilation? > > What are people doing with material and model libraries and paging? Do you > live with > vertex arrays and "precompile" textures, relying only on the > SharedStateManager? > I'd rather not give up on display lists just yet. > > Thanks, > Tim > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFHMyTOeDhWHdXrDRURAvWLAKCoBPTSun+pegT+naicyUfnnabG4gCfWCeo > kAcwiB7SuyTYk/NiaeJkwAs= > =5ClR > -----END PGP SIGNATURE----- > _______________________________________________ > 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
