HeapsIO / heaps

Heaps : Haxe Game Framework

Home Page:http://heaps.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Incorrect bone placement on some FBX animation files

trethaller opened this issue · comments

Here is animation which displays an incorrect placement on some bones (specifically the Clavicle ones) when the animation is exported with the model itself (Anim_walk_loop). When the geometry is not included in the animation file (Anim_walk2_loop.FBX), the problem disappears.
We identified that this is caused by Position keys missing in the generated HMD file.
When this optimization is disabled, the problem is resolved:

			if( data.z != null && roundValues(data.z, def.z, M) )
				hasValue = true;
			// no meaningful value found
			if( !hasValue )
				continue;      // <-----------
			var keyCount = 0;
			if( data.x != null ) keyCount = data.x.length;

Sample file:

NG_anim_bug.zip

The problem is correctly understood.

We're trying to know if the position in the animation is different than the position in the default skin (in that sample there's a difference for L/R Clavicle)

  • if the position is animated (non constant) then we will force the position into animation data
  • if the position is not animated (constant), we will compare it to the skin and force if different.
  • if there is no skin (no model, like the good animation in the sample), we are forcing the position as well (if( !hasTrans && def.transPos == null ) in BaseLibrary.loadAnimation)

The bug occurs then when:

  • we have a model in the Animation FBX
  • the position is not animated
  • the (fixed) position is different than the Model one

The correct fix would be to either:

  • correctly deduce the original skin position (defMat) : I tried to do that (commented code in BaseLibrary.updateDefaultMatrix) but it didn't work very well. Also would require to have skin (not work if model not exported)
  • always force position for all animations, whereas skin is present or not. This would increase animation size. It would be better if we can separate T/R/S data so we can have "PerFrame" on a transformation basis and not for the actual object