Batching stuff from a .x file loaded in
So I have loaded in a bunch of .x files to render a scene. They are loaded into ID3DXMESH structures. I really want to figure out how to batch stuff together to speed up rendering (which is really slow), but I can't seem to find a decent tutorial that focuses on taking mesh data and putting it into normal vertex buffers and batching it.
Can anyone help me here, or point me toward a good tutorial that explains what I need?
I'm currently doing this with meshes that don't include different material subsets. It's not so hard...
What you need to do for batching is to have all vertex data related to the same material in the same buffer.
Copying data from one buffer to another is rather straight forward using lock, memcpy and unlock.
Some things to consider though:
- You may want to get information about FVF/Vertex Declaration from the mesh (there are simple functions for that, see the SDK documentation)
- When copying the indices you need to adjust them accordingly to be correct with the new merged vertex buffer.
- I think you could first use mesh optimization routines to sort the vertices by material and get info about the buffer offsets rather easily. This could be used to extract the subset of a mesh that uses the material you are currently treating. (Haven't tried it myself yet though, and maybe I'm wrong about it or there are better ways to do this, I only give you a suggestion...)
Let me know if you have problems understanding the above.
What you need to do for batching is to have all vertex data related to the same material in the same buffer.
Copying data from one buffer to another is rather straight forward using lock, memcpy and unlock.
Some things to consider though:
- You may want to get information about FVF/Vertex Declaration from the mesh (there are simple functions for that, see the SDK documentation)
- When copying the indices you need to adjust them accordingly to be correct with the new merged vertex buffer.
- I think you could first use mesh optimization routines to sort the vertices by material and get info about the buffer offsets rather easily. This could be used to extract the subset of a mesh that uses the material you are currently treating. (Haven't tried it myself yet though, and maybe I'm wrong about it or there are better ways to do this, I only give you a suggestion...)
Let me know if you have problems understanding the above.
Thanks for the response.
I guess i'm still a little confused though. I know that there is a command to get the vertex buffer for the mesh. Once I have the vertex buffer, though, how do I loop through the vertices one by one and get information about them like what material they use?
I guess i'm still a little confused though. I know that there is a command to get the vertex buffer for the mesh. Once I have the vertex buffer, though, how do I loop through the vertices one by one and get information about them like what material they use?
Look at the function ID3DXBaseMesh::GetAttributeTable in the SDK documentation. With it, you can retrieve a table of which vertices belong to which material subsets. But as it says in the docs you first need to optimize your mesh to have those vertices to be sorted by material.
Then when copying the vertices you do something like
1. Lock the Meshes vertex buffer
2. For each material in the mesh:
- Get the range from the attributetable using the current material index (the same that you would use for DrawSubset for that material, so you can probably get detailed material info the same way as you do when drawing).
- Offset the pointers appropriately using the vertexstride from the mesh and the range data you just obtained.
- Copy the data: Either the whole range in one memcpy call or vertex by vertex. If you copy it vertex by vertex and want to organize the data you can use the vertexdeclaration of the mesh. Personally I'm doing like that because I copy everything to my own mesh classes as an intermediate step. Of course you need to make sure to lock your target buffers accordingly, which may result in a bunch of simultaneously locked buffers if you don't take care. That's why I chose to have an intermediate structure (one for each material of course).
3. Unlock the VB
Another thing you might want to have a look at is the attribute buffer which contains a DWORD array with the DWORDs being the material index for each face. But I think the above would be easier, but it all depends on your needs.
Hope this clears some things up. Need to go to breakfast now...
Then when copying the vertices you do something like
1. Lock the Meshes vertex buffer
2. For each material in the mesh:
- Get the range from the attributetable using the current material index (the same that you would use for DrawSubset for that material, so you can probably get detailed material info the same way as you do when drawing).
- Offset the pointers appropriately using the vertexstride from the mesh and the range data you just obtained.
- Copy the data: Either the whole range in one memcpy call or vertex by vertex. If you copy it vertex by vertex and want to organize the data you can use the vertexdeclaration of the mesh. Personally I'm doing like that because I copy everything to my own mesh classes as an intermediate step. Of course you need to make sure to lock your target buffers accordingly, which may result in a bunch of simultaneously locked buffers if you don't take care. That's why I chose to have an intermediate structure (one for each material of course).
3. Unlock the VB
Another thing you might want to have a look at is the attribute buffer which contains a DWORD array with the DWORDs being the material index for each face. But I think the above would be easier, but it all depends on your needs.
Hope this clears some things up. Need to go to breakfast now...
OK I think i'm getting the idea a little better now. To get this up and running i'm not going to worry about the different materials, i'll just have it render the whole scene with one renderstate. Once I get that going, i'll then try to get it all going with different materials.
I can't quite try this out today, but hopefully tomorrow or something I can see how this translates out in my code. ;) Thanks for the help.
I can't quite try this out today, but hopefully tomorrow or something I can see how this translates out in my code. ;) Thanks for the help.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement