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/
