Interface for 3D Models?

[Formats]
I've looked into these file formats aswell before chosing MS3D, .OBJ has the big disadvantage (like .3DS) of being popular but ancient and not supporting skeletal animation (..and if I bother writing a Model loader i want animations too). Alias .FBX and Collada both looked promising but there are no official specifications for FBX. Collada is well documented but also very young and updated regularly, which implies alot of updates to the loader and/or version conflicts.

A drawback of MS3D is that you cannot have more than 64k vertices/triangles per model, but that should be enough for a long time for real-time content. To my knowledge Gears of War is currently the polycount king, by using 10k triangles per character. Using more than that will most likely not yield any visual improvements (you already need to use a magnifying glass on a Screenshot to find any sharp edges, and you will definitely not notice any while the model is in motion) unless screen size and resolutions increase dramatically.

[Parsing]
Reading the chunks from MS3D works pretty much like this: first there is an 16-Bit ushort numVertices in the file, then theres numVertices times the Vertex struct. Skipping parts of the file by advancing the stream's index by numVertices*sizeof(Vertex struct) should be doable, but you cannot skip reading numVertices.

I'll give your suggestion some thought, haven't considered that possibility yet since my plan was to load the complete Model first, translate it into an Shader-, Animation- and Vertex-Cache-friendly structure (which i hoped your Interface could specify) and do a binary dump from that into my own minimalistic file format. The reason is, that if you want more than OpenGL's fixed-function Gouraud shaded material and have more than 1 animation, it's necessary to write some kind of editor that allows to define materials and a way to group the animation-keyframes into sequences like walking forwards/right/left/back, jump, attack, etc. (milkshape exports all animations as a single large array of keyframes). At this point I do not intend to provide a complete animation library including editors, what I had in mind is providing the loader and a simple demo application that shows how to render a model with fixed-functionality and skinning. The possibilities how to define the materials and sequences are too numberous to do a simple abstraction for such a library IMHO.

Saving MS3D is not much more difficult than parsing it (since you have to understand the file format either way), but involves alot more error checking. Right now I do not see any use for that, except for a mesh editor application? Considering a converter, you should know that Milkshape itself can import several dozen different formats (and there exist plugins and a SDK for more), so even if a developer team has several artists each using different modelling/animation packages there will be a way to import the file into Milkshape and save out a .MS3D (we did exactly that for a HL Mod).

I haven't given deployment much thought yet, I was hoping someone was already working on Model loaders for OpenTK and could provide an Interface to pass the parsed data to, I wouldn't mind if it was simply included into your library. It's not a commercial enterprise, after all I've chosen Milkshape also because of it's low-cost-yet-powerful nature ...and no, although this may sound like a PR campaign, i'm not working for the developers of Milkshape :P It's simply the best option I found for my requirements.

-Inertia

There are two free math libraries for .Net that I know of, dotnum and Math .Net. The second seems active, but I don't think the first one is maintained anymore.

I am going to add basic Vector, Matrix and Quaternion functions in OpenTK, but this is in the back burner right now. If you do write some math functions yourself, I'd love to add them in OpenTK (there's only so much a single developer can do!). However, I don't think that a pure managed solution will be fast enough for skeletal animation - but that's another story entirely.

In any case, I think model loading/optimisation/animation is best left to higher-level libraries, with OpenTK/Tao providing access to the low-level rendering functions. Any other solution would be too limiting. The only reason I am/was thinking to write a simple loader, is to add some more complex demos for OpenTK.

I would be very interested in a common parsing of 3D model formats. It is not an easy task though.

I have been (very slowly) working on a simple model editor.
http://www.golem3d.com
It currently only supports mesh animations, and if I ever get the full feature set finished for that, I have designed the code to support skeletal animations in the future.

I converted it to use OpenTK from Tao today, and it seems to work well.

It seems like we would need two common parsing formats, one for mesh animations, and one for skeletal animations.

Thanks. It is a fun pet project.

Most mesh animated models have the exact same number of vertices for each frame. This allows smooth interpolation between frames for all vertices. Normals for each vertex in each frame are also stored. There is one texture coordinate for each vertex of the model.

The only real format my editor supports currently is the Quake II (.md2) format which is exactly above. It is a lossy format that compresses the values down to a short and has a scale and translation for each frame to change the short back to the right values. The standard frame rate for quake II models is 10 fps.

Golem3D has a plugin architecture for model formats. I have a lot of plans for it, including skeletal support (eventually), but it all takes a good bit of time.

One format I have looked at is the Ogre3D engine model format. They use binary formats but have a converter to convert to an XML format. There is one file for the mesh (no animation in it) and a separate file for the skeletal animation that can be applied to the mesh. I have found that their implementation is pretty well thought out. I think that would be a good place to start if writing up some requirements.

The nice thing about an XML format is that someone can write a XSLT transform that can convert the XML into another format. The problem with XML is that the files can get really large. But drive space is getting cheaper and cheaper so that may not be an issue.

James

I've found something that goes into the direction of what I had in mind when originally starting this topic, the file Examples/Shapes/Shape.cs in the OpenTK distribution attempts to mimic an interface like I had in mind.

Is this serious, or just an example to workaround the lacking GLU objects?

What I really had in mind is something like this to specify a Geometry Interface:

fully abstract class iMesh3D
    {
        struct Vertex;
        Vertex[] Vertices;
        uint[] Indices; // ~1 billion Quads
        byte VertexCacheOpt; // 0 if none, otherwise the Vertex Cache size the mesh is optimized for.
        BeginMode PrimitiveType; // Points? Tristrip? Quads?
        bool UseDrawElements; // else use GL.DrawArrays
        uint RangeStart, RangeEnd; // RangeEnd==0 draw all
        Material matter; // which shader/tex must be bound to draw
        uint VBO;
        uint IBO;
        byte Validity; // bitmask to check array state
        // ClientMemVertices = 0x01, ClientMemIndices= 0x02, VBOVertices = 0x04, VBOIndices = 0x08
    }

and some base class derived from it, defining a default Vertex. Note that this does not include Orientation or a Draw() method, it's rather an interface so model loader, editing-, optimizing- and rendering-functions have an common interchange type.

The scope is solely providing an abstract definition of a Mesh, the above mentioned functions can operate on. Note that this class only specifies a Mesh, not a Model.

Guess GL3 leaves no choice but VBO, so it makes sense to include this into the definition, but it's just an assumption that VBO will largely stay the same. Not all members of the class are necessary, some may be missing. The idea is to describe only the mesh itself, so it can be copied into a VBO and remember the necessary states for drawing.

The suggestion is based on accessibility of the vertex list, while the array sent to Gl.BufferData() is already created. This can be fed to GL.Interleaved or have Pointers set manually with strides.

struct Vertex
        { // GL_T2F_N3F_V3F style layout
            public Vector2 UV;
            public Vector3 Normal;
            public Vector3 Position;
        }
Vertex[] Verices;

The typical use of this mesh class would be either generating procedural geometry or importing from disk, which can then be edited/noise applied/scaled/optimized or directly sent into the VBO. If the user wants to write his own separate management and solely take VBO/IBO handles from an object that should be fine aswell.

Edit: I'm kinda stuck with this interface though and don't think I can complete this on my own. Some design questions aren't easy to solve (namely the Vertex-struct, whether the Material should be included aswell and if it'd be desireable to serialize a Mesh instead of a custom file format for storing it).

Edit2: Another approach, compacted but split into 3 interfaces (DrawArrays, DrawElements 16Bit Indices and 32Bit). Doesn't solve the biggest Problem (struct Vertex) tho. It would have been really handy to have this kind of interface available when writing the Torusknot generator, it could have been easily fed into these layouts.

fully abstract class iTopologyNoIndex
    {
        struct Vertex;
        Vertex[] Vertices;
        BeginMode PrimitiveType; // Points? Tristrip? Quads?
        uint VBO;
    }
 
fully abstract class iTopologyUint16
    {
        struct Vertex;
        Vertex[] Vertices;
        ushort[] Indices;
        byte VertexCacheOpt; // 0 if none, otherwise the Vertex Cache size the mesh is optimized for.
        BeginMode PrimitiveType; // Points? Tristrip? Quads?
        uint VBO, IBO;
    }
 
fully abstract class iTopologyUint32
    {
        struct Vertex;
        Vertex[] Vertices;
        uint[] Indices;
        byte VertexCacheOpt; // 0 if none, otherwise the Vertex Cache size the mesh is optimized for.
        BeginMode PrimitiveType; // Points? Tristrip? Quads?
        uint VBO, IBO;
    }

These 3 could inherit from a base class, namely the BeginMode is inevitable and the Vertex-related definitions.

@Fiddler:
b) I consider this a bare minimum of must be known about the mesh. While it's clear what my requirements are, I'm not certain how to properly abstract this to a lowest denominator for all User's needs.

hey, at least it compiles!
Indeed, and thank you for analyzing the problem. At some point you are so deep in the woods that you cannot see the forrest anymore because of all the trees ;)

Separating the Vertex from the collections is a good move, I just think there must be at least 1 default Vertex for model loader / generators to use. It should not be the generator's responsibility to figure out what attributes it can fill in the given Vertex, but rather fill a default structure. The user could either derive his custom vertex layout from the default used by the loader/generator, or create a whole new and convert between the 2 meshes.
A default vertex layout would also clearly define what attributes a model generator must supply, while Position and Normal are not optional, Color and UV can be very difficult to determine.

Regarding the hiding of DrawArray/Elements there is one problem. At least for the MS3D format, all mesh data in the model is stored to be used with DrawArrays. I'm converting this into an indexed trilist, but this must be somehow transparent to the programmer what kind of data he got. If you don't want 2 mesh formats, maybe a 3rd class MeshState could describe the current mesh, if you dislike the way I used members to track the state.
Same applies for BeginMode, the Torusknot can be generated as a triangle-strip or indexed tri-list (and it would be easy to add the other modes beside GL_TRIANGLE_FAN and GL_POLYGON ). Without the knowledge in what mode we're working you cannot properly draw the mesh. In this spirit, you can even go one step further and include the face winding (CW? CCW?) or Material like I did. This could all be hidden by passing those properties into the load/generate functions instead of tracking them with the mesh, but this would make a common file format for saving to disk rather useless.

At the very least the BeginMode must be known by the draw functions, you can still make assumptions if the mesh is intended for use with DrawArrays by checking the presence/size of the Indices array. The face winding should imho be assumed to be always the OpenGL default, it is very easy to revert the winding manually to CW, if you have an exisiting mesh with CCW faces.

[vertex formats]
This probably should be closer examined what formats are good candidates for such a default, ofcourse this should never limit a consumer to this only format. The idea is just to have a lowest common denominator all GenerateBox, GenerateSphere, etc. functions can fill without any problems.

[indexing]
we already know from Beginmode (or an appropriate enum) which primitive type the mesh consists of, this information is needed no matter if we Draw-Array or -Elements.
Although it's a bit of a hack I start liking the idea to determine whether a mesh is for Draw-Array or -Elements by examining the Indices. You can safely assume that if there exists no Index-Array/IBO the mesh is not for DrawElements.

[face winding]
Like I said before, face winding is probably best solved by setting one of the possibilities as default. It's very easy for the user to convert between windings, but also makes it for programmers easier to write Generate* functions with only one winding in mind. If that winding is OpenGL default, this problem will be completely hidden from beginners.

[Material]
As an example, here the material supplied by MS3D:

public struct Material
    {
        public Vector4 Ambient;
        public Vector4 Diffuse;
        public Vector4 Specular;
        public Vector4 Emission;
        public float Shininess;
 
        public string TextureFileName;
        public string AlphaFileName;
    }

This isn't very usable in this state, but that's what is read from the file.

[Mesh]
Like you said, it's a collection of Vertices indexed by either order of appearance (DrawArrays) or by a separate list (DrawElements).

Just to make this more clear: In my definition, a Model (let's use a human wearing glasses as example) is described like these components:
-3 Meshes: The naked Body (Mesh 1), clothing and the frame of glasses (Mesh 2), the transparent glass (Mesh 3)
-3 Materials: 3 Materials in this case, one to display skin, one to display cloth/plastic and one to display glass.
-Optional: 1 Skeleton: The bind pose for skinning, a huge collection of Keyframes for animation for this skeleton.
-This can be extended now at heart's content, Matrix4 Orientation, Collision/Physics attributes etc.

I don't think sharing indices between meshes is something that will be used alot (it could be interesting for LOD though), but sharing parts of the material is quite desireable (e.g. different meshes might have unique textures but all require the same shader program bound). I haven't given Material/Skeleton abstractions much thought tho, for me a Material is 3 ints for GPU program and 2 Textures returned from Managers.

[OT]
Good to hear that it compiles under mono at all, my first OpenGL program I asked ppl to test didn't run on any ATi cards at all ;)

The 3ds material format is... interesting. (Mtl is just plain awful - or maybe it was the SGI Performer/CAVElib combination shudders)

Where do shaders fit in the grand scheme of things? Should they be attributes of the material format?

Maybe the approach so far was wrong, it could be much simpler. The .dds loader doesn't return you the image either, it returns you a valid Handle you can bind already, and a little information about the image dimension (Tex2D? Cubemap?). Why shouldn't the model loader/generators behave similar?

sealed class VboMesh
{
 public int VboHandle;
 public int IboHandle; // 0 == none
 public object Vertex&MaterialDeclaration;
 public eType IboType; // byte, ushort, uint, ulong?
}

I didn't really like using a collection/container for the Vertices, if you have the knowledge to write a function that can for example renormalize all normals in the VBO by using face normals, you should also know how to extract the data from the VBO and stuff it back in.

The "object" would need some formating, so you can figure out the offsets/strides to interleave the VBO correctly, but this approach might be much easier to handle for a new user than the old ones.
Any Thoughts?

my bad, i've mistaken this with irc. This is more of a "maybe this approach is better" note, than suggestion v1.0 final. The idea is that the object could contain whatever information you have about the model, which does not directly affect the VBO/IBO.
This could be BeginMode, IBO Type, Comments from modelling app, bone colors, skeleton, frames etc.

Edit: directly using VBO/IBO is probably a bad idea, because it complicates the use of the models with immediate mode and display lists alot. It also wouldn't serve the purpose of a middleware to import data from a modelling application, and save that out into your renderers custom format.
The older approach with the abstract Vertex struct is way more flexible.

This is an old topic. I wonder by now has anyone incorporated a DirectX file (file.x) import into OpenGL c# (Tao or OpenTK) or any pointer/reference.