Hi Ryan, I have fixed a couple of items in the precompile path of DatabasePager since 2.6, so even though it's now disabled by default, when you do enable it should function better. So I'd recommend reviewing the code in svn/trunk 2.7.7 rather than 2.6.0.
Robert. On Tue, Jan 6, 2009 at 11:33 PM, Kawicki, Ryan H <[email protected]> wrote: > OSG Version: 2.6.0 > OS: Windows XP SP2 > Compiler: MS Version 13.10.3077 ( .NET 2003 ) > > I am a little confused on how the precompile option works within OSG > 2.6.0. From what I understand, the intended use is to have all gl > objects compiled in the background before they are merged with the scene > graph. I do not believe this is working as intended. Please correct me > if I am wrong about any of my assumptions. > > By default, the code indicates that this option is on. This can be seen > in the constructor of the DatabasePager. As database requests are > processed, the requests are placed inside of the _dataToCompileList. A > few statements later, an if statement is evaluated to see if loaded > objects need to be compiled and that there are active graphics contexts. > This statement evaluates to true, but when it tries to obtain a compile > context for the graphics context, it returns NULL. Because of this, I > believe the objects to be compiled are being compiled on the same thread > that is rendering the scene. > > void DatabasePager::DatabaseThread::run() > { > < ... Code Removed ... > > // move the databaseRequest from the front of the fileRequest to the end > of > // dataToCompile or dataToMerge lists. > if (loadedObjectsNeedToBeCompiled) > { > OpenThreads::ScopedLock<OpenThreads::Mutex> > lock(_pager->_dataToCompileList->_requestMutex); > databaseRequest->_requestQueue = _pager->_dataToCompileList.get(); > > _pager->_dataToCompileList->_requestList.push_back(databaseRequest); > } > < ... Code Removed ... > > if (loadedObjectsNeedToBeCompiled && > !_pager->_activeGraphicsContexts.empty()) > { > for(ActiveGraphicsContexts::iterator itr = > _pager->_activeGraphicsContexts.begin(); > itr != _pager->_activeGraphicsContexts.end(); > ++itr) > { > osg::GraphicsContext* gc = > osg::GraphicsContext::getCompileContext(*itr); > if (gc) > { > < ... Code Removed ... > > } > } > < ... Code Removed ... > > } > > I did some digging to see what needed to be provided to osgViewer to > create the compile context. I found that there was a command line > argument ( "--cc" ) that could be passed to indicate to the pager that a > compile context should be used. This allowed for a compile context to > be obtained, but the scene was no longer visible. Nodes were being > requested and being inserted into the data to compile list, but the > graphics thread seems not to be compiling the data because nothing > visually was showing up. > > if (gc) > { > osg::GraphicsThread* gt = gc->getGraphicsThread(); > if (gt) > { > gt->add(new DatabasePager::CompileOperation(_pager)); > } > else > { > gc->makeCurrent(); > _pager->compileAllGLObjects(*(gc->getState())); > gc->releaseContext(); > } > } > > To make it even more interesting, I NOPed out all of the if statement > and had it go straight to the first statement of the else clause, and > the terrain began showing up, minus the textures. I have not quite > figured that one out yet. > > I do not claim to be an expert on the DatabasePager, but it looks like > there might be a few things wrong with the precompile option. I know it > is going to be defaulted to off in later versions of OSG, but I wanted > to do some testing with our terrains having this option on and off. To > me, it looked like having it on or off made no difference, and this is > why I started to investigate. > > Can anyone confirm that this is the intended behavior of the precompile > option? Have I made any bad assumptions on how the system is intended > to work? Are there missing command line arguments that I have not > explored? > > I am assuming that the graphics context created for the window is the > same graphics context that is used to precompile the data. What kind of > system is in place to make sure that only one thread has access to the > graphics context? > > Thanks for any help. I'll report anything else I might find. > > Ryan H. Kawicki > The Boeing Company > Training Systems & Services > Software Engineer > > _______________________________________________ > 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
