Rendering Quake III BSP In DirectX
Author
Hey,
I've been reading a load of documentation lately on Quake III's BSP format as well as a number of tutorials, namely the one's from GameTutorials.com in which the writer goes through loading the base level to lightmaps and utilizing nodes and leaves.
The one question that is nagging at the back of my mind is how to go about rendering the level face by face. I know in OpenGL there is no such think as a "vertex buffer" and thus they can use glDrawArrays quite easily without a decline in performance. In DirectX on the other hand I know of no way of drawing a number of texture mapped primitives without having a vertex buffer with at least 3 vertices assigned to it.
I think what I'm looking at here is having to use a dynamic vertex buffer and as I loop through each "face" from the BSP file, I populate the vertex buffer, set the textures (normal and lightmap), set any lights and then render it, continually looping through each face until I reach the end. From looking at this I believe this should stop the video card from locking during rendering as it will be rendering a group of vertices while I'm buidling up the next face.
for( int i = 0; i < numFaces; i++ )
{
lock the buffer
populate the buffer with faces;
set the texture at texture[ faces->texturID ];
set the stream source and everything
drawprimitive
}
If anyone else has any other experience with this it'd be great if you could provide me with some insight of whether or not this is how you went about rendering the level, and if not, what is the best solution here?
Thanks in advance,
Permafried-
The method you propose is *definetly* not DirectX friendly. Locking the vertex buffer and calling DrawPrimitive() for each face is going to kill your application.
According to this slideset (which I consider reliable), you only get about 25,000 DrawPrimitive() calls per second. You could very easily go over 25,000 DrawPrimitive() calls per frame.
Also, you shouldn't be locking many vertex buffer per frame. Locking a vertex buffer or index buffer causes a windows mode transition, from user mode to kernel mode (and back). This is to be avoided, or at least kept to a minimum.
I'm not familiar with Quake III BSP, but would it be possible to put all of the visible triangles into a vertex buffer, and make one DP call? Like:
However, you probably have a lot of different textures visible at one time. If possible, minimize the number of textures, because each requires another SetTexture() and DrawPrimitive(). You could still only make one Lock(), if you do it like this:
According to this slideset (which I consider reliable), you only get about 25,000 DrawPrimitive() calls per second. You could very easily go over 25,000 DrawPrimitive() calls per frame.
Also, you shouldn't be locking many vertex buffer per frame. Locking a vertex buffer or index buffer causes a windows mode transition, from user mode to kernel mode (and back). This is to be avoided, or at least kept to a minimum.
I'm not familiar with Quake III BSP, but would it be possible to put all of the visible triangles into a vertex buffer, and make one DP call? Like:
Lock the bufferfor each rendered face{ add vertices}Unlock the vertex bufferSet textureSet stream sourceDrawPrimitiveHowever, you probably have a lot of different textures visible at one time. If possible, minimize the number of textures, because each requires another SetTexture() and DrawPrimitive(). You could still only make one Lock(), if you do it like this:
Lock the bufferfor each texture n{ for each rendered face with texture n { add vertices } add vertex offset to offsetList}Unlock the bufferfor each offset in offsetList{ setTexture SetStreamSource with offset DrawPrimitive}
Author
Circlesoft,
Thanks for the reply. I know that rendering my level in this way is definitely not DirectX friendly but the problem arises, as you mentioned, having multiple textures where each face has not only a graphical texture assigned to it but a lightmap as well. This means that for each x number of vertices, I need to render just that subset and the texture assigned to it. This is where loading in and utilizing the Quake III .BSP format's PVS data will come in handy.
A thorough explanation of Quake III .BSP formats can be found at:
Game Tutorials
There are also 3 tutorials which build upon one another from loading and rendering the raw vertices to implementing the BSP tree and PVS.
I'm still going to be using a dynamic vertex buffer and populating it every frame with the PVS (I guess I could do a check and if it hasn't changed, don't update it ^_^) but looping through in this way should hopefully help to improve my performance.
Thanks again, I'll keep your suggestions in mind when I go back to optimizing this evening. My first goal is to simply get the level rendering in which case the architecture mentioned above should easily port over from raw rendering to selective rendering. Let me know if this seems to make a little more sense and I'm on the right track based on what you suggested.
Permafried-
Thanks for the reply. I know that rendering my level in this way is definitely not DirectX friendly but the problem arises, as you mentioned, having multiple textures where each face has not only a graphical texture assigned to it but a lightmap as well. This means that for each x number of vertices, I need to render just that subset and the texture assigned to it. This is where loading in and utilizing the Quake III .BSP format's PVS data will come in handy.
A thorough explanation of Quake III .BSP formats can be found at:
Game Tutorials
There are also 3 tutorials which build upon one another from loading and rendering the raw vertices to implementing the BSP tree and PVS.
I'm still going to be using a dynamic vertex buffer and populating it every frame with the PVS (I guess I could do a check and if it hasn't changed, don't update it ^_^) but looping through in this way should hopefully help to improve my performance.
Thanks again, I'll keep your suggestions in mind when I go back to optimizing this evening. My first goal is to simply get the level rendering in which case the architecture mentioned above should easily port over from raw rendering to selective rendering. Let me know if this seems to make a little more sense and I'm on the right track based on what you suggested.
Permafried-
I have been working on a Quake 3 renderer lately and Dustin is correct. You need to sort the faces by texture and then add them to the vertex/index buffer. Make sure when you create your vertex and index buffers that you use the dynamic creation flag and also when you lock them you want to use the discard flag.
Author
Yzzid,
I was wondering if you'd had any success to this point getting your level to render correctly or not. I know that Quake III uses triangle fans to render, but my biggest problem right now is figuring out the number of primitives to render based on the number of vertices contained within the face.
I created a normal vertex buffer for the sake of attempting to render the entire thing, but no matter what I've tried I can't get the thing to display, though I'm almost 100% sure it's loading correctly as I've gotten all the required information including vertices, faces and textures to this point.
When I load the level I've populated the vertex buffer and loaded all of the textures and have tried looping through the faces and rendeirng them using:
I was wondering if you'd had any success to this point getting your level to render correctly or not. I know that Quake III uses triangle fans to render, but my biggest problem right now is figuring out the number of primitives to render based on the number of vertices contained within the face.
I created a normal vertex buffer for the sake of attempting to render the entire thing, but no matter what I've tried I can't get the thing to display, though I'm almost 100% sure it's loading correctly as I've gotten all the required information including vertices, faces and textures to this point.
When I load the level I've populated the vertex buffer and loaded all of the textures and have tried looping through the faces and rendeirng them using:
pd3dDevice->SetFVF( CLevel::dwFVF );pd3dDevice->SetStreamSource( 0, m_pvbVertexLevelVertexBuffer, 0, sizeof( CLevelVertex ) );pd3dDevice->SetTexture( 0, m_pFaces->textureID );<br>DrawPrimitive( D3DPT_TRIANGLEFAN, m_pFaces->startVertex, ?!? );<br><br><br></pre></div><!–ENDSCRIPT–><br><br>For the time being, I really shouldn't have to worry about the offset into my vertex buffer as each face cotains the offset into the BSPVertex array which would correspond to the vertex buffer's offset as i copy vertex by vertex. Any help here would be appreciated as I'm a little confused oh why this thing just won't render.<br><br>Thanks again,<br><br>Permafried-
That seems to be the correct method.
I would also add that you should be using an index buffer and use the indices for each face too.
What you are doing should, in theory, work.
Try putting using the debug DirectX library on the highest output level and your output window in Visual Studio should give you some clues as to what the problem is.
I would also add that you should be using an index buffer and use the indices for each face too.
What you are doing should, in theory, work.
Try putting using the debug DirectX library on the highest output level and your output window in Visual Studio should give you some clues as to what the problem is.
Author
I think one of the major problems is rendering using triangle fans as Quake III did, but DirectX has the limitation that you have to provide any drawing method with the number of primitives, and there is no nice way as far as I can see to calculate the number of triangle fans based on the number of vertices to be drawn. I have a feeling if I could resolve this number correctly and mess with my rendering a little bit more I should be on the right track.
Any ideas on this?
Another thing I found, which is incredibly strange....I dumped out the vertices as they were loaded from my application and the last 15 vertices are churning out absolute garbage. I compared this with the dump from the OpenGL tutorial I've been using as a guide and my code looks identical as far as I can tell. I am getting back the correct number of vertices, faces and textures, but my vertices aren't loading correctly after the 52nd one. Here's what I've got as far as loading vertices:
Any ideas on this?
Another thing I found, which is incredibly strange....I dumped out the vertices as they were loaded from my application and the last 15 vertices are churning out absolute garbage. I compared this with the dump from the OpenGL tutorial I've been using as a guide and my code looks identical as far as I can tell. I am getting back the correct number of vertices, faces and textures, but my vertices aren't loading correctly after the 52nd one. Here's what I've got as far as loading vertices:
struct tBSPVertex{ D3DXVECTOR3 d3dvOrigin; ///< The position of the vertex in 3D space D3DXVECTOR2 d3dvTexCoords; ///< The texture coordinates of this vertex's texture D3DXVECTOR2 d3dvTexLightMap; ///< The texture coordinates of this vertex's lightmap D3DXVECTOR3 d3dvNormal; ///< The normal calculated for this vertex unsigned char ucColour[ 4 ]; ///< The colour of this vertex};bool CLevel::levelLoadLevel( char* szLevel ){ // get the total number of vertices m_iNumOfVertices = bspLumps[ LUMP_VERTICES ].iLength / sizeof( tBSPVertex ); // allocate memory for the vertices to be read in m_pVertices = new tBSPVertex[ m_iNumOfVertices ]; // seek to the position in the file which contains the vertices fseek( pFile, bspLumps[ LUMP_VERTICES ].iOffset, SEEK_SET ); // loop through all the vertices and populate the vertex array for( int i = 0; i < m_iNumOfVertices; i++ ) { // read in the current vertex fread( &m_pVertices, <span class="cpp-number">1</span>, <span class="cpp-keyword">sizeof</span>( tBSPVertex ), pFile );<br><br> <span class="cpp-comment">// reverse the positional coords, quake III uses Z as up</span><br> <span class="cpp-keyword">float</span> fTemp = m_pVertices.d3dvOrigin.y;<br> m_pVertices.d3dvOrigin.y = m_pVertices.d3dvOrigin.z;<br> m_pVertices.d3dvOrigin.z = -fTemp;<br><br> <span class="cpp-comment">// negate the textures coords otherwise it'll be upside down</span><br> m_pVertices.d3dvTexCoords.y *= -<span class="cpp-number">1</span>;<br>}<br><br><br></pre></div><!–ENDSCRIPT–><br><br>I've also tried without swapping the y and z and I can manage to get to vertex 70 before it barfs..I'm totally lost on this one, I can see nothing wrong with my code above nor the level load itself….hopefully a fresh set of eyes will help ^_^.<br><br>Thanks again for all your help,<br><br>Permafried-<br><br><!–EDIT–><span class=editedby><!–/EDIT–>[Edited by - Permafried- on August 17, 2004 9:28:31 PM]<!–EDIT–></span><!–/EDIT–>
What flags are you opening your file with? I recently had a problem just like this. The solution was to open it read-binary flag:
file = fopen( filename, "rb" );
Also, you may just want to try something to see if it makes a difference:
file = fopen( filename, "rb" );
Also, you may just want to try something to see if it makes a difference:
fseek( pFile, bspLumps[ LUMP_VERTICES ].iOffset, SEEK_SET );fread( (void*)m_pVertices, m_iNumOfVertices, sizeof( tBSPVertex ), pFile ); // loop through all the vertices and populate the vertex arrayfor( int i = 0; i < m_iNumOfVertices; i++ ){ // reverse the positional coords, quake III uses Z as up float fTemp = m_pVertices.d3dvOrigin.y;<br> m_pVertices.d3dvOrigin.y = m_pVertices.d3dvOrigin.z;<br> m_pVertices.d3dvOrigin.z = -fTemp;<br><br> <span class="cpp-comment">// negate the textures coords otherwise it'll be upside down</span><br> m_pVertices.d3dvTexCoords.y *= -<span class="cpp-number">1</span>;<br>}<br></pre></div><!–ENDSCRIPT–><br>
Author
Hey,
I can't believe after all that trouble of disappearing vertices when loading that it was that simple little b....and of course while going through line after line of code that is something more than easy enough to miss.
Thanks a lot that solved the problem, I now have all the vertices in the exact order and format that the tutorial does, so hopefully tomorrow I can tackle the issue of rendering.
In regards to rendering, if I'm not mistaken the number of primitives on a DrawPrimitive call when using triangle fans should be ( number of vertices - 2 ), this seems to stay true in all cases even though I haven't tried it in code yet.
Thanks again,
Permafried-
[Edited by - Permafried- on August 18, 2004 11:47:52 AM]
I can't believe after all that trouble of disappearing vertices when loading that it was that simple little b....and of course while going through line after line of code that is something more than easy enough to miss.
Thanks a lot that solved the problem, I now have all the vertices in the exact order and format that the tutorial does, so hopefully tomorrow I can tackle the issue of rendering.
In regards to rendering, if I'm not mistaken the number of primitives on a DrawPrimitive call when using triangle fans should be ( number of vertices - 2 ), this seems to stay true in all cases even though I haven't tried it in code yet.
Thanks again,
Permafried-
[Edited by - Permafried- on August 18, 2004 11:47:52 AM]
Author
Hello again,
Well I finally got the geometry rendering, but noticed my textures were completely whack. I created a quick file output routine to check all the information about the vertex and noticed the texture coords are right outta whack (ignore the - this is due to a dumb calculation I had in the code):
Face: 0
Start Vert: 0
Num Verts: 6
Vertex 0: -128 264 64 0 -4
Vertex 1: -128 264 -64 0 -2
Vertex 2: 0 264 -184 2 -0.125
Vertex 3: 184 264 -184 4.875 -0.125
Vertex 4: 184 264 184 4.875 -5.875
Vertex 5: -128 264 184 0 -5.875
Texture: 0
Face: 1
Start Vert: 6
Num Verts: 5
Vertex 6: -128 264 184 2 -5.875
Vertex 7: 184 264 184 6.875 -5.875
Vertex 8: 184 632 184 6.875 -0.125
Vertex 9: -248 632 184 0.125 -0.125
Vertex 10: -248 384 184 0.125 -4
Texture: 0
Face: 2
Start Vert: 11
Num Verts: 4
Vertex 11: 184 264 184 0.125 -5.875
Vertex 12: 184 264 -184 5.875 -5.875
Vertex 13: 184 632 -184 5.875 -0.125
Vertex 14: 184 632 184 0.125 -0.125
Texture: 0
Face: 3
Start Vert: 15
Num Verts: 5
Vertex 15: -248 632 -184 0.125 -0.125
Vertex 16: 184 632 -184 6.875 -0.125
Vertex 17: 184 264 -184 6.875 -5.875
Vertex 18: 0 264 -184 4 -5.875
Vertex 19: -248 320 -184 0.125 -5
Texture: 0
Face: 4
Start Vert: 20
Num Verts: 5
Vertex 20: -248 632 184 0.125 -0.125
Vertex 21: -248 632 -184 5.875 -0.125
Vertex 22: -248 320 -184 5.875 -5
Vertex 23: -248 320 -64 4 -5
Vertex 24: -248 384 184 0.125 -4
Texture: 0
Face: 5
Start Vert: 25
Num Verts: 4
Vertex 25: -248 632 184 0.125 -5.875
Vertex 26: 184 632 184 6.875 -5.875
Vertex 27: 184 632 -184 6.875 -0.125
Vertex 28: -248 632 -184 0.125 -0.125
Texture: 0
Face: 6
Start Vert: 29
Num Verts: 4
Vertex 29: -128 384 64 0.5 0
Vertex 30: -128 320 -64 1.5 -0.5
Vertex 31: -128 264 -64 1.5 -0.9375
Vertex 32: -128 264 64 0.5 -0.9375
Texture: 1
Face: 7
Start Vert: 33
Num Verts: 4
Vertex 33: -248 384 64 0.0625 -1.5
Vertex 34: -248 320 -64 0.0625 -0.5
Vertex 35: -128 320 -64 1 -0.5
Vertex 36: -128 384 64 1 -1.5
Texture: 1
Face: 8
Start Vert: 37
Num Verts: 4
Vertex 37: -128 320 -64 1 -1.5
Vertex 38: -248 320 -64 0.0625 -1.5
Vertex 39: -248 320 -184 0.0625 -0.5625
Vertex 40: -128 320 -184 1 -0.5625
Texture: 1
Face: 9
Start Vert: 41
Num Verts: 4
Vertex 41: 0 264 -184 1.4375 -0.9375
Vertex 42: 0 264 -64 0.5 -0.9375
Vertex 43: 0 272 -64 0.5 -0.875
Vertex 44: 0 272 -184 1.4375 -0.875
Texture: 1
Face: 10
Start Vert: 45
Num Verts: 4
Vertex 45: 0 264 -64 1 -0.9375
Vertex 46: -128 264 -64 0 -0.9375
Vertex 47: -128 320 -64 0 -0.5
Vertex 48: 0 272 -64 1 -0.875
Texture: 1
Face: 11
Start Vert: 49
Num Verts: 4
Vertex 49: -128 320 -184 0 -0.5625
Vertex 50: 0 272 -184 1 -0.5625
Vertex 51: 0 272 -64 1 -1.5
Vertex 52: -128 320 -64 0 -1.5
Texture: 1
Face: 12
Start Vert: 53
Num Verts: 4
Vertex 53: -128 264 64 1.5 -0.9375
Vertex 54: -128 264 184 0.5625 -0.9375
Vertex 55: -128 384 184 0.5625 0
Vertex 56: -128 384 64 1.5 0
Texture: 1
Face: 13
Start Vert: 57
Num Verts: 4
Vertex 57: -128 384 184 1 -1.4375
Vertex 58: -248 384 184 0.0625 -1.4375
Vertex 59: -248 384 64 0.0625 -0.5
Vertex 60: -128 384 64 1 -0.5
Texture: 1
Face: 14
Start Vert: 61
Num Verts: 4
Vertex 61: 40 320 184 0.5625 -0.5
Vertex 62: 40 320 88 1.3125 -0.5
Vertex 63: 40 336 88 1.3125 -0.375
Vertex 64: 40 336 184 0.5625 -0.375
Texture: 1
Face: 15
Start Vert: 65
Num Verts: 4
Vertex 65: 40 320 88 0.3125 -0.5
Vertex 66: 184 320 88 1.4375 -0.5
Vertex 67: 184 336 88 1.4375 -0.375
Vertex 68: 40 336 88 0.3125 -0.375
Texture: 1
Face: 16
Start Vert: 69
Num Verts: 4
Vertex 69: 184 320 88 1.4375 -0.6875
Vertex 70: 40 320 88 0.3125 -0.6875
Vertex 71: 40 320 184 0.3125 -1.4375
Vertex 72: 184 320 184 1.4375 -1.4375
Texture: 1
Face: 17
Start Vert: 73
Num Verts: 4
Vertex 73: 40 336 184 0.3125 -1.4375
Vertex 74: 40 336 88 0.3125 -0.6875
Vertex 75: 184 336 88 1.4375 -0.6875
Vertex 76: 184 336 184 1.4375 -1.4375
Texture: 1
The last two digits are the texture coordinates and I've never seen texture coords of 4.0 in my life. Is there any way to make DirectX recognize this or am I basically SOL for rendering with these kinds of numbers?
Thanks again,
Permafried-
PS: Yzzid, if you happen to come across this post again, have you ever run across this when rendering using ur Quake III BSP renderer or is something else maybe the problem here?
Well I finally got the geometry rendering, but noticed my textures were completely whack. I created a quick file output routine to check all the information about the vertex and noticed the texture coords are right outta whack (ignore the - this is due to a dumb calculation I had in the code):
Face: 0
Start Vert: 0
Num Verts: 6
Vertex 0: -128 264 64 0 -4
Vertex 1: -128 264 -64 0 -2
Vertex 2: 0 264 -184 2 -0.125
Vertex 3: 184 264 -184 4.875 -0.125
Vertex 4: 184 264 184 4.875 -5.875
Vertex 5: -128 264 184 0 -5.875
Texture: 0
Face: 1
Start Vert: 6
Num Verts: 5
Vertex 6: -128 264 184 2 -5.875
Vertex 7: 184 264 184 6.875 -5.875
Vertex 8: 184 632 184 6.875 -0.125
Vertex 9: -248 632 184 0.125 -0.125
Vertex 10: -248 384 184 0.125 -4
Texture: 0
Face: 2
Start Vert: 11
Num Verts: 4
Vertex 11: 184 264 184 0.125 -5.875
Vertex 12: 184 264 -184 5.875 -5.875
Vertex 13: 184 632 -184 5.875 -0.125
Vertex 14: 184 632 184 0.125 -0.125
Texture: 0
Face: 3
Start Vert: 15
Num Verts: 5
Vertex 15: -248 632 -184 0.125 -0.125
Vertex 16: 184 632 -184 6.875 -0.125
Vertex 17: 184 264 -184 6.875 -5.875
Vertex 18: 0 264 -184 4 -5.875
Vertex 19: -248 320 -184 0.125 -5
Texture: 0
Face: 4
Start Vert: 20
Num Verts: 5
Vertex 20: -248 632 184 0.125 -0.125
Vertex 21: -248 632 -184 5.875 -0.125
Vertex 22: -248 320 -184 5.875 -5
Vertex 23: -248 320 -64 4 -5
Vertex 24: -248 384 184 0.125 -4
Texture: 0
Face: 5
Start Vert: 25
Num Verts: 4
Vertex 25: -248 632 184 0.125 -5.875
Vertex 26: 184 632 184 6.875 -5.875
Vertex 27: 184 632 -184 6.875 -0.125
Vertex 28: -248 632 -184 0.125 -0.125
Texture: 0
Face: 6
Start Vert: 29
Num Verts: 4
Vertex 29: -128 384 64 0.5 0
Vertex 30: -128 320 -64 1.5 -0.5
Vertex 31: -128 264 -64 1.5 -0.9375
Vertex 32: -128 264 64 0.5 -0.9375
Texture: 1
Face: 7
Start Vert: 33
Num Verts: 4
Vertex 33: -248 384 64 0.0625 -1.5
Vertex 34: -248 320 -64 0.0625 -0.5
Vertex 35: -128 320 -64 1 -0.5
Vertex 36: -128 384 64 1 -1.5
Texture: 1
Face: 8
Start Vert: 37
Num Verts: 4
Vertex 37: -128 320 -64 1 -1.5
Vertex 38: -248 320 -64 0.0625 -1.5
Vertex 39: -248 320 -184 0.0625 -0.5625
Vertex 40: -128 320 -184 1 -0.5625
Texture: 1
Face: 9
Start Vert: 41
Num Verts: 4
Vertex 41: 0 264 -184 1.4375 -0.9375
Vertex 42: 0 264 -64 0.5 -0.9375
Vertex 43: 0 272 -64 0.5 -0.875
Vertex 44: 0 272 -184 1.4375 -0.875
Texture: 1
Face: 10
Start Vert: 45
Num Verts: 4
Vertex 45: 0 264 -64 1 -0.9375
Vertex 46: -128 264 -64 0 -0.9375
Vertex 47: -128 320 -64 0 -0.5
Vertex 48: 0 272 -64 1 -0.875
Texture: 1
Face: 11
Start Vert: 49
Num Verts: 4
Vertex 49: -128 320 -184 0 -0.5625
Vertex 50: 0 272 -184 1 -0.5625
Vertex 51: 0 272 -64 1 -1.5
Vertex 52: -128 320 -64 0 -1.5
Texture: 1
Face: 12
Start Vert: 53
Num Verts: 4
Vertex 53: -128 264 64 1.5 -0.9375
Vertex 54: -128 264 184 0.5625 -0.9375
Vertex 55: -128 384 184 0.5625 0
Vertex 56: -128 384 64 1.5 0
Texture: 1
Face: 13
Start Vert: 57
Num Verts: 4
Vertex 57: -128 384 184 1 -1.4375
Vertex 58: -248 384 184 0.0625 -1.4375
Vertex 59: -248 384 64 0.0625 -0.5
Vertex 60: -128 384 64 1 -0.5
Texture: 1
Face: 14
Start Vert: 61
Num Verts: 4
Vertex 61: 40 320 184 0.5625 -0.5
Vertex 62: 40 320 88 1.3125 -0.5
Vertex 63: 40 336 88 1.3125 -0.375
Vertex 64: 40 336 184 0.5625 -0.375
Texture: 1
Face: 15
Start Vert: 65
Num Verts: 4
Vertex 65: 40 320 88 0.3125 -0.5
Vertex 66: 184 320 88 1.4375 -0.5
Vertex 67: 184 336 88 1.4375 -0.375
Vertex 68: 40 336 88 0.3125 -0.375
Texture: 1
Face: 16
Start Vert: 69
Num Verts: 4
Vertex 69: 184 320 88 1.4375 -0.6875
Vertex 70: 40 320 88 0.3125 -0.6875
Vertex 71: 40 320 184 0.3125 -1.4375
Vertex 72: 184 320 184 1.4375 -1.4375
Texture: 1
Face: 17
Start Vert: 73
Num Verts: 4
Vertex 73: 40 336 184 0.3125 -1.4375
Vertex 74: 40 336 88 0.3125 -0.6875
Vertex 75: 184 336 88 1.4375 -0.6875
Vertex 76: 184 336 184 1.4375 -1.4375
Texture: 1
The last two digits are the texture coordinates and I've never seen texture coords of 4.0 in my life. Is there any way to make DirectX recognize this or am I basically SOL for rendering with these kinds of numbers?
Thanks again,
Permafried-
PS: Yzzid, if you happen to come across this post again, have you ever run across this when rendering using ur Quake III BSP renderer or is something else maybe the problem here?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement