What are the standard alternatives for the mechanics of attaching turrets and such to 3D models for use in-game? I don't mean the logic, but rather the graphics aspects.

My naive approach is to extend the MD2-like format that I'm using (blender-exported using a script) to include a new set of properties for a mesh that:

  • is anchored in another 'parent' mesh. The anchor is a point and normal in the parent mesh and a point and normal in the child mesh; these will always be colinear, giving the child rotation but not translation relative to the parent point.

  • has a normal that is aligned with a 'target'. Classically this target is the enemy that is being engaged, but it might be some other vector e.g. 'the wind' (for sails and flags (and smoke, which is a particle system but the same principle applies)) or 'upwards' (e.g. so bodies of riders bend properly when riding a horse up an incline etc).

  • that the anchor and target alignments have maximum and minimum and a speed coeff.

  • there is game logic for multiple turrets and on a model and deciding which engages which enemy. 'primary' and 'secondary' or 'target0' ... 'targetN' or some such annotation will be there.

So to illustrate, a classic tank would be made from three meshes; a main body mesh, a turret mesh that is anchored to the top of the main body so it can spin only horizontally and a barrel mesh that is anchored to the front of the turret and can only move vertically within some bounds.

And there might be a forth flag mesh on top of the turret that is aligned with 'wind' where wind is a function the engine solves that merges environment's wind angle with angle the vehicle is travelling in an velocity, or something fancy.

This gives each mesh one degree of freedom relative to its parent. Things with multiple degrees of freedom can be modelled by zero-vertex connecting meshes perhaps? This is where I think the approach I outlined begins to feel inelegant, yet perhaps its still a workable system? This is why I want to know how it is done in professional games ;)

Are there better approaches? Are there formats that already include this information? Is this routine?

  • 1
    \$\begingroup\$ The question is a bit vague, what is your intended goal or final result? \$\endgroup\$ Jan 26, 2011 at 21:23
  • \$\begingroup\$ are you looking for some easier model of usage than bones? Mean parent-child tranformations as you mention? I've implemented some tanks just using transformations and having objects for body, turret and gun. \$\endgroup\$
    – Notabene
    Jan 27, 2011 at 9:46

2 Answers 2


Yap. Bones formats. MD2 is a vertex animation format, not bones based format. And in Blender, depends on the version you're working with, but can probably make use of:

  • Directx *.x (I think in both 2.49 and 2.56 beta)
  • *.md5 . Doom III, like md2, from Id Software, but much better than md2. Md2 has vertex position accuracy problems, normals/lighting problems, UVs have its issues too, etc. Still, all blenders do export it, and can be useful for the flag animation. But you can asign some bones to the flag, some weight painting, and have same effect.Even easier.
  • Collada. But it is still not ended, in certain newest builds at graphicall.org I have checked to be working, at least in basic stuff which you need.
  • You need to use Blender 'constraints' in your bone animations, to have the behaviours you mention, and then export with those "baked". Then code would do the rest.(and don't quote me on this, but I think md5 did export constraints also. And that you can use a md5 version with blender 2.41. I think , set as an addon, md5 can work well with 2.56, but have not tried yet.)

A good knowledge of Blender rigging (bones, weights, constraints) system and formats is quite needed for this, but seems pretty doable.

A lot of people just used to use Milkshape, ideal for these kind of things, and there were very good loaders for game programmers, for ms3d format.

IMHO you can achieve the same by loading for example an md5, there are good loaders out there, and am told is an easy to handle format for programmers. Collada anyway might be the best in long run: Is the definite Blender's bet, and in general, everybody, engines, etc, are trusting on it. But it's a very complex format, so making a loader might be hard, unless you can grab sth already made or whatever. I don't know, that's the programmer side of things.

  • \$\begingroup\$ How might you annotate things so the engine understands what the artist intended for the various meshes in the model? \$\endgroup\$
    – Will
    Jan 27, 2011 at 9:27
  • 3
    \$\begingroup\$ It's usually done by adding tags to certain bones, or having special bones named a certain way. For example every bone named starting with "foot" is assumed to be the bottom of a foot, the direction of it showing the direction the foot is facing; a bone named "projectile_start" is where you spawn the projectiles of your tank's cannon, and object parts tagged with "steel" have corresponding sparks when hit and have corresponding sound effects assigned. \$\endgroup\$ Jan 27, 2011 at 10:02
  • 2
    \$\begingroup\$ Why is bones needed for simple mesh translation and rotation? Aren't bones used to actually deform the meshes while translating and rotating them while a simple mesh/layer parenting setup sounds a lot simpler for non-organic constructs? \$\endgroup\$ Jan 27, 2011 at 17:13
  • 1
    \$\begingroup\$ @oskar Duveborn: True, so +1, but if you use bones you can add a deforming tank (with a cloth over the turret, or an organic alien tank, who knows) without needing the change the engine. \$\endgroup\$ Jan 27, 2011 at 23:03
  • \$\begingroup\$ @Oskar Duveborn: Bones aren't strictly needed, just useful: they are usually already well-supported in modern engines and in your tool chain of choice, they have all kinds of constraints to the relative movement which you'd otherwise need to implement anyway, they allow for non-organic constructs to have flexible parts as well (connecting hoses, for example), and they allow you to apply IK solutions to your animation: from that perspective, there isn't a lot of difference between an arm moving to reach an apple, and a tank's turret and gun assembly turning around to aim in a direction. \$\endgroup\$ Jan 28, 2011 at 7:05

I'm not entirely sure if I fully understood your question(s). But I'd definitely use a mesh format that supports bones and animations. Especially the bones are important if you wish to move separate mesh-parts individually.

The flag you're speaking of could be pre-animated (wave movement) and aligned in the direction of the wind by using bones. The speed of the animation could be controlled by the strength of the wind.

I can't give you any format recommendations though, since you didn't mention the engine/framework you're using. OGRE for example uses its own mesh format that supports bones and animations. Unity can load several popular native formats directly... and there's always Collada, an XML based 3D format which you could write a parser for (or use an existing one).

  • \$\begingroup\$ Pretty much this- existing formats use bones to support this. \$\endgroup\$
    – DeadMG
    Jan 27, 2011 at 7:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .