Inertia's picture

.x loading

I'm currently working on a DirectX .x file loader for the OpenTK.Utilities.dll because of the widespread support for that format in modelling apps. My question is now, does anyone has an elegant solution how to evaluate template structs inside the .x file like this one:
template SkinWeights {
 <6f0d123b-bad2-4167-a0d0-80224f25fabb>
 STRING transformNodeName;
 DWORD nWeights;
 array DWORD vertexIndices[nWeights];
 array FLOAT weights[nWeights];
 Matrix4x4 matrixOffset;
}
you can safely ignore the UUID bit (and don't worry about the null-terminated string or matrix order either), but they are creating a new struct with these templates and use this further down in the file like this:
 SkinWeights {
    "Bip01_Spine";
    962;
    0,
.....alot more values.....
    7139;
    0.979254,
.....alot more values.....
    0.458862;
    -0.093409,-0.000001,0.995628,0.000000,-0.000000,1.000000,0.000001,0.000000,-0.995628,...;;
   }
Furthermore you are allowed to do this:
SkinWeights MySkinWeight {
"Bip01_Spine";
    962;
    0,
.....alot more values.....
    7139;
    0.979254,
.....alot more values.....
    0.458862;
    -0.093409,-0.000001,0.995628,0.000000,-0.000000,1.000000,0.000001,0.000000,-0.995628,...;;
}
and then use MySkinWeight as a reference somewhere else in the model. The template SkinWeights is just an example, templates can have an arbitrary number of members (which can be arrays aswell) Won't cite any of my approach as it will be ugly to maintain, and hopefully that also increases chances to get some fresh ideas.

Edit: trimmed a few values, they were breaking the layout.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Inertia's picture

Something like this:

VertexDeclaration bla = new VertexDeclaration( GraphicsDevice, VertexPositionNormalTexture.VertexElements );

you may derive from some Vertex base class to create custom layouts, have never bothered with it as the default declarations give quite good choices.

P.S: should we move this into pms? People might get confused and switch to XNA :p

Inertia's picture

After giving this some more thought, I believe it's a bad idea porting any XNA related stuff. When relying on XNA it would most likely be the best solution to simply write a Windows XNA app that acts as a model exporter. Binary dump all data from a model loaded with XNA into your custom file format (there really is no way around that, if you want a fast-loading and supporting-all-your-requirements model format) and write an importer for OpenGL. Writing an exporter ontop of XNA also brings additional benefits, such as support for any file formats XNA can load - the animation library does not support them all.

This will be problematic with MacOS|Linux, but the amount of work required to port the XNA stuff is huge, and even I am not eccentric and masochistic enough to do this. Writing custom loaders for .dds made sense, since this format is very important to 3D rendering (and relatively easy to load, compared to models), but porting this animation package is way beyond what utilities.dll needs to provide imho.

Another approach could be using XNA as a foundation and override the DirectX related methods to use OpenTK functions instead.

objarni's picture

my 2 cc: Building a "custom format exporter XNA app" seems sane ... then you can extract whatever information you think is important from any file formats supported by XNA

Inertia's picture

"Learn another API" might sound bad at first, but XNA is very easy to get into, and documentation through MSDN is good. You can get a (static) model loaded in less than 1 hour (without prior XNA knowledge) if you take a look at the examples that come with it.

The restriction that XNA will never evolve beyond DirectX9 is not a problem for such an exporter, and you can also chose how you want the mesh saved (serialize? binary? ascii? split skin&skeleton from animation and save in separate files? etc.). Those decisions are hard to make for OpenTK.Utilities.dll, because it's guaranteed that they will not satisfy everyone's needs.

I'm not saying OpenTK should not have any model loaders, but it should be carefully considered what makes sense here.

objarni's picture

Inertia: I agree about model loaders -- they will be a "moving target" all the time as the technology evolves very fast in this area. On top of that, the data stored in real-time models are, I hazard, quite custom game-per-game. But some loaders for arcane, simplistic formats would be nice for indie game development.

I'm sure there are lots of such simple formats with tons of models available on the net. Quake model format? Q2 models? Unreal models ? etc. etc. I'm not really knowledgeable in this area, I must admit... Convex polygons with single, packed textures + texture coordinates and normals would go far..

Inertia's picture

Indeed, the problem starts at "how many bones may influence a vertex at max.?", goes to "store vertex weights in a byte? [0..100] or [0..255]? use float [0f..1f]?" and can also be pushed to include a GI coefficient per vertex. Some people might want to store only the Normal vector for a vertex, some might want Normal & Tangent and derive the Bitangents via crossproducts, some might want to store all 3 vectors - just to give some concrete examples.

This is why I had already said in the other model-loader topic that the ms3d loader is just middleware to get the model from a modelling application into C# and not something one would want to use in a shipping game. Maybe add the ms3d loader to TKU.dll (my abbreviation of OpenTK.Utilities.dll from now on :P) as a sample how to write a loader with some custom optimizations, but atm I'm not certain anymore that I should finish the .x loader. There's 2 different .x loaders for XNA one could use (1 from the animation component library, 1 from XNA itself) which are debugged and available already.