   [C++] Looking for easy to use, well documented, lightweight, 3D loader
  At this point, I'm willing to accept just about anything.  I've been digging through google for months off and on, and haven't ever been one step closer.  All I want to do is import basic 3D geometry and animations.  Ideally, it would be a format that both Blender and 3DSMax can operate on.  If Quake's .md2 and .md3 formats weren't so screwy with the normals (which I would prefer to be accurate for shading purposes), I'd just use one and be glad to be done.  .3ds is popular, but for all the tutorials out there, none of the ones I've encountered have even touched on animation.  Most of them brush off the subject saying "there's too many ways to do it" or "we'll get to that later."  Yes, even NeHe's are incomplete.  .dae, .fbx,and even .x are far too cumbersome to be appropriate for such a simple usage.I tried Collada DOM (no doccumentation) and FCollada, FBX SDK (that was an esoteric nightmare), admittedly I skipped over .x when even the directX guys complained about it, lib3ds has absolutely no documentation (I don't think it supports animations either).  Cal3D is apparently dead, as all of the download "mirrors" link back to the same dead page... I even  went so far as to check out converting to irrlecht and OGRE as a possible solution.  To be honest, all I want is a loader that loads a model and has a function that takes both a reference (name, number, I don't care - just something to represent an animation) and a delta (to represent the time, for interpolation) and spits out a vertex, normal, and texture-coordinate array for rendering.  It would be a downright miracle if I could query the location of a bone/tag/ect during an animation so that I could attach other models to it.So, for clarity's sake I'm asking this: Does anyone know of a simple, lightweight 3D loader?  As long as I can easily animate, attach to, and retrieve the vertex data from it, I'll take it.That rant aside, let me say this: Most threads like this (and I'm aware that there are hundreds - I've read plenty) terminate with "write your own" or "find one on google."  I ask you not to do this, as it's singularly unhelpful.  I've spent months on google, and as for the former, I code as a hobby, not a job, and I don't find studying dozens of file format specifications and trying to piece together how they're intended to work at all interesting.  I enjoy writing game logic, and learning all about the intricacies of 10 year old file formats has been not only frustrating but an effort in futility.  Is it really necessary for every coder to reinvent the wheel?  If I were looking for some sophisticated feature, I could imagine it being so... but basic geometry?  The first thing I learned about programming was never reinvent the wheel.  Please don't invite me to do so.P.S. Writing my own format is a suggestion that's cropped up many times... but I can't see how that is anything but much harder than using an existing one, considering I would have to do all the work of using the existing one in order to write a converter, or worse yet learn a completely new scripting language for Blender and 3DSMax to create an exporter.  The format may well be optimized, but it does nothing to alleviate the problem.   
Quote:Original post by ZouflainIf Quake's .md2 and .md3 formats weren't so screwy with the normals (which I would prefer to be accurate for shading purposes), I'd just use one and be glad to be done.You can compute the normals yourself. It should look something like this:for each vertex v    v.normal = (0, 0, 0)for each triangle t    triNormal = computeTriNormal(t)    for each vertex v of t   t.normal += triNormalfor each vertex v    v.normal.normalize()BTW, I agree that this is a problem, which is why I'm working on my own simple format that supports skeletal animation. I also wrote a converter (using the Assimp library) and a few demos that show how to use the format. So far I've made nice progress and I hope to release all of this in the next few weeks.   ;  On calculating the normals myself:Unless I'm mistaken, the center of the triangle is the mean average of the vertex positions within that triangle, and the normal of the triangle is the cross product of any two vectors from that center to a vertex, right?Thus, in something like psuedocode:vec3 center = (vertex[0].xyz+vertex[1].xyz+vertex[2].xyz)/3;vec3 normal = (vertex[0].xyz-center)%(vertex[1].xyz-center);//where % = cross productThen, to get the vertex normal from these face normals, I would just take the sum of these vectors and normalize it, right?  For some reason, I can't shake the feeling that I'll be getting the normal and -normal for the face without being able to discern the difference.As a side note, I've tried ASSIMP several times now.  When it was brand new (or at least when I first heard about it) it wasn't documented and wouldn't build for me.  Now I'm not so sure about the documentation, but it still wont build for me, and their prebuilt libraries are - by their own comments - poorly updated.  I'd love to use it, if someone can show me an example for a viewer and either help with the build errors or provide a link to a suitable prebuilt version (I'd like one for mingw's g++ and another for MSVS8).  I don't expect anyone to do that much work for me, however, so that's really just a hope and prayer.   ;  I'm not sure if your method for computing the face normal is correct, but I'm pretty sure the following method is correct:Vector3 e0 = v2 - v0Vector3 e1 = v2 - v1Vector3 n = cross(e0, e1)n.normalize()You have to make sure to take the cross product in the correct order, because it's not commutative.But like you said, this computes the face normal. It's incorrect to just assign it to the vertices because a vertex is usually shared by several triangles, each one with a different face normal.Instead, the vertex normal should be the average of the normals from all the faces that share it. This is how the vertex normals are computed in my previous post.   ;  I just happen to be looking for the same thing - and was perusing AssImp and its documentation.  There appears to be a viewer app included in the distribution, so you could check that out.  From what I've read, some support for animation is there but it depends on the specific format to know what is available...EDIT: I just downloaded the latest source from sourceforge, opened up the VC9 project and built it.  It compiled correctly, except for something in their unit tests...  Do you have boost installed?  Also, if you are building their viewer you should have the latest DXSDK installed as well.[Edited by - Jason Z on April 3, 2010 4:59:44 PM];  AssImp looks good and it looks like the way to go for me.The documentation is good and they support a LOT of formats. (They say some of them are not fully supported but it does not surprise me)*rant mode on* It is so frustrating to find good 3d formats and loaders. Some formats lack features and some, like collada, are too painfully generic. Most of the time is very difficult to find sample code or some kind of guidance in writing your own importer for a given format. When you find the perfect format, it turns out your 3D package of choice can´t export it and you must write an exporter or twist your artist workflow to convert the format you can export to the format you can import.Someone really should create a stupidly simple format for begginers that  supports skeletal animation/tangents and all that stuff that simple formats like .obj do not support , and provide template importers/exporters. Not an industry standard, but some kind of "amateur" standard so that people won´t pull their hair off trying to load the stanford bunny in their app.*rant mode off*   ;  I am working on a rigid-body model file format designed to work with OpenGL (though it could easily be used with Direct3D). So, I am unable to help you (yet) with regard to loading animation. That is the next step. :DHere is a sample of how the loader works:http://code.google.com/p/c3mloader/wiki/TutorialThe other half of the project is a converter tool that will take other formats (right now just 3DS and OBJ) and put them into this C3M format.   ;Quote:Original post by ArKano22and some, like collada, are too painfully generic.Thats because collada is like FBX - its used as an exchange format between editing packages, its not intended for use directly by game engines. The point with those is to write a small converter that just rips the information out that you want. Autodesk provide an API for FBX and Feeling provide one for Collada to do this.Quote:Original post by ArKano22Someone really should create a stupidly simple format for begginers that  supports skeletal animation/tangents and all that stuff that simple formats like .obj do not support , and provide template importers/exporters. As much as i'd like this to happen, they would also have to provide a large portion of the rendering (because of skinning) & update code (because of animation) for this too, which is why it doesn't happen - it suddenly crosses the border from a import/export api into a rendering engine.   ;  Hi Zouflain!I'm using XNA Animation Component Library.It's very good & powerful enough to cover my needs.U can build ur model with animations in 3dMax, Blender or whatever, load it & play its anims in XNA very easily. U can even blend animations, access bones, matrices, evrth.It's documented, it has a working example with a working model & a forum.I think the creators no longer give support to the project, but some users still post things time to time as well as updates for each XNA version that comes out (anyway, u can download the library' source & recompile urself if u need to).I won't say it's the easiest thing in the world, but it works fine.It supports .X & .FBX formats.Of course it's tricky to export the model in the correct way, until u learn how to do it right.u can find evrth here :)   ;  OOOOOOOOH, sorry!!! I thought u needed it for XNA!!! (I've just read "C++").My mistake!!!Well, in case u consider moving to XNA, it may be helpful :)Good luck!!!Synth   