Hi,
I have been chasing an anomaly which has affected interpolations >180 degrees. I have tracked down the
Hmm, an interesting problem. I guess the first question would be whether model animation is currently affected by this in any way (in a dependency way)? This would help feed the next question; which behavior would be more commonly used? Based on that, yes, let’s set up a default and flag accordingly.
Yes this is a bit awkward, a flag should work fine but would it be worth while from a design point of view ?
Where I am coming from with this, is this, the problem can be overcome in spatial transform rotation by simply adding key frames to break up rotations > +/- 180 degrees. As far as I am aware only spatial transform rotations are affected, I don’t know if it would benefit other developers.
Also with the flag in place, a decision would need to be made on the behaviour of spatial transform rotations.
Should the mapping be off always for spatial transform rotations ? OR
Should the user be allowed to choose between having mapped and unmapped spatial transform rotations ?
With the first option, we may find that a 720 to 360 mapped spatial transform rotation is of great use ( I don’t know of any use yet though), therefore having the mapping off could hobble other developers.
With the second option, this would provide the choice, but setters (and getters for completeness) would have to be provided in SpatialTransform() and the importers/exporters would have to be modified.
I don’t know, perhaps I’m philosophizing too much over this problem ! 
Hmm, well then I think the best solution for now would be to overload and add a behavioral flag in there but leave the default action as is… No one’s code is borked and the developer has a choice in slerping action.
That sounds great, what would also help would be to draw attention to this, in the API documentation. This would fore warn current or future developers that are not aware of this issue.