D3DX Meshes
Author
Hey guys,
I've been working with D3DX meshes to use in my 3d engine. My first question is, is it considered bad practice to have a class inherit from a D3DX interface? For instance, I have a cMesh class and it currently inherits from ID3DXMesh. I didn't think it would work at first, but I didn't receive any errors. I just have never heard of anyone using this.
Second, what is the best way to integrate D3DXMeshes into my physics engine? A major portion of my physics engine relies on accessing vertex data: collision detection (triangle/triangle), rotational dynamics, center of mass, etc. My current understanding is that the Lock method (using readonly) will create a duplicate buffer of vertices and return that instead of the actual vertex data. If that is true, wouldn't that be an extremely slow way to just read vertices? What is the fastest way to access vertex data in a mesh?
Thanks a lot.
- Enosch
Quote:My first question is, is it considered bad practice to have a class inherit from a D3DX interface?
If the purpose of your cMesh class is to encapsulate mesh functionality then you will want to use an instance of a D3DX mesh instead of deriving from it. For example you probably wouldn't want to have other classes locking the mesh's attribute buffer, there should be mesh function to encapsulate this functionality.
Quote:Second, what is the best way to integrate D3DXMeshes into my physics engine?
That depends on a lot of things, most of which are details of your physics engine. In any case, you probably wouldn't use the same geometry for rendering as for collision, and the collision geometry would be stored in system memory, so locking will be very efficient.
Quote:Original post by Enosch
Hey guys,
I've been working with D3DX meshes to use in my 3d engine. My first question is, is it considered bad practice to have a class inherit from a D3DX interface? For instance, I have a cMesh class and it currently inherits from ID3DXMesh. I didn't think it would work at first, but I didn't receive any errors. I just have never heard of anyone using this.
As James has mentioned. If you want to extend the functionality of the class then by all means derive from it.
I usually just encapsulate the Mesh and provide simplistic methods for my resource manager to handle the class. This might not scale well thought and i'd wait for further comments about this if you are serious about extending the class's functionality.
Quote:Original post by Enosch
Second, what is the best way to integrate D3DXMeshes into my physics engine? A major portion of my physics engine relies on accessing vertex data: collision detection (triangle/triangle), rotational dynamics, center of mass, etc. My current understanding is that the Lock method (using readonly) will create a duplicate buffer of vertices and return that instead of the actual vertex data. If that is true, wouldn't that be an extremely slow way to just read vertices? What is the fastest way to access vertex data in a mesh?
You can definitely get access to the VertexBuffer and IndexBuffer's of a mesh. ID3DXBaseMesh::GetVertexBuffer() and ID3DXBaseMesh::GetIndexBuffer().
I'd recommend that locking resources should be considered a last resort if all else fails. It's usually slow.
I hope this helps.
Take care.
lets not forget that ID3DXMesh is a COM object so you would not be able to call a constructor for your derived class... <hope im not wrong here> ;P
I would just use CMesh as an adaptor type class.. make functions to reference the the parts of the ID3DXMesh you may need...
as for the getting the vertex data.. have a vector or vector3 to hold your position vertices, or what ever else you need
good luck
I would just use CMesh as an adaptor type class.. make functions to reference the the parts of the ID3DXMesh you may need...
as for the getting the vertex data.. have a vector or vector3 to hold your position vertices, or what ever else you need
good luck
Well,
I don't think there is a good way to incorporate ID3DXMesh into a physics engine, for the following reasons:
1. Lock operations on managed VBs are expensive.
2. The vertex information stored within a mesh is usually optimized for rendering efficiency, not collision queries. For collision, geometry is either stored in a different way or another method is used to make tests faster (for example: bounding volume hierarchies)
3. Rendering geometry is usually more detailed than collision geometry (or, should be in most cases). If your mesh has a lot of faces this means collision tests will be slow. This is the reason we use proxy geometry which is more simple (yes, requires maintaining an additional data set)
4. There are other surface properties that might be useful for the benefit of the physics engine which don't exist in the ID3DXMesh. This means that your derived class (or your adapter, depending on what you decide to do) has to encapsulate the new properties in some way. IMO this will clutter your design.
I don't think there is a good way to incorporate ID3DXMesh into a physics engine, for the following reasons:
1. Lock operations on managed VBs are expensive.
2. The vertex information stored within a mesh is usually optimized for rendering efficiency, not collision queries. For collision, geometry is either stored in a different way or another method is used to make tests faster (for example: bounding volume hierarchies)
3. Rendering geometry is usually more detailed than collision geometry (or, should be in most cases). If your mesh has a lot of faces this means collision tests will be slow. This is the reason we use proxy geometry which is more simple (yes, requires maintaining an additional data set)
4. There are other surface properties that might be useful for the benefit of the physics engine which don't exist in the ID3DXMesh. This means that your derived class (or your adapter, depending on what you decide to do) has to encapsulate the new properties in some way. IMO this will clutter your design.
Thanks a lot, that was exactly what I needed.
Since the VB data is stored for rendering optimization, if I modify vertex data in a VB (using the offset and size params), will it hit the correct vertex? The reason I am asking is, since I will keep a copy of the VB data in system memory in application optimized format, when I modify a specific set of vertices (say at indices 5-10) in my system copy, if I modify the VB data at those indices (the render-optimized copy) will it modify the vertices I am trying to modify? (whew, that was longer than I thought it would be, and probably as clear as mud)
On the physics part, does anyone know of any algorithms that will produce a lower resolution version the mesh data. Or is the common thing to just model 2 meshes, one at hight res and one at low res. I was planning to add LoD support for meshes anyways and as far as I know having 2 versions of the same mesh is the common way of doing this, so this would just be a step in that direction.
Thanks again for all the support.
- Enosch
Since the VB data is stored for rendering optimization, if I modify vertex data in a VB (using the offset and size params), will it hit the correct vertex? The reason I am asking is, since I will keep a copy of the VB data in system memory in application optimized format, when I modify a specific set of vertices (say at indices 5-10) in my system copy, if I modify the VB data at those indices (the render-optimized copy) will it modify the vertices I am trying to modify? (whew, that was longer than I thought it would be, and probably as clear as mud)
On the physics part, does anyone know of any algorithms that will produce a lower resolution version the mesh data. Or is the common thing to just model 2 meshes, one at hight res and one at low res. I was planning to add LoD support for meshes anyways and as far as I know having 2 versions of the same mesh is the common way of doing this, so this would just be a step in that direction.
Thanks again for all the support.
- Enosch
If you need to access and modify the vertex buffer of a mesh a lot (like very frame or so) then you should put it in dynamic memory.
For physics, you can start with a simple bounding box or bounding sphere test, and then only do an actual mesh test (with D3DXIntersect) if the first test is positive and you want to really be sure. You would create a progressive mesh if you want to create a simpler one for intersect testing.
For physics, you can start with a simple bounding box or bounding sphere test, and then only do an actual mesh test (with D3DXIntersect) if the first test is positive and you want to really be sure. You would create a progressive mesh if you want to create a simpler one for intersect testing.
Quote:Original post by voguemaster
1. Lock operations on managed VBs are expensive.
Locking a managed mesh (or any managed resource for that matter) with the D3DLOCK_READONLY flag should not be expensive. I would imagine it can honor that quite easily and quickly by accessing the system side memory/copy of the resource (since all managed resources are back up by a system memory copy).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement