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..)
added on the 2009-08-27 10:12:22 by arm1n arm1n
I'm using it, and I'm pretty happy with it.
added on the 2009-08-27 10:19:04 by kusma kusma
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.. ;)
added on the 2009-08-27 10:22:54 by mad mad
decent vertex cache optimization code comes out pretty short, actually. :)
added on the 2009-08-27 10:29:42 by ryg ryg
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..
added on the 2009-08-27 10:35:00 by arm1n arm1n
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.
added on the 2009-08-27 10:40:24 by smash smash
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
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..
added on the 2009-08-27 11:01:55 by arm1n arm1n
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.
added on the 2009-08-27 11:11:13 by kusma kusma
btw, the coolest thing in d3dxmesh is the mesh simplification + progressive mesh generaton. :)
added on the 2009-08-27 11:24:35 by smash smash
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..)
added on the 2009-08-27 11:37:17 by arm1n arm1n
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.
added on the 2009-08-27 11:41:48 by kusma kusma
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).
added on the 2009-08-27 11:43:12 by smash smash
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).
added on the 2009-08-27 11:54:55 by arm1n arm1n
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..
added on the 2009-08-27 11:58:21 by arm1n arm1n
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.
added on the 2009-08-27 11:59:08 by Hyde Hyde
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".
added on the 2009-08-27 12:22:50 by kusma kusma
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")?
added on the 2009-08-27 12:43:23 by arm1n arm1n

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... :)

added on the 2009-08-27 18:40:05 by nystep nystep
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.

added on the 2009-08-28 00:41:41 by Yomat Yomat
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..)
added on the 2009-08-28 09:11:02 by arm1n arm1n
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? :)
added on the 2009-08-28 10:14:15 by ryg ryg
ryg: all im going to say is, thank fuck you've got a good artist working with you. :)
added on the 2009-08-28 10:16:00 by smash smash
well i'm not the one writing effects anyway :)
added on the 2009-08-28 10:18:58 by ryg ryg
mesh things are fun, but not as fun as coding plasmas x')
added on the 2009-08-28 10:31:34 by nystep nystep