# OpenGL Rendering Quake III BSP In DirectX

## Recommended Posts

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[ i ]; 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-

##### Share on other sites
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:
Lock the bufferfor each rendered face{   add vertices}Unlock the vertex bufferSet textureSet stream sourceDrawPrimitive

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:
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}

##### Share on other sites
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-

##### Share on other sites
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.

##### Share on other sites
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:

pd3dDevice->SetFVF( CLevel::dwFVF );pd3dDevice->SetStreamSource( 0, m_pvbVertexLevelVertexBuffer, 0, sizeof( CLevelVertex ) );pd3dDevice->SetTexture( 0, m_pFaces[ i ]->textureID );DrawPrimitive( D3DPT_TRIANGLEFAN, m_pFaces[ i ]->startVertex, ?!? );

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.

Thanks again,

Permafried-

##### Share on other sites
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.

##### Share on other sites
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:

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[ i ], 1, sizeof( tBSPVertex ), pFile );		// reverse the positional coords, quake III uses Z as up		float fTemp = m_pVertices[ i ].d3dvOrigin.y;		m_pVertices[ i ].d3dvOrigin.y = m_pVertices[ i ].d3dvOrigin.z;		m_pVertices[ i ].d3dvOrigin.z = -fTemp;		// negate the textures coords otherwise it'll be upside down		m_pVertices[ i ].d3dvTexCoords.y *= -1;}

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 ^_^.

Thanks again for all your help,

Permafried-

[Edited by - Permafried- on August 17, 2004 9:28:31 PM]

##### Share on other sites
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:

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[ i ].d3dvOrigin.y;   m_pVertices[ i ].d3dvOrigin.y = m_pVertices[ i ].d3dvOrigin.z;   m_pVertices[ i ].d3dvOrigin.z = -fTemp;   // negate the textures coords otherwise it'll be upside down   m_pVertices[ i ].d3dvTexCoords.y *= -1;}

##### Share on other sites
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]

##### Share on other sites
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?

##### Share on other sites
Well it turns out I found my problem and have officially loaded my first fully texture mapped Quake III .BSP level in DirectX. Apparently having normals defined as part of your custom vertex but not having lighting enabled causes DX to puke when rendering textures.

Long story short, it's working and now I'm moving up to rendering full quake III levels like DM8 etc.

Thanks again for everyone's help, much appreciated. If anyone has any questions about this I'll be more than happy to help out with it and may look into turning it into a tutorial once I figure out lightmaps, brushes, etc.

Permafried-

##### Share on other sites
Glad to see you making progress.

I just finished getting most of my shader features implemented.
The only things which aren't working are environment mapping, sky boxes, deformed vertexes, and turblant textures.

##### Share on other sites
Yzzid,

Wow you're miles ahead of me....I almost jumped outta my chair when I managed to get the level rendering fully texture mapped ^_^. I managed to get lightmaps somewhat working last nite, but think I have a few problems with how I'm building up the texture based on the information provided. All I do is create a blank texture using CreateTexture, then make a call to LockRect and loop through each pixel of the pBits and assign a colour to it 1 pixel at a time.

I'm going to experiment with this a little more tonite when I get home and hopefully can manage to solve this and move onto working with leaves, nodes and the PVS.

Permafried-

##### Share on other sites
You must realize that I have been working on this for a few years.

It has taken me a while to understand everything.

One thing that has help immensely is that there is a rendering engine in the ShaderX book. That is what I am using as a reference right now. I highly recommend picking it up.

##### Share on other sites
I may have to look into getting a copy of that....I'm developing based on documentation on the Quake III BSP format from what is available online, and pieceing the rest of it together based on what I know about OpenGL, DirectX and C++ in general. For only working on the code for 4 days now or so I'm happy with the results, but I have a tight timeline as it's a school project.

It's supposed to run from September to December, but since I had the summer off as a co-op term I decided to work on it all summer instead, just so I can build the type of project I'm able to add to my portfolio after school, not this piece of junk threw it together as fast as possible just to get the mark ^_^.

If I run into anymore problems I'll keep adding to this thread, particularly since it may be of use to others in the community if they're interested in creating their own BSP parser/rendering engine. It still blows my mind that my texture coordinates are correct, even though the values that were output to the file are totally out of whack and shouldn't have worked in the first place, makes me wonder if they're in binary format, and if I were to convert them over to ASCII via conversion methods if I'd see the real values or not.

Permafried-

##### Share on other sites
Texture coordinates can be outside of the range of 0.0 to 1.0. If this is the case then the texture just repeats if the addressing mode is set to wrapping.

##### Share on other sites
Hey,

Well I thought I had it down, but I seem to have problems with the creation of some of my lightmaps. It worked fine in a simple level which consisted of a cube with a ramp and a wooden platform, but now loading a larger level, I get a nice whack of purple in places and I'm not too sure why. I thought the code to create the lightmaps was working well....but maybe someone can spot an error:

for( int i = 0; i < m_pLevel->levelGetNumberOfLightmaps(); i++ )	{		// create the texture at index i, we'll make this		// dynamic so we can clear it out and re-write later		D3DXCreateTexture( DXUTGetD3DDevice(), 128, 128, D3DX_DEFAULT, 0,						   D3DFMT_X8R8G8B8, D3DPOOL_MANAGED,						   &m_pLightmaps[ i ].m_d3dtTexture );		// get the lightmap's surface descriptor		m_pLightmaps[ i ].m_d3dtTexture->GetSurfaceLevel( 0, &pLightmapSurface );		// lock the texture's entire surface, this gets us		// ready to begin writing out the pixel information		pLightmapSurface->LockRect( &rect, NULL, 0 );		// get the surface information in bit form, this will		// allow us to write out the information pixel by pixel		pTextureSurface = static_cast<unsigned char*>( rect.pBits );		dwBitsPerRow = rect.Pitch;		// loop through all items in each row, Quake III		// stores this information in 128 pixels		for( int x = 0; x < 128; x++ )		{			// get the current index into the surface			DWORD dwIndex = x * dwBitsPerRow;			// loop through all items in each column, Quake III			// stores this information in 128 pixels as well			for( int y = 0; y < 128; y++ )			{				// get the RGB elements out of the array, we need				// to adjust the gamma so they're a little brighter				float fRed =	static_cast<float>( m_pLevel->levelGetLightmapAtIndex( i )->ucImageBits[ x ][ y ][ 2 ] );				float fGreen =	static_cast<float>( m_pLevel->levelGetLightmapAtIndex( i )->ucImageBits[ x ][ y ][ 1 ] );				float fBlue =	static_cast<float>( m_pLevel->levelGetLightmapAtIndex( i )->ucImageBits[ x ][ y ][ 0 ] );				float fScale = 1.0f;				// we'll brighten them up by a factor of 10, this will				// still give a nice effect without blowing the user's eyes				fRed = fRed * ( 10 / 255.0f );				fGreen = fGreen * ( 10 / 255.0f );				fBlue = fBlue * ( 10 / 255.0f );				// check if the red went past the highest value				if( fRed > 1.0f && ( ( 1.0f / fRed ) < 1.0f ) )				{					// set the new scale					fScale = ( 1.0f / fRed );				}				// check if the green went past the highest value				if( fGreen > 1.0f && ( ( 1.0f / fGreen ) < 1.0f ) )				{					// set the new scale					fScale = ( 1.0f / fGreen );				}								// check if the blue went past the highest value				if( fBlue > 1.0f && ( ( 1.0f / fBlue ) < 1.0f ) )				{					// set the new scale					fScale = ( 1.0f / fBlue );				}				// get the scale for this pixel				fScale *= 255.0f;				// multiply all our pixel values by this scale				// this will keep them constant but brighten them				fRed *= fScale;				fGreen *= fScale;				fBlue *= fScale;				// setup the alpha information for all four bytes				pTextureSurface[ dwIndex + y * 4 + 0 ] = static_cast<unsigned char>( fRed );				pTextureSurface[ dwIndex + y * 4 + 1 ] = static_cast<unsigned char>( fGreen );				pTextureSurface[ dwIndex + y * 4 + 2 ] = static_cast<unsigned char>( fBlue );				pTextureSurface[ dwIndex + y * 4 + 3 ] = 255;			}		}

I'm going to continue investigating the problem in case this isn't it, but I can't really seem to find anywhere else where the problem might be arising from.

Permafried-

##### Share on other sites
Your brightening method seems somewhat bizarre .. try using a power curve if you really need gamma correction. Also Q3 uses a gamma ramp where 0-128 is a linear or power ramp and 128-255 just is max, to be able to have intermediate blending results above 1.

##### Share on other sites
Hey,

Thanks for the reply, I tried commenting out the code which handles gamma correction, and sure enough the ugly purple blotches disappeared so this seems to be the root of the problem. My ultimate goal would be to do this in hardware rather than through this algorithm but I'm still searching on how to accomplish this.

Anyone have any ideas on this, and if not, would anyone know of any good links explaning different means of apply gamma correction?

Thanks again everyone,

Permafried-

[Edited by - Permafried- on August 22, 2004 2:14:03 PM]

##### Share on other sites
Hey hey, I am curious about what you have done, is there a way for you to write a follow up article or perhaps post what you have made ?? I am learning a lot of this stuff too trying to make sense of it all !

##### Share on other sites
A gamma ramp is the way to go so you don't have to do all this yourself, however, if you want this to run in a window, you can't use the gamma functions (they only work in fullscreen mode IIRC).

You can see a screenshot of my viewer here

##### Share on other sites
Don't render the faces as triangle fans, maps compiled with later bsp-compilers don't use triangle fans and you will get som pretty ugly results. Most web pages describing the format got this wrong.

Instead render as triangles with struct face.vertex as the start of the list of vertices and the meshverts starting at struct face.meshvert through struct face.n_meshverts as indices starting from struct face.vertex.

That might sound confusing, basically just take the meshvert indices of the face and index the list of vertices starting at the particular index given in the face by the vertex member.

This works with old and new maps without any problems and it's also the way to render type 3 faces (models) so if you get this down you'll be able to see all the models as well.

Good luck!

##### Share on other sites
Fiskbil,

I think I've finally run into the issue you were talking about in regards to triangle fans. All I got was a whack of geometry all over hell's half acre with textures mapped here and there. I'd have to say it gave me my laugh for the day....but now I'm confused on how to implement what you mentioned in your last post.

Does this mean I require an index buffer as well as my vertex buffer...and I populate the index buffer with the mesh indices...or do I want to call DrawPrimitive() in a loop using the meshes? Everything I've tried up to this point has ended up in my world being warped beyond belief with holes, missing textures and tears all over the place.....and I can't seem to exactly figure out what you're describing in code from your explanation.

Thanks,

Permafried-

[Edited by - Permafried- on September 9, 2004 4:47:13 PM]

##### Share on other sites
OK first you need to create an index buffer to go with the vertex buffer.

Then for each face you do the following:

1. Fill the vertex buffer with the vertices using the first vertex and number of vertices members of the face struct.
2. Fill the index buffer with the indices using the first index and number of indices members of the face struct.
3. Call SetStreamSource passing in your vertex buffer
4. Call SetIndices passing in your index buffer
3. Call DrawIndexedPrimitive passing in triangle list for the type and numindices/3 for the number of primitives.

This should get you started in the right direction although it doesn't work for bezier patches as they do not have indices. You have to actually do the math on them to calculate all the vertices and indices. Right now stick with rendering just the polys and meshes as they have indices included with them.

Good luck.
Let us know how you make out.

##### Share on other sites
Yzzid,

Good to hear from you again...and thanks for the much clearer explanation. I thought maybe I'd gotten away without having to use dynamic vertex and index buffers while rendering but apparently I'm right back to square one again. I'm assuming since I'll be rendering one face while preparing for the next that my framerate shouldn't suffer too too much though I'm trying to keep in mind what Circlesoft mentioned way back when this thread first started.

Thanks again and I'll let you know how it goes.

Permafried-

## Create an account

Register a new account

• ## Partner Spotlight

• ### Forum Statistics

• Total Topics
627661
• Total Posts
2978496
• ### Similar Content

• Both functions are available since 3.0, and I'm currently using glMapBuffer(), which works fine.
But, I was wondering if anyone has experienced advantage in using glMapBufferRange(), which allows to specify the range of the mapped buffer. Could this be only a safety measure or does it improve performance?
Note: I'm not asking about glBufferSubData()/glBufferData. Those two are irrelevant in this case.
• By xhcao
Before using void glBindImageTexture(    GLuint unit, GLuint texture, GLint level, GLboolean layered, GLint layer, GLenum access, GLenum format), does need to make sure that texture is completeness.
• By cebugdev
hi guys,
are there any books, link online or any other resources that discusses on how to build special effects such as magic, lightning, etc. in OpenGL? i mean, yeah most of them are using particles but im looking for resources specifically on how to manipulate the particles to look like an effect that can be use for games,. i did fire particle before, and I want to learn how to do the other 'magic' as well.
Like are there one book or link(cant find in google) that atleast featured how to make different particle effects in OpenGL (or DirectX)? If there is no one stop shop for it, maybe ill just look for some tips on how to make a particle engine that is flexible enough to enable me to design different effects/magic
let me know if you guys have recommendations.
• By dud3
How do we rotate the camera around x axis 360 degrees, without having the strange effect as in my video below?
Mine behaves exactly the same way spherical coordinates would, I'm using euler angles.
Tried googling, but couldn't find a proper answer, guessing I don't know what exactly to google for, googled 'rotate 360 around x axis', got no proper answers.

References:
Code: https://pastebin.com/Hcshj3FQ
The video shows the difference between blender and my rotation:

• By Defend
I've had a Google around for this but haven't yet found some solid advice. There is a lot of "it depends", but I'm not sure on what.
My question is what's a good rule of thumb to follow when it comes to creating/using VBOs & VAOs? As in, when should I use multiple or when should I not? My understanding so far is that if I need a new VBO, then I need a new VAO. So when it comes to rendering multiple objects I can either:
* make lots of VAO/VBO pairs and flip through them to render different objects, or
* make one big VBO and jump around its memory to render different objects.
I also understand that if I need to render objects with different vertex attributes, then a new VAO is necessary in this case.
If that "it depends" really is quite variable, what's best for a beginner with OpenGL, assuming that better approaches can be learnt later with better understanding?

• 10
• 12
• 22
• 13
• 33