Hi Marc et al, I took a look at the threads J.P. pointed to and I'm pretty sure I'm observing this same problem also.
In my app, I've implemented a custom Win32 viewer using SceneView and a small initial scenegraph. I am explicitly calling SceneView::init in my app immediately before the first update traversal, although I'm not sure that has bearing on the problem. Through trial and error, I found that the problem goes away if I mask out the COMPILE_GLOBJECTS_AT_INIT bit when calling SceneView::setDefaults. I think this may be analogous to Robert's workaround. It also goes away if the initial scenegraph has no Drawables to compile. Even with the initial scene graph pared the to the bare minimum data -- one Geode containing one Drawable containing one GL_POINTS primitive, containing one point -- the problem persists. I also observed the following weird symptoms which may be relevant: - My app is currently set up to create multiple identical windows on demand. When I create the first window, I observe the problem. But the second and later windows within the same process work fine. - When running under GLIntercept the problem goes away. I'm testing with OSG 1.1 and the NVIDIA 84.26 driver. -Mike -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marc Bernatchez Sent: Wednesday, September 27, 2006 10:35 AM To: OSG List Subject: [osg-users] Re: Problems loading 3DS files since OSG 1.1 Hi JP, Yes, that is exactly it. The temporary fix below did work. Did we find yet what is the exact code change that triggered this between OSG 1.0 and 1.1? The link with display lists and drawing contexts sounds logical with the symptoms that were reported. My application runs in stereo so I assume I setup two separate contexts. I run on an NVIDIA as you already guessed and am using osgUtil::SceneView too. My NVIDIA driver version is: 78.01. If the problem is out of the OSG community control, maybe an interim solution could be to track down the OSG code that caused this and revert back, that would allow to remove this annoyance from the next OSG releases until NVIDIA can help on this. This is assuming that the OSG changes triggering this bug are not absolutely necessary and could be achieved using a different coding method. Any news on this issue regarding a permanent solution? What is the position of Robert and others on this? Thanks JP for the pointer. It helps a lot! Regards, -- ===================================== Marc Bernatchez Candidat au Ph.D. Ecole Polytechnique de Montreal Montreal, QC, CANADA ===================================== Virtual Reality web site, VResources: http://vresources.org ===================================== Hi Marc, I'm taking a guess here, but it sounds like the same problem some people ran into with using SceneView (post OSG 1.0), display lists and NVidia cards on Windows. I'm not sure if VRJuggler uses SceneView, but search for the threads by "Gian Lorenzetto" on model loading. The workaround suggested by Robert was this (supposing you are using SceneView): ------8<------------ sceneview = new osgUtil::SceneView; sceneview->setDefaults(); sceneview->setInitVisitor(new osgUtil::GLObjectsVisitor(osgUtil::GLObjectsVisitor::COMPILE_STATE_ATTRI BUTES)); sceneview_->setSceneData(... ------8<------------ regards jp -- ===================================== Marc Bernatchez Candidat au Ph.D. Ecole Polytechnique de Montreal Montreal, QC, CANADA ===================================== Virtual Reality web site, VResources: http://vresources.org ===================================== _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
