🔒 Locked
MD2 inverted?
Advertisement
Original Post
I am attempting to render a mesh loaded from a MD2 file. MD2 files use a right-handed coordinate system it seems, and so the Y and Z values need to switched to work properly in a left-handed system. I have done this, but the mesh still looks funny when rendered. Some faces are rendered on top of others that should be behind them. I've tried clockwise and counter-clockwise culling and even tried turning it off. Any clues?
my guess is your not interpreting the md2's state data correctly, md2's have some of their triangles arranged in triangle strips and others in triangle fans, and the rest as a fat pile of triangles. http://linux.ucla.edu/~phaethon/q3/formats/md2-schoenblum.html has info on that, they seem to call it "GL COMMANDS" in this resource, im willing to bet that thats the problem, i remember with my md2's i screwed something up when i was interpreting these "commands" and it looked something like what your describing, id look into that
hope that helps
-Dan
hope that helps
-Dan
So you need to divid the mesh into triangle strips and fans? I am currently just taking all the vertices and stuffing them into a vertex buffer and rendering it as a triangle list (indexed).
The thing is, the actual mesh looks ok (the position of all the vertices are correct). It just seems as if triangles are sorted incorrectly. Some are clockwise, while others are counter clockwise or something. But the strange thing is, it looks wierd even if I turn culling off.
btw, I've been using just that link you write my MD2 loader. ;)
The thing is, the actual mesh looks ok (the position of all the vertices are correct). It just seems as if triangles are sorted incorrectly. Some are clockwise, while others are counter clockwise or something. But the strange thing is, it looks wierd even if I turn culling off.
btw, I've been using just that link you write my MD2 loader. ;)
I can't really say what your problem is based on the description you've given - it sounds like there may be a bug in your loader - but you definitely *don't* need to use the GL commands. There's no reason you shouldn't be able to build simple triangle lists. The GL commands will probably be much less efficient than triangle lists stored in vertex buffers.
I've looked around and most MD2 loaders that use D3D seem to ignore the GL Commands.
First I create a index buffer from the "triangles" in the MD2 file. Then I create a vertex buffer from the vertex data in the first frame of the MD2 file. Next I try to render it with a simple DrawIndexedPrimitive() call.
I've tried to render the vertices as indexed and as non-indexed (by creating a seperate vertex for each index in a triangle). No dice.
Can it have anything to do with the Z buffer? As culling doesn't seem to matter I mean? It looks just like it's drawing pixels with a "deeper" Z value over pixels that should be infront.
First I create a index buffer from the "triangles" in the MD2 file. Then I create a vertex buffer from the vertex data in the first frame of the MD2 file. Next I try to render it with a simple DrawIndexedPrimitive() call.
I've tried to render the vertices as indexed and as non-indexed (by creating a seperate vertex for each index in a triangle). No dice.
Can it have anything to do with the Z buffer? As culling doesn't seem to matter I mean? It looks just like it's drawing pixels with a "deeper" Z value over pixels that should be infront.
Ok, i've tried that too now. Still same problem though. :(
Snippet from when i'm filling my D3D vertex buffer:
m_pFrames contains the MD2 frames just as they are in the file.
m_pTris has the MD2 triangles.
pVertices is the pointer to the buffer i'm filling.
Snippet from when i'm filling my D3D vertex buffer:
pVertices[i * 3].x = ((float)m_pFrames[frame].pVertices[m_pTris.vertexIndices[0]].vertex[0] * m_pFrames[frame].scale[0]) + m_pFrames[frame].translate[0];pVertices[i * 3].z = -(((float)m_pFrames[frame].pVertices[m_pTris.vertexIndices[0]].vertex[1] * m_pFrames[frame].scale[1]) + m_pFrames[frame].translate[1]);pVertices[i * 3].y = ((float)m_pFrames[frame].pVertices[m_pTris.vertexIndices[0]].vertex[2] * m_pFrames[frame].scale[2]) + m_pFrames[frame].translate[2];m_pFrames contains the MD2 frames just as they are in the file.
m_pTris has the MD2 triangles.
pVertices is the pointer to the buffer i'm filling.
I meant to negate the new Z coordinates. That will compensate for the right handedness of the MD2 setup. Thus do this
pVertices[i * 3].z = (((float) . . .;
pVertices[i * 3].y = -(((float) . . .;
Also, your culling should be set to something like this:
pYourD3Ddevice->SetRenderState(D3DRS_CULLMODE, D3DCULL_CW);
Try changing D3DCULL_CW to D3DCULL_CCW if you are still having problems.
pVertices[i * 3].z = (((float) . . .;
pVertices[i * 3].y = -(((float) . . .;
Also, your culling should be set to something like this:
pYourD3Ddevice->SetRenderState(D3DRS_CULLMODE, D3DCULL_CW);
Try changing D3DCULL_CW to D3DCULL_CCW if you are still having problems.
Quote:
Original post by Ademan555
Im tellin yah you need those commands, i think whether you need them or not depends on what model your loading, but at least the models i had for mine, all of them needed them...
-Dan
No, those are optional. GLCOMMANDS are totally optional. I've never come across an MD2 where you HAVE to use the glCommands. They're just if you want an optimized way to draw in OpenGL.
Well, DOH... I had neglected to specify that AutoDepthStencil should be enabled in the device parameters. No wonder the Z-buffer was all screwed up! It had no Z-buffer to work with. :/
GRRRRRAAO... I hate it when you sit for like a day and just don't get a problem and it turns out to be that you just forgot something simple.
Anyway, thanks for all your help guys! :)
GRRRRRAAO... I hate it when you sit for like a day and just don't get a problem and it turns out to be that you just forgot something simple.
Anyway, thanks for all your help guys! :)
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement