5 replies to this topic

[ill]

I'm trying to figure out the best way to support multimaterial meshes.

 

A. One way I was doing it before is to have one VBO and IBO for the entire mesh, and have different draw calls per material using glDrawRangeElements.

 

B. Another way that's much easier for me at the moment due to the tools that I have is to actually have the meshes split up per material, and have them be completely separate meshes with their own geometry.  To the Artists, it would still be as if they're working with one giant mesh to keep things convenient.

 

Either way I'd be currently sorting draw calls first by the material/shader and then by meshes themselves.

 

Since I'm doing this, I was wondering if there's any performance hit due to using large VBOs at all.

 

Let's say I'm doing option A and I have one giant VBO and IBO for the mesh.  Since all my draw calls are sorted by shaders and textures, I might bind the VBO for a large mesh, only draw a small portion of it, then bind another VBO for a different large mesh, and etc...  Then later, when it comes time to draw the other materials in the mesh, I bind that large VBO again, and draw another small portion of it.  Is this a concern for performance?  I was wondering if I'd be thrashing some cache or something.  I have no idea how this works within the GPU or if I should even worry about it.

[RobTheBloke]

C: One large VBO for all vertices / uvs / normals, and seperate IBO's for batches of polygonsthat use different materials.

[ill]

With the current system I have, I'd still be switching the VBO quite a bit.  Are you saying it's a good idea to load everything in the level into a giant VBO?

 

Also I'm still trying to understand batching by using only one draw call to draw a large amount of objects, especially if they all have different skeletal animation states.

[metsfan]

What he's saying is that you shouldn't think of the vertex buffer as a mesh or a material.  You should think of the VBO as a lookup table of all your verts.  Then, you can create many index buffers, to represent each mesh.  Then you do a draw call for each index buffer, and you can set your uniforms necessary to draw the material.  Now obviously where this falls apart is if you have vertex-specific information for different materials.  If this is the case, you will bloat vertices that don't require this information.  Hopefully your data doesn't have too much of that.  A simple way to solve this:  Group all vertices with a similar vertex layout in the same VBO.  Also, AFAIK, you don't want VBOs larger than say 5-6mb, so another exception would be if your meshes were extremely large, in which case you may want to break them out into smaller objects.

 

Best of luck.

Edited by metsfan, 19 March 2013 - 10:46 AM.

[ill]

My level will already be made of many many meshes and at the moment I have a VBO per mesh.  I never thought of trying to put all meshes in one VBO and having many IBOs.  I'm not sure I really want to either unless there are some nice performance benefits.  It may make loading between levels take much longer though since I may have to completely rebuild this VBO per level.  It would also probably make large worlds where portions of the world stream in dynamically more or less impossible.

[RobTheBloke]

My level will already be made of many many meshes and at the moment I have a VBO per mesh.  I never thought of trying to put all meshes in one VBO and having many IBOs.  I'm not sure I really want to either unless there are some nice performance benefits.  It may make loading between levels take much longer though since I may have to completely rebuild this VBO per level.  It would also probably make large worlds where portions of the world stream in dynamically more or less impossible.

 

You could get away with one vbo, and one ibo for all geometry if you really wanted. glDrawElementsBaseVertex might help with that kinda thing! Rebuilding vertex data on load is a bit silly. Rebuild that data offline, and then store into a format that allows quick loading.