.x loading

You could use the stuff in System.Reflection.Emit to create an assembly at runtime that parses the values (or maybe a CodeDomCompiler). I guess the XmlSerializer actually does this sort of thing for performance reasons, so I imagine it would performan well here. I don't really know how easy it would be to do this sort of thing though.

"can the modeling program define templates in any way it would like?"

Yes, exporters can declare arbitrary templates. The only restriction I've seen so far is that the template must be abstract (declaration only, no initialization of values). There seems to be no restriction of member count, but probably there's a minimum of 1 required. You cannot declare new types with it though, only a selected number of integer/floats.

There's a number of default templates used to store mesh, animation, etc. which I had just hardcoded, but when throwing some test-models at it the problem with custom templates arose. I've started implementing what you mention as 2), but like I said in the initial post this will be a nightmare to maintain/debug for people who are not familiar with the specs and bit&byte pushing, and is very error-prone in general. I'm mostly looking for options that make sense here, the .Net framework is just too big to know every single class and hopefully someone has dealt with this problem before.

I've started reading about Reflection.emit, but current events keep me too occupied to give an educated answer if this actually meets the requirements. Will look into this more closely and write a prototype soon.

Yeah, that's what looked bad at the first glimpse at it and I haven't read enough about it to see if that can be avoided. There must be a cheaper way to achieve the same.

Another approach I had considered was using boxing to abstract which types are actually used in the template, and use a class instead of a struct. It would then internaly have 10 (or so) Object fields which are used to reference the boxed data. Feels to me more like a hack than a proper solution though.

well there's one for XNA which could probably be ported to OpenTK http://www.codeplex.com/animationcomponents

where's the fun/challenge in that though? :P

XNA has a couple of other questions answered where I'm trying to figure out a more "lightweight" solution for. E.g. the Vertex[] discussed in the other model loader topic, is solved in XNA with these classes iirc:

http://msdn2.microsoft.com/en-us/library/microsoft.xna.framework.graphic...
http://msdn2.microsoft.com/en-us/library/microsoft.xna.framework.graphic...

Pro/Contra regarding usage of XNA approaches:

Pro:
-the microsoft engineers probably put quite a bit of thought into their APIs before locking them down.
-tested, proven to work.
-the animation library does not only load .x, it also loads .bvh .asf .amc, which I believe are used in commercial motion capture environments (never had my hands on that equipment so cannot say for sure)
-major game development companies start to use .Net languages to code their tools, editors & Co. It's much quicker writing importers|optimizers in the robust .Net environment, and it doesn't exclude writing the "engine" in C++
-does not only provide loaders, but also means to playback the animations.

Con:
-Microsoft has designed XNA upon DirectX, with at least 1 eye on the XBox compatibility.
-Their "content pipeline" approach has either to be rebuilt, or replaced. Both is a considerable amount of work, which may actually exceed the effort required to cook your own.
-Other people might have done the first 90% of the work, but you may end up doing the 2nd (difficult) 90% of the library and still they do have the credit for doing the easy bits. The animation library's last update was 1 year ago, and it has 46 unresolved issues last time I checked.
-I've taken a look at their .x loader, and it will reject custom templates like:

Although the list of cons is longer, the pros do weight quite a bit. It'd probably be quite easy porting the .ms3d loader to feed the XNA vertex declarations, as the file formats are basically achieving the same. This applies for (possible, not planned) .fbx .md3 .md5 .dae (collada) loaders aswell.

Also a unified playback solution would be kinda nice, at least as a starting point.

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

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