What's your in-game model/animation solution?

I'm just curious as to what you all use for using models (and possibly animations) in your games. (at least the 3D ones ) I'm mainly interested because I haven't seen many complete solutions, though perhaps I just didn't look hard enough. The closest I've seen are the file descriptions of various formats, and maybe a couple obj loaders for download.

As you may have seen by the demo I released a few months ago, I took a rather bold approach, myself, and decided that I would make my own solution, making my own model, skeleton, and animation format. (though you start off by importing a .obj model; I'm actually releasing an update on this project pretty soon, but that's for later )

So what do you guys do? What tools do you use to first make the models and animations, then what do you do to put them to use?

There really aren't any standards available out there that I've found (especially none for the Mac). You could go with something like MD5 (Doom 3) I suppose. My own format is somewhat similar. I've been toying around with Maya for my modeling and animations, and outputting using MEL (Maya Embedded Language) scripts. Obj is probably as good as anything to start with, but it doesn't do bones. Skeletal animation is not very complicated IMHO, but there doesn't seem to be very much definitive (hobby programmer readable) documentation available; just bits and pieces here and there is all I've found. I even bought Focus on 3D Models, and found it quite lacking too, but at least it offered as good a picture as anything else out there on the subject -- that is to say, not much.

There are a very few other paths to pursue on the Mac side of course. Among others, Blender is a good direction to look. Maya works really well (the best outside of 3D Studio Max actually), but it's gawdawful expensive, and not designed for the niche market of indie game developers, and is now owned by Autodesk, so I've been looking at other possibilities. After what seems like decades of trying to find the right solution, I just haven't found anything that really fits my exact feature requests as a hobby programmer, so last week I actually started making my own modeler/editor/animator/texture-mapper/terrain maker/unrealistic-super-mondo-does-everything app. I have no idea how far I will get with it, but I figure it'll be fun, and it'll scratch an itch that I've had for a long time. Heck, if it does actually manage to get anywhere I'll even distribute it!

Kind of off-topic, but here are some of my ideas for it:

My initial design is fully Cocoa (I've wanted to do a pure Cocoa app for a long time), and I'm even going to try to leverage Core Data, but I am not certain of how well that will work out at all -- I just started reading the Core Data programming guide and I'm using this project as my excuse to spend the time on it ;-) This is going to be a bit of an experiment to see just how much heavy lifting Cocoa can really do in conjunction with OpenGL. I would like to have a public interface available for plug-ins, but I am not entirely sure about the value there. Being able to write custom exporters and importers is a pretty high priority though. I have been really impressed with the speed and efficiency of scripting languages I've tried, so I might make a public API with script bindings available as well. I already have a pretty nice console for the real-time preview feature I'm planning, and an almost complete syntax colorizer that I worked on last year (for the scripting environment). I also have a rough layout of the interface and am leaning heavily toward a four-view document window, with a toolbar, and separate inspector(s) window(s). I prefer all-in-one designs, but since there are so many features being juggled around at first, it's getting kind of tricky to swing that right away. I don't know how much time I will have available for this project, but if anybody has any burning ideas or feature requests, I'm all ears! Or eyes, as it may be...

In Water Tower 3D, I made up my own formats for everything, and ended up building a lot of the assets by hand. It would have worked well if I'd had time to develop the tools to support the process ahead of time, but as it was, the solution was less than ideal. I ended up spending a whole lot of time and extremely tedious work to build something very mediocre.

If I come back to the project later, my plan is to do the modeling in something that can export to .obj, and write a very simplistic program just for animation. If I can find a modeler with all the animation capabilities I need, the latter may not be necessary.

I hear you about the lack of info on animations. Even specific info about how to use quaternions is hard to come by. (hence my thread on how to do kinematics with quaternions, which has only 1 reply and no actual answer to my question) I think I have all the mathematics figured out, and I have all the coding theoretically complete for my animations. (just finished last night, with a few tweaks I thought of tonight ) However, I haven't had a chance to test it yet... After a few days of diffusing the explosions that invariably happen after writing a segment of code, I'll truly see if I got my stuff correct.

AnotherJake: that's quite a project you've got there. It seems of somewhat similar design to mine... but much more extensive. (I was planning on making other editors, but they will be for a "in-house" solution specific to the game I'm creating at the time) Good luck on that.

I have used MD2 and a custom made format very similar to it, with an OBJ importer that took a series of OBJ files as keyframes and exported to a single binary file containing animation/vertex/text coords./normals info. No bone support though.

imikedaman Wrote:Skeletal animation is practically the *only* way to make a decent 3D game, and it's been around for at least a decade (with Banjo Kazooie).

There are plenty of animations that are next to impossible (or ridiculously complicated to achieve) using skeletons alone. Vertex keyframe morphing is still a valid approach, and as PowerMacX pointed out it all comes down to what you're animating, and the range of motion required.