D3DXMesh
category: general [glöplog]
Any reasons to not use it? Up till now I always wrote my own similar classes, but as I am heavily rewriting my engine codebase I thought why not use existing stuff. I know there is no equivalent in GL, but I ditched the idiotic "but it needs to be cross-platform" idea anyway.
Anyone using it? Experiences? Performance problems?
What about ID3DXSkinInfo?
(And no I am not talking about using .X files - I will be using lightwave..)
Anyone using it? Experiences? Performance problems?
What about ID3DXSkinInfo?
(And no I am not talking about using .X files - I will be using lightwave..)
I'm using it, and I'm pretty happy with it.
ive written an engine years ago with the d3dx stuff.. it worked all pretty well and i didn't get to major limitations. but after "testing" that stuff i would stay in the write the complete thing for yourself.. however that skinned animation stuff and for instance the vertexcacheoptimizers arent that easy to implement on your own.. ;)
decent vertex cache optimization code comes out pretty short, actually. :)
great, thanks for your inputs! of course there are also nice vertexcacheoptimizer-libs out there (nvTriStrip, the one by Tom Forsyth etc.)...
so i will be having a closer look at the D3DXMesh stuff then..
so i will be having a closer look at the D3DXMesh stuff then..
I tried it a few years ago. My biggest problem with it was that it uses a single vertex buffer + FVF - i wanted to use multiple vertex buffers and vertex decls. Not sure how you would support instancing either. Maybe it's been improved since though.
If you only want the optimisation functions, those work with just plain index and vertex buffers so you probably dont need d3dxmesh for that.
If you only want the optimisation functions, those work with just plain index and vertex buffers so you probably dont need d3dxmesh for that.
smash: hm, regarding instancing/multiple VBs you have a good point. But maybe using multiple D3DXMeshes for this might do the trick (one for mesh data, one for instance data)? something like
Will have a look into this when I get home..
Code:
class Mesh
{
public:
void DrawSubMesh(...);
void DrawInstanced(...);
u8* LockVertexBuffer();
u8* LockIndexBuffer();
u8* LockInstanceBuffer():
...
protected:
ID3DXMesh* mMesh;
ID3DXMesh* mInstanceData;
};
Will have a look into this when I get home..
jar_: There are reasons to use multiple vertex streams even without instancing. But in those cases I've simply not cared enough to actually do it. I've usually had a demo to make as well, you know ;)
For instancing, I've had the instance data separated from the rest, and looked up the vertex buffer from the d3dxmesh (so I've had to code the drawing-routine myself, but that's dead trivial) - quite similar to what you proposed. Worked for me.
For instancing, I've had the instance data separated from the rest, and looked up the vertex buffer from the d3dxmesh (so I've had to code the drawing-routine myself, but that's dead trivial) - quite similar to what you proposed. Worked for me.
btw, the coolest thing in d3dxmesh is the mesh simplification + progressive mesh generaton. :)
just wondering: what are those common scenarios where having multiple vertex streams come in handy? (For CPU geometry modification I could think of seperating the static (texcoords, etc.) from the modified data, but I guess most of those slimevector/blobdeform/skinning stuff can be done inside the shader nowadays..)
jar_: Use your imagination :)
One example could be geometry that is rendered in multiple passes, where tangent/normal information isn't needed for all passes. You could save quite a bit of bandwidth by not reading it.
One example could be geometry that is rendered in multiple passes, where tangent/normal information isn't needed for all passes. You could save quite a bit of bandwidth by not reading it.
jar: separating static and dynamic; reusing vertex streams, e.g. sharing vertex data for two uv streams if they are the same; and being able to have more options for vertex data formats - e.g. you can compress your texcoords, normals and tangents to 8 or 16 bit using vertex decls, whereas fvfs dont let you do that (erm, that i remember).
isn't d3dxmesh deprecated in dx10? or is it just the .x format?
there is ID3DX10Mesh. I think it's the X format that is deprecated (current temporay format is SDKmesh iirc).
kusma, smash: thanks for the insight. I guess this different scenarios also mean that there can't be a single one-fits-them-all mesh class in the engine..
beware that loading .x-files via the d3dx-lib can be slow (both txt/bin formats). I had to save out the raw streams and dump them to disk in stargazer in order to get a reasonably short loadingtime. that's right, i dont give a damn about filesize.
the progressive mesh generation smash mentioned is nice though. Kusma also pointed out to me that there is a generate X - file function: say you've got some streams and you want to export it as .X (i.e. from a modelling tool). Some coders would then go on and read the .x-spec and sit for hours cursing, while others would simply call the magic function and be done with it.
also consider what 3dmodelling tools you will be using and check that there is a working exporter or that you can easily write a plugin.
the progressive mesh generation smash mentioned is nice though. Kusma also pointed out to me that there is a generate X - file function: say you've got some streams and you want to export it as .X (i.e. from a modelling tool). Some coders would then go on and read the .x-spec and sit for hours cursing, while others would simply call the magic function and be done with it.
also consider what 3dmodelling tools you will be using and check that there is a working exporter or that you can easily write a plugin.
I was working up my motivation to start working on a new demo, but this thread reminded me of how much I hate demo-"engines".
hyde: As stated in the first post I won't be loading .x-files. The tip for dumping geometry to .X is nice, though.
kusma: well, then use your non-engine approach and go for it! (or just make a beefed-up regus2 ;-)
yes, progressive mesh might be nice, but did anyone ever make use of it in a demo (except statix in "bleam")?
kusma: well, then use your non-engine approach and go for it! (or just make a beefed-up regus2 ;-)
yes, progressive mesh might be nice, but did anyone ever make use of it in a demo (except statix in "bleam")?
D3DXMesh...
the official proof that direct3d is beloved because coders are lazy ;)))
else... you may try... ASSimp ... it supports the d3d .x file format as well as many others... :)
cheers,
the official proof that direct3d is beloved because coders are lazy ;)))
else... you may try... ASSimp ... it supports the d3d .x file format as well as many others... :)
cheers,
There is also a mesh class in DX10 but most of the functions are removed. Hence the file size of the d3dx-dll is 1/8th of DX9. Somewhat liberating.. until you realize that you can probably use DX9 to create a mesh and convert it to DX10. Woe is us, lazy or not.
ok, so I did some prototyping yesterday night and finally decided to _not _ use D3DXMesh, but roll my own supporting multiple streams etc.
i hope this new design will also make instancing much simpler.
thanks for all the useful comments.
(oh, and nicestep: once again, I am _not_ using .X files - D3DXMesh is not in any way tied to .X files..)
i hope this new design will also make instancing much simpler.
thanks for all the useful comments.
(oh, and nicestep: once again, I am _not_ using .X files - D3DXMesh is not in any way tied to .X files..)
hye: well, i find writing mesh processing code a *lot* more interesting (and rewarding) than writing effects and shaders, so why would i use d3dxmesh when it means i have to skip the fun part and get back to the boring bits? :)
ryg: all im going to say is, thank fuck you've got a good artist working with you. :)
well i'm not the one writing effects anyway :)
mesh things are fun, but not as fun as coding plasmas x')