-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Osfield wrote: > 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. > OK; I'll check those out. > Also what hardware/OS are you using? Fedora, 3 Ghz dual processor P4, 8800 GTS. I don't have any I/O worries about the machine; other OSG sample programs and databases run fine.
Tim > > Robert. > > On Nov 8, 2007 3:01 PM, Tim Moore <[EMAIL PROTECTED]> wrote: > 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 _______________________________________________ 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHM41neDhWHdXrDRURAiXrAKDfsljuLckH8dxU1LDEoOaHeXOW3QCeIDgQ qw8lH0YWsES6JKFYBb6SHiE= =TgMC -----END PGP SIGNATURE----- _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
