Mesh file format?

.obj is really simple and easy, but you will reach its limits really quickly (e.g. no animation support).

Collada is an open standard, but it is somewhat complex and have not always the best support of modelling tools, though I use it in my converter.

FBX is a Autodesk standard which is widely supported.

In general I would always sugguest to use one of the major exchange formats, that is either FBX or collada, and write a converter (not an tool dependent exporter!) to your own internal, binary format, if you really what to use it beyond a simple demo. FBX and collada are both text based formats which are really bloated with data you don't always need.

I've read about "assimp" as a means to parse .dae files, and it sounds quite interesting. (http://assimp.sourceforge.net/).
Any experiences with it, and also any other alternatives?

Also is there a good source of information on how to structure your binary mesh data?

I'd recommend using Assimp as part of your asset pipeline if you're new to this and/or don't want to write your own. However I'd also move to using your own format for the game, by processing the original source files (.dae etc.) into your own format on load and then caching the result so that any future load can see if the source has changed and if not load the cached data. Then you only need to distribute the cached files, normally in a zip container (packed format). This is fairly standard in the industry, and easy to implement.

Your own format should mirror the binary in game format as closely as possible since it doesn't need to be backward compatible or cope with endian-ness or other cross platform issues since the asset pipeline deals with this sort of thing. This also makes it really easy to write your own format.

I do like Assimp, but I'm one of the founders so it's not surprising. Assimp works well for many people as far as I can tell from the feedback. And it can do a lot of processing for you to handle details you're not aware of at the beginning. Such are: calculating tangent space, triangulating complex shapes, splitting up meshes for vertex count or bone count, optimizing for GPUs post transform cache and so on.

To reiterate on what dougbinks said: it's not really suitable for everyday loading. For that, create a custom binary file format mirroring your engine's internal structures as closely as possible. Use Assimp only to load 3d files when they're new or you know they've changed, then inspect the asset and save it in your internal file format for quick loading times.

FBX and collada are both text based formats which are really bloated with data you don't always need.

FBX is almost always binary unless you manually select to make it text-based.
As an advantage over COLLADA, this means that textures can be embedded into .FBX files whereas they cannot in .DAE (COLLADA) files.

I'd recommend using Assimp

I would recommend not, and…

I'm one of the founders

…perhaps you can tell me if my reasoning is valid (in other words, does Assimp support this most-valuable feature?).

I do acknowledge that Assimp does a lot of heavy lifting, such as splitting up vertex buffers to handle limited systems such as iOS and to simplify meshes, but I would consider these far less important than the main feature which makes me a proponent of .FBX: World animation simulation.

There are many types of animation curves (linear, splines, step, etc.) and each type has a few parameters (for example a stepping key-frame denotes that between this key-frame and the next, a single non-interpolated value should be used, however whether that value should come from this key-frame or the next depends on a parameter) and trying to simulate this is non-trivial.

Why do you need to simulate this? Because your only run-time animation interpolation should be linear. You should never be doing switch cases to check the key-frame type and branch etc. Your run-time should be nothing but: Take current key-frame. Take next key-frame. Interpolate linearly.


If you try to do this with raw animation data you are very likely to encounter very bad run-time animations.
The solution is for the tool to simulation the animation and inject key-frames where necessary in order to make a linear-interpolation run-time as accurate as desired.
The Autodesk® FBX® SDK allows you to evaluate animation tracks at any time in the simulation and makes it trivial to reduce complex animation tracks into accurate linear–interpolation-only tracks.


My older engine never split vertex buffers or simplified/split meshes.
It also didn’t convert animation tracks to linear-only.
Ultimately, that engine never encountered a problem with too-large vertex buffers or over-complex meshes because the meshes were designed for the target platforms (simple meshes for iOS, huge meshes for PC).
It did however have problems running complex animations.

This is why I consider it a much more important feature. The Autodesk® FBX® SDK also does coordinate conversions, triangulating of complex shapes (specifically NURBs), etc. It doesn’t do all that Assimp does but there is overlap on the important features.


I am not talking down on Assimp—I am saying that the Autodesk® FBX® SDK offers something I consider more important.
I am writing a book and it includes a chapter on how to make your own 3D formats using interchange formats such as COLLADA, Autodesk® FBX® SDK, and Assimp.
The chapter is written (I started with it because I need a 3D file format in order to write the rest of the book) and I tried to give a fair pro/con comparison of each.
One of the biggest pros for Autodesk® FBX® SDK (which also does have its cons—for one, every new SDK release breaks your old code, but Autodesk® personnel have told me this will stop after the next or next next release) was that it was the only one with this ability (to trivially simplify complex animation tracks into linear–interpolation-only), however if I am wrong and Assimp does this also, please let me know and I will correct my chapter.
I checked prior to writing the chapter and I could not find any such feature listed on Assimp’s page.


L. Spiro

Adding extra keyframes eats up memory though. And I presume you slerp quaternions or do you add keyframes if lerping quats gives you bad accuracy?

One place I worked at used the spline curves for animation, animations were a lot less memory hogging there, I was going to look at it where I work now but the animators like to do things like freeze anims and have 2 or more curves to animate per node so I put it on the backburner.

The place that used the spline curves may have had a few games out to do with Lego (insert franchise here).

It is a 2-step process. It begins with raw-interval sampling, which certainly adds a ton more key-frames, but then it does redundancy checking and removes redundant key-frames. I generally end up with either only a few more key-frames in very simple animations (where there are so few key-frames that just a few more don’t really eat up noticeable extra memory) or with fewer than were originally in the file.

The first step is to decide your sampling rate. I found that this does not effect the final result in terms of number of key-frames overall so you may as well keep it high. Sometimes you will end up with a few extra than otherwise, sometimes fewer. Average is the same (but the conversion time is affected), so I sample at 96 times per second (I have a table of sample rates and if one fails due to too much memory I decrease the sampling rate and try again).

Next is to build a table of times through the animation that you are going to sample. Since this is offline, std::set works fine, since the times do need to be in sorted (and non-duplicate) order for this to work.
Start by adding all of the original key-frame times to the set.
Then add all the key-frame times as per your selected sampling interval.

Then go over the animation track and use the Autodesk® FBX® SDK to sample at all of those times you have added to your set.


Stage 2 begins afterwards. This is where you remove redundant key-frames.
In this stage you start with key-frames 0 and 2 and linearly interpolate between them. If the result is close enough (given your own error metric) to key-frame 1 then key-frame 1 can be eliminated and you then check between 0 and 3 to see if 2 can be eliminated.
When you get to one that can’t, repeat from the next set of key-frames.
Keep doing this until you reach the end of the animation.

The code for all of this follows (but is hard to read).

	/**
	 * Loads data from an FBX animation curve.
	 *
	 * \param _pfacCurve The curve from which to load keyframes.
	 * \param _pfnNode The node effected by this track.
	 * \param _ui32Attribute The attribute of that node affected by this track.
	 * \return Returns true if there are no memory failures.
	 */
	LSBOOL LSE_CALL CAnimationTrack::Load( FbxAnimCurve * _pfacCurve, FbxNode * _pfnNode, unsigned int _ui32Attribute ) {
		SetAttributes( _pfnNode, _ui32Attribute );

		unsigned int ui32Total = _pfacCurve->KeyGetCount();
		static const FbxTime::EMode emModes[] = {
			FbxTime::eFrames96,
			FbxTime::eFrames60,
			FbxTime::eFrames48,
			FbxTime::eFrames30,
			FbxTime::eFrames24,
		};
		unsigned int ui32FrameMode = 0UL;
		if ( ui32Total ) {
			while ( ui32FrameMode < LSE_ELEMENTS( emModes ) ) {
				// Count how many entries we will add.
				FbxTime ftTotalTime = _pfacCurve->KeyGetTime( ui32Total - 1UL ) - _pfacCurve->KeyGetTime( 0UL );
				// We sample at emModes[ui32FrameMode] frames per second.
				FbxLongLong fllFrames = ftTotalTime.GetFrameCount( emModes[ui32FrameMode] );
				if ( ui32Total + fllFrames >= 0x0000000100000000ULL ) {
					// Too many frames!  Holy crazy!  Try to sample at the next-lower resolution.
					++ui32FrameMode;
					continue;
				}

				m_sKeyFrames.AllocateAtLeast( static_cast<unsigned int>(ui32Total + fllFrames) );
				// Evaluate at the actual key times.
				int iIndex = 0;
				for ( unsigned int I = 0UL; I < ui32Total; ++I ) {
					if ( !SetKeyFrame( _pfacCurve->KeyGetTime( I ), _pfacCurve->Evaluate( _pfacCurve->KeyGetTime( I ), &iIndex ) ) ) {
						return false;
					}
				}
				// Extra evaluation between key times.
				iIndex = 0;
				FbxTime ftFrameTime;
				for ( FbxLongLong I = 0ULL; I < fllFrames; ++I ) {
					ftFrameTime.SetFrame( I, emModes[ui32FrameMode] );
					FbxTime ftCurTime = _pfacCurve->KeyGetTime( 0UL ) + ftFrameTime;
					if ( !SetKeyFrame( ftCurTime, _pfacCurve->Evaluate( ftCurTime, &iIndex ) ) ) {
						return false;
					}
				}


				// Now simplify.
				unsigned int ui32Eliminated = 0UL;
				for ( unsigned int ui32Start = 0UL; m_sKeyFrames.Length() >= 3UL && ui32Start < m_sKeyFrames.Length() - 2UL; ++ui32Start ) {
					const unsigned int ui32End = ui32Start + 2UL;
					while ( m_sKeyFrames.Length() >= 3UL && ui32Start < m_sKeyFrames.Length() - 2UL ) {
						// Try to remove the key between ui32Start and ui32End.
						double dSpan = static_cast<double>(m_sKeyFrames.GetByIndex( ui32End ).tTime.GetMilliSeconds()) - static_cast<double>(m_sKeyFrames.GetByIndex( ui32Start ).tTime.GetMilliSeconds());
						double dFrac = (static_cast<double>(m_sKeyFrames.GetByIndex( ui32Start + 1UL ).tTime.GetMilliSeconds()) -
							static_cast<double>(m_sKeyFrames.GetByIndex( ui32Start ).tTime.GetMilliSeconds())) / dSpan;
						// Interpolate by this much between the start and end keys.
						double dInterp = (m_sKeyFrames.GetByIndex( ui32End ).fValue - m_sKeyFrames.GetByIndex( ui32Start ).fValue) * dFrac + m_sKeyFrames.GetByIndex( ui32Start ).fValue;
						double dActual = m_sKeyFrames.GetByIndex( ui32Start + 1UL ).fValue;
						double dDif = ::abs( dInterp - dActual );
						if ( dDif < 0.05 ) {
							m_sKeyFrames.RemoveByIndex( ui32Start + 1UL );
							++ui32Eliminated;
						}
						else {
							// Move on to the next key frame and repeat.
							break;
						}
					}
				}
				::printf( "\tOriginal key frames: %u\r\n\tFinal total key frames: %u %f\r\n", ui32Total,
					m_sKeyFrames.Length(), m_sKeyFrames.Length() * 100.0f / static_cast<LSFLOAT>(ui32Total) );
				break;
			}
		}
		return ui32FrameMode < LSE_ELEMENTS( emModes );
	}

What makes the biggest difference is the epsilon you use to decide if key-frames should be removed, and my results are as above. It is common to have the same number as or fewer than the original number of key-frames. m_sKeyFrames here by the way is a set.

So ultimately memory concerns and extra key-frames are not an issue. At most you would end up with just a few extra ones, but that is the bare minimum you would need to produce the “same” animation via only linear interpolation, which makes your run-time much faster and is an obvious win.

L. Spiro

Yeah, we try to do that but I reckon the code is bugged, because it hardly reduces the keyframes at all. I need to look at the code myself I think.

We weren't doing keyframe reduction on our sky animations (they're a special case) and I changed it to only use the artist placed keyframes and it went from over 2 meg to 224 bytes ;)

Besides some issues I had with AssImp here and there I'd still strongly recommend to use it. Collada as interchange and binary specific format for run-time. I've been asked for FBX a couple of times as well. So far with no good reason at all.

Yes, FBX is also a good thing. It's solid technology, except for the whole "binary-distributed only" which rubs me in the wrong direction. I prefer building myself, and in most cases today it's just a "drop those files into your project configuration and build along". But that's another topic.

FBX does a good job on animations, and I concede that Assimp is lacking in that direction. Assimp supports node animations, so you could actually animate any motion in your scene, but it does not support meta data on animations such as "interpolate this linearly, this not at all" and it does not support complex animation curves such as splines. The reasons for this are manifold:

a) I never needed it, and I'm nearly the only person who takes care of animations in the Assimp project. Whenever I get animation data along with a scene, it comes as a dense regular pattern of keyframes, where linear interpolation is more than enough to represent the motion correctly. Therefore there was never a need for complex animation curves, and thus I never got around to implement them.

b) Most file formats don't even support any complex animation features. To my knowledge Collada is the only file format that allows specifying interpolation, and I've never seen it in use anywhere. It it would be used, I should probably add a decoder in the loader to interpret this data and break it down into linearly interpolated keyframes.

c) Assimp tries to cater to a hell of a lot people. We get occasional complaints that we flat the data too much and that we should strife to preserve the data as original as possible. But 30+ file formats do have many a different view on how to represent the data, and the current Assimp structures are simply the lowest common denominator of all these views. If we ramp up the data structures, it should better be able to handle ALL of these formats. And I really fear that we end up at an overengineered mess of generic data blobs and reading techniques such as Collada is, which would render the whole library useless in my opinion.

d) Optimizing animation data shouldn't be that hard, and we already planned a post processing step to filter out keyframes that don't make a difference when missing. But we never got around to implement it.

Note: Assimp also supports FBX, but to my knowledge it's still hidden in some personal fork and wasn't reintegrated yet.