Found the sound the nature of this bug I suspect its a memory error that only trips you over in certain circumstances, change the cirtcumstances slightly and the bug "magically" disappears - for instance debug vs release. Threading issue tend to be like this in nature too, but in this case its been reproduce in GLUT examples which are single threaded so this is very unlikely.
Perhaps the new osgsimpleviewerGLUT and osgsimpleviewerProducer examples might come in useful here. There are basically the same OSG/OpenGL wise, but have different windowing API's setting up the graphics context. Recently for a client app they hit a problem under Windows using a simple GLUT example, I moved this example to using Producer and its been fine ever since, the problem wasn't related the display lists but textuering, I couldn't explain this bug, but Producer's setup fixed.
If this sample trick works with osgsimpleviewerGLUT not working and osgsimpleviewerProducer working then we'll be much closer to a bare minumum app that does the same in both cases save for the windowing. All the OpenGL tokens should be the same, as they should have been with my clients GLUT vs Producer example app.
If the error is on the OSG side then its likely to be an uninitialized variable somewhere. The nature of this problem doesn't point to this as the most likely candidate, it has many of the hallmarks of a OpenGL driver bug.
Robert.
On 10/2/06, Marc Bernatchez <[EMAIL PROTECTED]> wrote:
>Hi Marc,
>Little has changed with it between 1.0 and 1.2. Little changed with
>SceneView too.
>I suspect there is a bug in the OpenGL driver that is triggered in some
>OpenGL usage conditions. It may well be impossible for us to pin point
>this, let alone provide a decent work around on the OSG side. We need to
>reproduce this in a small example and send it one to NVidoa and bag on their
>door, with a number of seperate voices clearly specifying the importance of
>resolving this.
>There is chance there is a problem on the OSG side though, but nature of the
>problem suggests that its outside the OSG.
>Robert.
Hi Robert,
When you say that little has changed, which module are you referring to? Pretty much all files under the osgUtil folder have changed. Since the code that seems to trigger this problem sounds located there, I would certainly consider that area as a serious spot for further investigation.
I would first try the most accessible and obvious test which is to revert to the old lib3ds code and see if it has an impact. Are there many dependencies to that change or can we simply revert the code in a few lib3ds files and hope it will compile fine? It feels to me this problem is a vertice format issue and having big / little endian mix-up would clearly cause strange behaviors. I have little hope this will be the problem as it wouldn't work with osgViewer stand-alone, but who knows, it may be worth a quick try. If it is not in lib3ds, then the next biggest suspect is the osgUtil section. This represents quite a few changes so I do not know where to start looking and thus would like your help for that section.
The problem with the approach you suggest is that I feel it will be hard to convince NVIDIA that they are the ones at fault if we only knock their doors with a test app that recreate the problem. On the other hand, if we can tell them which changes in the test app code triggers it, then it will be easy for them to track down the problem on their driver side so they would probably be more inclined to give it a look. We can also give it a try right away like you suggest and see their reaction. Meanwhile, it doesn't prevent us from keeping looking for the trigger point in parallel. They would surely give it more importance if we show our intent to work with them on this than just hand it over to them. I recall someone mentioned that the VRJuggler simple OSG demo app (is it osgNav?) allowed to trigger the problem. We could try to put a demo case with this code and a 3DS file that shows the problem and contact NVIDIA with that.
I wouldn't say at this point that the bug is in the driver more than OSG. I agree with you it looks like it, but if you look at it from the opposite angle, it could be a case that the windows based driver is more picky (or if you prefer, follows more closely the OpenGL specs than the linux one). In that scenario, something that is slightly limit to being acceptable by OpenGL standards could indeed only crash on the driver that is the most strict.
Let me know of your suggestion on code changes under osgUtil or other modules that we could put to test in order to try to narrow down the trigger point of this problem. A good starting point seems to be to look at code relating to the COMPILE_STATE_ATTRIBUTES flag, and then radiate around from the point. An other point that raises question is: what is different between 3DS files and OpenFLight ones in terms of loaded formats? As it seems that the 3DS loaded first bugs while loading a FLT doesn't.
I will test as much as I can on my side based on your suggestions and try to provide a test app based on the osgNav code.
Regards,
--
=====================================
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/
