0
\$\begingroup\$

I'm trying to understand the relationships between 3D models (files) and the games that load and use them. As a software engineer, I'm willing to make the few following assumptions:

  • I would assume that most (popular) 3D model formats are basically just storing coordinate positions for all the vertices that make up the model. They probably also store texture/theming information about each polygon (that is formed by combining 3+ vertices)
  • I would also assume that "labeled animations"" are stored in these files as well. This way, a 3D artist could make a model of some character, and animate them running all from inside whatever tool they use for modeling. Then they associate that animation with some label ("bad_guy_running") and all that info is stored inside the resultant file. Then, in the game code, the developers can programmatically access + execute those labels somehow, therein reproducing the same animation from inside the game. In our case, the bad guys starts running.

Am I way off base here? If so, please begin by correcting me, and please be gentle, as again I'm not even sure what this subject matter would be called to even do the upfront research on my own.

\$\endgroup\$
  • 1
    \$\begingroup\$ AFAIK you're on-target. I happen to know a bit about the OBJ format (as it pertains to vertex and texture) information, but it does not support animations. I assume that a given file type as a standard method of supplying animation information as well, and that when read and interpreted correctly results in the same animation that was exported. FBX, I believe, is an "open format" that you could look into. \$\endgroup\$ – Draco18s Feb 3 '16 at 16:51
  • \$\begingroup\$ Thanks @Draco18s (+1) - very interesting. So, to stick with OBJ (since you're familiar with it!), if an artist hands you an OBJ file of some game character, how do you animate it (make it run, jump, etc.)? \$\endgroup\$ – smeeb Feb 3 '16 at 16:55
  • \$\begingroup\$ @Draco18s I'm not an expert in this topic, but I think using FBX files requires you to buy some sort of license for it, basically because it is under the 3ds team's hand. \$\endgroup\$ – Bálint Feb 3 '16 at 17:04
  • \$\begingroup\$ @smeeb OBJ doesn't natively handle animations. When using such models myself I use programming to animate them (simple position/rotation tweens). \$\endgroup\$ – Draco18s Feb 3 '16 at 17:29
  • \$\begingroup\$ @Bálint I'm not either. I thought FBX was open, if not then I was wrong. \$\endgroup\$ – Draco18s Feb 3 '16 at 17:29
1
\$\begingroup\$

I would assume that most (popular) 3D model formats are basically just storing coordinate positions for all the vertices that make up the model. They probably also store texture/theming information about each polygon (that is formed by combining 3+ vertices)

For games, we will almost exclusively use triangles for the final geometry (although for some types of modelling, quads are more natural; they are easily converted to triangles after the fact, however). Otherwise, this is basically correct. Some file, somewhere, will store a bunch of vertex data which represents triangles.

I would also assume that "labeled animations"" are stored in these files as well.

Somewhat less good of an assumption. Animations are stored somewhere, but not necessarily in the same file. One of the most popular approaches for animations is "skeletal animation," in which a simplistic rig (or skeleton) is what is actually being animated, and the more complex triangle mesh is weighted to various "bones" of this rig. One of the benefits of this approach is that the animations can be stored distinct from the actual model geometry and re-used across many similar models.


In general, animations are not "implicitly" understood by the game engine at all. There are many ways to store models and animations, and many ways to make use of them in an engine. During the development of a game (or of an engine), decisions will be made by the team about the representations and technology they want to use and the workflow they want to fit that in to. Somebody will then explicitly write the code to make the game understand the animation and model data exported from modelling programs.

It is common these days to have basically three steps to the pipeline: the artist works in some content authoring tool like Maya. The artist then exports their model to an "interchange" format, such as FBX or Collada. These are very generalized formats that can represent many kinds of data in many structured ways. These interchange files will be converted to the final representation loaded by the game, which may be highly optimized for precisely how the game wants to work with the data.

\$\endgroup\$
  • \$\begingroup\$ Awesome, awesome answer @Josh Petrie (+1) - one quick followup question for you: when you say "Somebody will then explicitly write the code to make the game understand the animation and model data exported from modelling programs...", can I assume there are a plethora of open source libraries for this sort of thing? Even though each game's tech stack is different, I'd imagine there are C/C++/Java/Python/whatever libraries that handle various "interchange" formats, no? If my assumption is correct, can you please just kindly point me to one on GitHub/anywhere? \$\endgroup\$ – smeeb Feb 3 '16 at 17:15
  • \$\begingroup\$ ..I'd just like to see what the code is actually doing. And if my assumption is wrong, can you please just explain why? Perhaps you can point me to some code from an open source game that is "understanding" an animation, stored in some interchange file? Thanks again! \$\endgroup\$ – smeeb Feb 3 '16 at 17:18
  • \$\begingroup\$ There's lots of code for dealing with Collada. Less for FBX as the format is proprietary (you can get the SDK from Autodesk though). I can't endorse or recommend any of these things in particular but searching GitHub for skeletal animation yields a lot of results that may be worth looking in to. Similar for Collada. If you'd like to discuss the topic further you can join the Game Development Chat. \$\endgroup\$ – Josh Feb 3 '16 at 17:26
0
\$\begingroup\$

They pretty much store the coordinates in a binary file

What you described here is the COLLADA file format, or one of the morph formats (md1, md2, md4, etc.).

COLLADA

Collada supports animations by storing skeletal information about each state. It also needs to store weight information too. Because Collada is made to be a human-friendly format, it's pretty big compared to other formats.

If you want to know more about COLLADA, click here.

MORPHs

Any model file can be used in morph animation. The program reads in multiple mesh information for each model, then (usually with the GPU trough a vertex shader) interpolates between the values. If the format supports morph animation, like md1, then every state can be found in that one file, if not (e.g. .obj files), then it requires multiple files.

The more famous morph formats are the md1, and md2 formats, wich originally were made for QUAKE.

\$\endgroup\$
  • \$\begingroup\$ Sorry but md4 uses skeletal animations not morph targets. Look here. md5 also does skeletal animations \$\endgroup\$ – Soapy Feb 3 '16 at 17:02
  • \$\begingroup\$ @Soapy Sorry, I missread something. I correct it. \$\endgroup\$ – Bálint Feb 3 '16 at 17:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.