An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x69631572
Function=DrvSetPixelFormat+0x1BC42
Library=C:WINDOWSSystem32nvoglnt.dll
Current Java thread:
at org.lwjgl.opengl.GL12.nglDrawRangeElements(Native Method)
at org.lwjgl.opengl.GL12.glDrawRangeElements(Unknown Source)
at com.jme.renderer.lwjgl.LWJGLRenderer.draw(LWJGLRenderer.java:998)
at com.jme.scene.TriMesh.draw(Unknown Source)
at com.jme.scene.Spatial.onDraw(Spatial.java:208)
at com.jme.scene.Node.draw(Node.java:222)
at com.jme.scene.Spatial.onDraw(Spatial.java:208)
at com.jme.scene.Node.draw(Node.java:222)
at com.jme.scene.Spatial.onDraw(Spatial.java:208)
at com.jme.scene.Node.draw(Node.java:222)
at com.jme.scene.Spatial.onDraw(Spatial.java:208)
at com.jme.renderer.lwjgl.LWJGLRenderer.draw(LWJGLRenderer.java:1171)
at com.jme.app.SimpleGame.render(Unknown Source)
at com.jme.app.BaseGame.start(Unknown Source)
at jmetest.renderer.loader.TestMaxJmeWrite.main(TestMaxJmeWrite.java:35)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.intellij.rt.execution.application.AppMain.main(Unknown Source)
I checked my index array and the largest index is smaller than the length of my Vertex array. I don't know LWJGL so I can't really debug the problem to much. It happens when when I load this one model. Other models don't give me trouble, but this one model does (it's a 3d model of Europe). I've loaded larger and more complex models without pain. Not sure why this one give this error. Could it just be my computer. The error only happens when I can view the model, and even then sometimes I can view it for a few seconds before the error throws.
We were having issues with a similar issue in our game and it turned out to be an issue with textures and texture combining. It’s hard to see the exact problem from the stack trace since glDrawRangeElements does so much. You definitely have the latest from cvs, right? Looking around the net for similar errors when we saw ours (also complaining about DrvSetPixelFormat) game companies, if sent that stack, would recommend you update your driver. Of course we tried that without luck and it ended up being incorrect texturing code in jME as I mentioned.
Doesn’t matter what I do with the VBO settings now, it crashes while loading a textured 3ds / obj model. I’ve updated all my drivers, tried different JREs, and different video cards. Still no luck - I guess I’m going to have to do without textures for now.
Some of the test classes work, and some die in the same way. Right now I’m struggling to load 3ds models without _any_textures! The rendering window opens for a frame or two, and then dies. Extremely frustrating.
I’ve updated the drivers for all the graphics cards I’ve tested against:
an nVidia AGP, an nVidia PIC, an ATI AGP, and an intel on-board. Some of them had worse problems than others - the intel chipset wouldn’t even display the gl preferences dialog?(!) I haven’t had time yet to chase up why.
sigh
I’ve tried multiple models against multiple cards, and sometimes it dies, and sometimes it runs without crashing until I close it 30 mins later.
I think it must be some threading-related problem, and I’ve simply setup my code in such a way that the problem is exacerbated. Any other ideas?
Is there some documentation around that would set out all the calls I need to make (and their order!) to load a 3ds model without difficulty? Perhaps more importantly, a listing of the calls I shouldn’t make?
what are these cards you’ve tested? actual names please… (eg. nvidia geforce 2 mx) if some of the jmetests die for you, then you’ve got an issue that goes beyond improper code usage.
I think it must be some threading-related problem, and I've simply setup my code in such a way that the problem is exacerbated. Any other ideas?
Jme is not thread safe. You need to make shour that only one thread is accessing jme at one time. The only thread that can load textures is the rendering one. You also can onle load models that have textures in the rendering thread.
Hrm. The application I’m working on uses AWT components to modify the models loaded by the jME stuff. I’ve got 2 threads - one for the gui, and one for jME. All the model loading stuff is taken care of by jME, so I’m pretty sure it’s all in the one thread, but I’ll check & get back to you.
Nope - all my object loading is done in one thread.
The only thread that can load textures is the rendering one
Thats not strictly true badmi. You can force another thread to be the currentThread in OpenGL and load textures in it. Like Renanse is doing :)
DP
Actually sorry DP but I'm only using one thread. I had to ditch the multithread approach, *even though I was making sure it was safe* because OpenGL is only safely accessed via one thread. (So it's not a jME restriction...) See my turning point from multi to single here at the lwjgl forum: http://puppygames.net/forums/viewtopic.php?p=5121&highlight=#5121
Hrm. The application I'm working on uses AWT components to modify the models loaded by the jME stuff. I've got 2 threads - one for the gui, and one for jME. All the model loading stuff is taken care of by jME, so I'm pretty sure it's all in the one thread, but I'll check & get back to you. :)
Nope - all my object loading is done in one thread. :(
I do something similar in the Particle Editor when you choose a new texture image. You might take a look at that app and see if it sets off any bells.
Im curious as to know the performance difference from loading from one thread as opposed to loading in 2...Or does the rendering thread wait for the loading thread to finish anyway before it renders?
(Possibly due to later libraries?)
