Animation: quaternion vs. axis-angle

pjcozzi commented 10 years ago

I assume this was discussed at length, and, if so, we can just move on; I don't want to slow us down.

Both my implementation and @tparisi's use quaternions for rotation, which means that we have to convert the glTF axis-angle representation to a quaternion. I suspect that most non-trivial implementations will also quaternions, and it's no problem for the converter to output these.

So why did we go with axis-angle? To lower the barrier to entry? Would using quaternions plus having some quaternion-to-rotation-matrix and quaternion-interpolation examples be more in tune with the glTF vision - "avoid client-side work?"

fabrobinet commented 10 years ago

we choose axis angle because they can carry rotations > 2 * PI and they convert well to quaternion. In short, axis angle really represent a rotation while a quaternion is more an orientation.

fabrobinet commented 10 years ago

note that we discussed that in length, but I don't mind re-evaluating options if needed.

I use quaternions for interpolations but axis angle also. It seems that for the many ones who uses exclusively quaternion, having axis angle will require to break the rotations in multiple quaternions sometime, so I wouldn't object to have a orientation property that would carry a quaternion. In the converter we would split rotations as necessary so they could be just be sent to the engine.

pjcozzi commented 10 years ago

Ah, actually I think I remember some of this conversation 6+ months ago. @RemiArnaud and @tparisi should chime in, but if all our engines are converting to quaternion anyway, we are not getting the benefit of axis-angle and we're doing more client-side work than we'd like.

RemiArnaud commented 10 years ago

Yes, that's exactly what al lot of engines are doing. For example, see http://answers.unity3d.com/questions/26447/how-to-change-the-animationcurve-interpolation-qua.html

Here's how it works in mode detail:

the converter keeps does the 'right thing'. The conversion process is not a direct conversion of the euler keys into quaternions. Instead, the converter is sampling the animation created with the full values ,provided a sample rate, and then exports quaternions based on the error difference measured between what the simple quaternion interpolator will do in the engine ('play') and what the value should be. If extrapolation between two quaternions provide the intermediate value within the error, then the intermediate quaternion is not exporter.

Most engines have several ways of interpolating values. Could be step, linear, and ... something else which is often some kind of sinus interpolation or hermite curve. So glTF can decide which of those it want to implement (does not have to match COLLADA at all - in fact a COLLADA bezier on Euler can be converted to a glTF quaternion Hermite for example.

I hope I make sense. But basically, if we the converter can have the following parameters then it can do the job of converting everything to quaternions for the run-time:

accuracy (e.g. 0.5 euler degrees)
sample rate

accuracy is definitely a parameter to the converter. sample rate.. I think there is an extension that exists for that, but most of the time this would have to be provided as a parameter to the converter.

Regards -- Remi

On Fri, Oct 18, 2013 at 2:31 PM, Patrick Cozzi notifications@github.comwrote:

Ah, actually I think I remember some of this conversation 6+ months ago. @RemiArnaud https://github.com/RemiArnaud and @tparisihttps://github.com/tparisishould chime in, but if all our engines are converting to quaternion anyway, we are not getting the benefit of axis-angle and we're doing more client-side work than we'd like.

— Reply to this email directly or view it on GitHubhttps://github.com/KhronosGroup/glTF/issues/144#issuecomment-26631339 .

pjcozzi commented 10 years ago

@tparisi are you also in support of replacing axis-angle with quaternions?

meshula commented 10 years ago

Sorry for jumping in out of the blue, but I am someone on the internet with an opinion - more specifically, I'm someone who has spent a lot of time addressing angles in runtimes and tools :)

I don't think you can argue that Euler with conversion is good enough, or quaternion with Euler is good enough. Sometimes artists need to animate an object through an orientation where Euler angles would introduce gimbal lock, and sometimes artists need to animate an object in a way that is easy to understand as an Euler angle so that the curve can carefully tuned, such as the rotation of a steering wheel, or a propellor on an airplane going through multiple revolutions.

In Imath, https://github.com/openexr/openexr/blob/master/IlmBase/Imath/ImathEuler.h , we provided all 24 valid Euler representations because we found over the years that artists would choose the right one for their task at hand. Autodesk made a similar choice. http://download.autodesk.com/us/maya/2010help/API/class_m_euler_rotation.html

It's also useful to provide interpolation options such as euler-linear, great-circle-nearest, or slerp. For example, the shortestUnitArc option on the rotate action here - https://developer.apple.com/library/ios/documentation/SpriteKit/Reference/SKAction_Ref/Reference/Reference.html#//apple_ref/doc/uid/TP40013017

I don't think an approximation scheme will serve you well when you have concatenated rotations. Let's say you have a rig like a snake. o----o----o-----o . If the rotational tolerance at each node is r, and the number of nodes is n, and you are approximating the angles at each node, by the end of the chain, a concatenated transform is going to have an error bound of r^n in the components affected by rotation. In the case of a human it could mean the fingers twitch or move to weird positions.

Finally, if you stick with what the artist authored, and you carry the numerical precision all the way through (i.e., they animated in IEEE float, and you run in IEEE float) then the accumulated error would have been visible to them in their authoring environment, and your run time will therefore be true to their intent.

RemiArnaud commented 10 years ago

Yes, this is all true. And this level of complexity and flexibility is is very well handled by formats such as COLLADA. So all the information you are mentioning is available as input to the converter. It is really important this information is weel understood and taken in account by the COLLADA->gltf tool.

But this all applies to authoring space, and when the data is processed for run time it looses most if not all its original authoring concepts.

glTF is not designed for authoring, it is a final format for visualizing/animating targetting the OpenGL familly API.

So, at the end of the day, do not expect the same euler system, interpolation method,keys, IK constraints, ... To exist in glTF it will all be backed in a way that is the best compromise we can come up with between size of data and friendlyness to the API

-----Original Message----- From: Nick Porcino notifications@github.com Date: Tue, 22 Oct 2013 07:21:39 To: KhronosGroup/glTFglTF@noreply.github.com Reply-To: KhronosGroup/glTF reply@reply.github.com Cc: Rémi Arnaudremi@acm.org Subject: Re: [glTF] Animation: quaternion vs. axis-angle (#144)

Sorry for jumping in out of the blue, but I am someone on the internet with an opinion - more specifically, I'm someone who has spent a lot of time addressing angles in runtimes and tools :)

I don't think you can argue that Euler with conversion is good enough, or quaternion with Euler is good enough. Sometimes artists need to animate an object through an orientation where Euler angles would introduce gimbal lock, and sometimes artists need to animate an object in a way that is easy to understand as an Euler angle so that the curve can carefully tuned, such as the rotation of a steering wheel, or a propellor on an airplane going through multiple revolutions.

In Imath, https://github.com/openexr/openexr/blob/master/IlmBase/Imath/ImathEuler.h , we provided all 24 valid Euler representations because we found over the years that artists would choose the right one for their task at hand. Autodesk made a similar choice. http://download.autodesk.com/us/maya/2010help/API/class_m_euler_rotation.html

It's also useful to provide interpolation options such as euler-linear, great-circle-nearest, or slerp. For example, the shortestUnitArc option on the rotate action here - https://developer.apple.com/library/ios/documentation/SpriteKit/Reference/SKAction_Ref/Reference/Reference.html#//apple_ref/doc/uid/TP40013017

I don't think an approximation scheme will serve you well when you have concatenated rotations. Let's say you have a rig like a snake. o----o----o-----o . If the rotational tolerance at each node is r, and the number of nodes is n, and you are approximating the angles at each node, by the end of the chain, a concatenated transform is going to have an error bound of r^n in the components affected by rotation. In the case of a human it could mean the fingers twitch or move to weird positions.

Finally, if you stick with what the artist authored, and you carry the numerical precision all the way through (i.e., they animated in IEEE float, and you run in IEEE float) then the accumulated error would have been visible to them in their authoring environment, and your run time will therefore be true to their intent.

Reply to this email directly or view it on GitHub: https://github.com/KhronosGroup/glTF/issues/144#issuecomment-26806936

RemiArnaud commented 10 years ago

You can't replace one by another since they are not exactly equivalent.

Quaternions will, depending on the dataset, generate more data/keys. Axis-angle will keep the original keys.

The real question is how much we want to push in the converter, and how conversion/backing we want.

I don't have objections to either of the following choices:

keep as-is. Converter provides axis-angle, keys are not created by converter, angles can be greater than 180 or less than -180
- use quaternions only. Converter calculate quaternions and insert keys when needed so that the resulting animation is equivalent
provide option to quaternions or axis-angle in both format and converter

However I would object to:

switch to quaternion, do not resample and calculate keys. Tell the user to conform their data to the limitations introduced by the converter/format.

I hope this make sense.

-----Original Message----- From: Patrick Cozzi notifications@github.com Date: Tue, 22 Oct 2013 06:55:33 To: KhronosGroup/glTFglTF@noreply.github.com Reply-To: KhronosGroup/glTF reply@reply.github.com Cc: Rémi Arnaudremi@acm.org Subject: Re: [glTF] Animation: quaternion vs. axis-angle (#144)

@tparisi are you also in support of replacing axis-angle with quaternions?

Reply to this email directly or view it on GitHub: https://github.com/KhronosGroup/glTF/issues/144#issuecomment-26804559

fabrobinet commented 10 years ago

Thanks for the input @meshula. Yes, @RemiArnaud you have put the right words into what's glTF intention is.

My suggestion is to provide both options:

axis angles: TRS R: axis angle. It is a "real" rotation that can make multiple spins..
quaternion. TOS O: orientation : A quaternion that will be sampled as needed. Exactly as advised Remi.

I'd like we agree on this quicky so I move forward on the converter.

RemiArnaud commented 10 years ago

As a side note, maybe we should rename the tool into compiler. A converter is more for a tool that can convert or translate between two equivalent representations. COLLADA->glTF is morre analogous to a compiler than a converter IMHO, since we have no intent to convert back.

-----Original Message----- From: Fabrice Robinet notifications@github.com Date: Tue, 22 Oct 2013 10:28:02 To: KhronosGroup/glTFglTF@noreply.github.com Reply-To: KhronosGroup/glTF reply@reply.github.com Cc: Rémi Arnaudremi@acm.org Subject: Re: [glTF] Animation: quaternion vs. axis-angle (#144)

Thanks for the input @meshula. Yes, @RemiArnaud you have put the right words into what's glTF intention is.

My suggestion is to provide both options:

axis angles: TRS R: axis angle. It is a "real" rotation that can make multiple spins..
quaternion. TOS O: orientation : A quaternion that will be sampled as needed. Exactly as advised Remi.

I'd like we agree on this quicky so I move forward on the converter.

Reply to this email directly or view it on GitHub: https://github.com/KhronosGroup/glTF/issues/144#issuecomment-26823695

fabrobinet commented 10 years ago

good point.

meshula commented 10 years ago

Allowing either axis-angle or quaternion essentially covers the use cases I care about at run time :)

pjcozzi commented 10 years ago

Supporting both does not feel inline with the glTF vision. I opened this issue in the hopes of making the client do less work - the glTF vision - and now we are considering making it do more work. Look at runtime formats for major engines, what percentage of them support more than one representation? Yes, yes, glTF is more broad, but if we become too broad, then we have become an authoring format and have fallen short on the vision. Are there really enough prominent use cases to support both?

I would rather stick with one (quaternions with converter support), and then ultimately promote an extension if enough folks find it valuable to have another representation. We can even have converter support for Eulers since it's already there. We can always add to glTF; removing is much harder.

fabrobinet commented 10 years ago

I am also OK with just quaternions and be conservative.

RemiArnaud commented 10 years ago

How is this more work for the application?

Application A want quaternions, ask for quaternions, and deal with quaternions

Application B want axis/angle, ask for axis/angle, and deal with axis/angle

-----Original Message----- From: Patrick Cozzi notifications@github.com Date: Tue, 22 Oct 2013 14:44:41 To: KhronosGroup/glTFglTF@noreply.github.com Reply-To: KhronosGroup/glTF reply@reply.github.com Cc: Rémi Arnaudremi@acm.org Subject: Re: [glTF] Animation: quaternion vs. axis-angle (#144)

Supporting both does not feel inline with the glTF vision. I opened this issue in the hopes of making the client do less work - the glTF vision - and now we are considering making it do more work. Look at runtime formats for major engines, what percentage of them support more than one representation? Yes, yes, glTF is more broad, but if we become too broad, then we have become an authoring format and have fallen short on the vision. Are there really enough prominent use cases to support both?

I would rather stick with one (quaternions with converter support), and then ultimately promote an extension if enough folks find it valuable to have another representation. We can even have converter support for Eulers since it's already there. We can always add to glTF; removing is much harder.

Reply to this email directly or view it on GitHub: https://github.com/KhronosGroup/glTF/issues/144#issuecomment-26853500

meshula commented 10 years ago

Are there enough prominent uses? Yes. Object tumbling from baked physics sim: quaternion. Angles on a robotic arm: Euler.

As Remi says, the application should be able to do the appropriate thing with the appropriate representation, not have to do it's own conversion to or from another representation. The properties of an Euler representation and a quaternion are not the same.

pjcozzi commented 10 years ago

How is this more work for the application?

If we support both, what does a compliant glTF implementation have to implement? Both, unless we fragment the market and they only have to support one. Then the only hope is that everyone is using a Rest3D server that can return the right representation: unlikely and a limitation that I wouldn't impose.

So clients would need to support both and that makes it more work - and not inline with what we are trying to achieve unless the motivation is strong enough.

RemiArnaud commented 10 years ago

I am at loss here.

We have lots of options in the converter, and will have more. We have profiles coming.

Since when does an application have to be able to load all possible combinasions of valid gltf files?

If you want to do that, then yes, this is a bit more work than just loading the data you intent for your app. I personally do not see the point to do that, but you are free to do that.

Now, why would you want to limit the options on gltf to the ones you want to support in your application?

-----Original Message----- From: Patrick Cozzi notifications@github.com Date: Thu, 24 Oct 2013 05:01:41 To: KhronosGroup/glTFglTF@noreply.github.com Reply-To: KhronosGroup/glTF reply@reply.github.com Cc: Rémi Arnaudremi@acm.org Subject: Re: [glTF] Animation: quaternion vs. axis-angle (#144)

How is this more work for the application?

If we support both, what does a compliant glTF implementation have to implement? Both, unless we fragment the market and they only have to support one. Then the only hope is that everyone is using a Rest3D server that can return the right representation: unlikely and a limitation that I wouldn't impose.

So clients would need to support both and that makes it more work - and not inline with what we are trying to achieve unless the motivation is strong enough.

Reply to this email directly or view it on GitHub: https://github.com/KhronosGroup/glTF/issues/144#issuecomment-26986294

fabrobinet commented 10 years ago

@RemiArnaud's point is that glTF is not an inter-exchange format. So adopters may convert assets to fit their needs.

But it doesn't mean we can afford or want to specify here more variations of the same concept than what we absolutely need for a V1.0. Always better to be a bit frustrating, get more feedback and open up later. (nothing worse than API legacy:)).

Now, I'd like bring back the discussion at the "needs" level and evaluate if there a case at run-time level that really mandates to get axis-angle representation at runtime over quaternions. So here are some facts here:

axis-angles can represent any angle and multiple spins, while quaternions are just orientation.
Using one or another shouldn't make much difference for statics scenes
for animated scene more keys may have to be generated if we only choose quaternion.
In term of storage size, this won't make a big difference because complex animations have to be sampled anyway. (*) Small ones say just a 360 tour would be breaked into 2 keyframes.
most of us use quaternions in their engine for animaitons (slerp).

That's why on a practical matter, I tend to agree with Patrick to start conservative and only with quaternions. Because eventually they lead to more work on converter side and less work for clients which the trade-off that helps us make decisions here.

Important Note ('*' glTF just supports 3 transforms for animations: translation, rotation, scale. Input files (especially COLLADA ones) often carries more and in any order. You may have a stack 10 of transforms with rotation, scale, rotation, translate, translate coming in any order. So get to export just 3 transforms out of them you need to build a matrix and decompose it. And then you end up with an orientation in place of the rotation, that's why in practice, even with axis angle output what's you'll really get is an orientation and not a rotation)

Note: @RemiArnaud please use GitHub to answer issues:).. mail replies messes up answers...

meshula commented 10 years ago

A couple more points.

approximating curves with a different representation can introduce errors, especially in deep hierarchies. These errors can show up as incorrect end effector positions, and shuddering.
euler animations will tend to compress much better on characters because of restricted joints such as elbows
interpolation of both Euler and quaternion can be ambiguous and may make more sense in one orientation or another depending on if we are talking about knees, propellors, or tumbling rocks.

RemiArnaud commented 10 years ago

I will claim that most if not all vertex shaders are using model matrices at the end.

So, why don't we follow that logic and just do matrices? I do know of several engines that do just that, and then apply a compression algorithm specific to matrices to reduce the size of the animation data.

It is all a matter of what the application point of view is. Previously someone pointed out that if you want to do robotic arms, and enable the application to do some IK, it is necessary to provide an axis angle, as the axis itself is very important in the math involved for those applications. Also, if your application depend of knowing how many turns you made around the axis, then you can only know that with axis angle.

If you just care about interpolation animations, quaternions are just fine (if the converter did a correct job). So we're back to the question about limiting or not the use of the data/applications that glTF targets.

If you can't afford (the time) to specify another form of rotation than the one currently in the spec and the converter, then why not keeping what we currently have and working on other issues?

Clearly, axis/angle representation has more information than quaternion representation. Many different axis/angle will map to the same quaternion - as quaternions cannot store angles with multiple spins.

You already said this. And also say that you want to ignore this fact because it is fine to limit the use case to animations where this information does not matter. So basically say you are ok to reduce the scope of use of glTF. The problem is that I don't see a compeling reason to do that.

However I do see it to be a good convenience for the converter to export quaternions for applications that want to use this directly, but not at the cost of reducing the scope of glTF to other applications.

PS: Sorry, github web does not work on my phone. I turned off my computer a while ago. I hope this message can be edited on the web to clean it up if needed.

-----Original Message----- From: Fabrice Robinet notifications@github.com Date: Thu, 24 Oct 2013 13:50:13 To: KhronosGroup/glTFglTF@noreply.github.com Reply-To: KhronosGroup/glTF reply@reply.github.com Cc: Rémi Arnaudremi@acm.org Subject: Re: [glTF] Animation: quaternion vs. axis-angle (#144)

@RemiArnaud's point is that glTF is not an inter-exchange format. So adopters may convert assets to fit their needs.

But it doesn't mean we can afford or want to specify here more variations of the same concept than what we absolutely need for a V1.0. Always better to be a bit frustrating, get more feedback and open up later. (nothing worse than API legacy:)).

Now, I'd like bring back the discussion at the "needs" level and evaluate if there a case at run-time level that really mandates to get axis-angle representation at runtime over quaternions. So here are some facts here:

axis-angles can represent any angle and multiple spins, while quaternions are just orientation.
Using one or another shouldn't make much difference for statics scenes
for animated scene more keys may have to be generated if we only choose quaternion.
In term of storage size, this won't make a big difference because complex animations have to be sampled anyway. (*) Small ones say just a 360 tour would be breaked into 2 keyframes.
most of us use quaternions in their engine for animaitons (slerp).

That's why on a practical matter, I tend to agree with Patrick to start conservative and only with quaternions. Because eventually they lead to more work on converter side and less work for clients which the trade-off that helps us make decisions here.

Important Note ('*' glTF just supports 3 transforms for animations: translation, rotation, scale. Input files (especially COLLADA ones) often carries more and in any order. You may have a stack 10 of transforms with rotation, scale, rotation, translate, translate coming in any order. So get the 3 transforms you need to build a matrix and decompose it. And then you end up with an orientation in place of the rotation, that's why in practice, even with axis angle output what's you'll really get is an orientation and not a rotation)

Note: @RemiArnaud please use GitHub to answer issues:).. mail replies messes up answers...

Reply to this email directly or view it on GitHub: https://github.com/KhronosGroup/glTF/issues/144#issuecomment-27028575

fabrobinet commented 10 years ago

It is all a matter of what the application point of view is. Previously someone pointed out that if you want to do robotic arms, and enable the application to do some IK, it is necessary to provide an axis angle, as the axis itself > is very important in the math involved for those applications. Also, if your application depend of knowing how many turns you made around the axis, then you can only know that with axis angle.

This info is not available in the animations anyway. It's true that the animation with axis-angle will not have to be potentially split in multiple quaternions but it doesn't mean you will be able to know from there what's the maximum angles for IK. And you shouldn't get that info from animations...

This kind of info goes outside the scope of animations playback, for instance in COLLADA 1.5.0 there is:

<axis_info sid="a1" axis="man/j1/axis_x"> 
 <locked><bool>false</bool></locked> 
 <index><int>1</int></index> 
 <limits> 
 <min><double>-90</double></min> 
 <max><double>90</double></max> 
 </limits> 
</axis_info>

It's the kind of topic that will be welcomed to experiment as extensions in glTF or in later revisions.

I understand that's just an example, and there are maybe other more relevant situations, but I am just not convinced with this one for the reasons I just mentioned.

RemiArnaud commented 10 years ago

Why not?

All we ate talking about here is interpolation between 2 positions/orientations.

How do I go from point A tio point B? What method do I want to apply, and do I have all the necessary input data for the interpolation I want to do.

Axis angle have enough information to enable Direct angle interpolation, euler decomposition and interpolation, quaternion lerp, and even IK. Quaternions allow for ... Quaternion lerp.

Note that this is not enough information to provide for smooth interpolations, such as bezier and hermite , as then you need additional control points or tangents. So we probably need to add more to cover more use cases. Also, physics engines, another form of controllers do not generally work with quaternions,

fabrobinet commented 10 years ago

I agree with you and @meshula that for curves the current design will have limitations but we have to start somewhere - but in practice export plugins already samples curves and the more you sample, the smoother you get, no news here right ? Again extensions will be welcomed to handle these cases when absolutely necessary for V1.0 adopters. But overall speaking of glTF V1.0 scope I thought it was clear at least with @pjcozzi , @tparisi and you that we'll put the together the first requirements for animation playback, in a way that takes discretized input and developers just have to interpolate for replay. Where the data comes from and how it was discretized/sampled is all a converter matter at this time. I also agree with you @RemiArnaud that if there is anything unclear about this scope for glTF we should as editors clear this first and I propose to discuss it on monday.

Here:

If you just care about interpolation animations, quaternions are just fine (if the converter did a correct job).

What do you mean ? that the converter is not currently doing a correct job ? Yes there is more work to do to resample when needed but that's in progress. Converter already takes care of most transforms including flattening and merging or animations . Complete support will be there eventually.

Moreoever, do we agree that for complex animations due to COLLADA stack of transform (see above Important Note) and the fact that glTF just support TRS, (i.e no stack - like most engines) that either you sample/export a axis-angle or quaternion you will end with just an orientation in both cases ? I can send you examples offline if needed to show you one of these COLLADA files with dozen of transforms per node...

Here I am echoing @pjcozzi who has been advocating for quaternion because based on the experience of our implementations (that supports animations) this is the representation that surfaced as commonly used. But I'd be happy to hear from community what they think.And I hear you argument that one can select the kind he wants to convert, but simpler is better so it is worth having this discussion again. @meshula has been covering many use and we need to sort out here (and that's related to glTF 1.0 scope) is what's mandatory for animation replay. As proposed @RemiArnaud the converter should probably be renamed as compiler because data is backed and no round-trip won't be possible and properties that may exist in COLLADA will be ignored as of now (like IK).

@ryu2 and @meshula , @bhouston , @donny-dont and everyone reading this... In the context of animation playback, would exporting just quaternions cause issues for your engine ? or foreseeable problems ? would you be more comfortable that glTF supports both axis-angle and quaternion ? does your engines supports both internally ? do you always have to convert from one representation to another ?

bhouston commented 10 years ago

@fabrobinet quaternions is fine for pure playback. You can not always properly motionblur a quaternion if it does more than a 360 rotation thought, without some special case code, thus that is one limitation.

BTW http://clara.io now exports to glTF in the latest update.

fabrobinet commented 10 years ago

@bhouston awesome news, I'll try :) I don't know about the motion blur aspect WRT quaternion, I have to think/read up on this. I'll google that... As of now the only thing the converter would do is adding keys (i.e quaternion) to complete full rotation. Thanks for the input !

bhouston commented 10 years ago

@fabrobinet, the quaternion, motionblur issue is just because quaternions can't represent multiple revolutions. But if you always ensure keyframes are never separated by more than 180 degrees, you can figure out where the previous keyframe was and ensure that one can interpolate properly. If you allow for keyframes to be further than 180 degrees apart it is ambiguous which way the rotation went -- both directions would result in the same quaternion.

Basically quaternions can not specify revolutions. See this book page:

http://books.google.ca/books?id=X3hmuhBoFF0C&lpg=PA272&ots=tizSJBFwq1&dq=quaternion%20revolutions&pg=PA272#v=onepage&q=quaternion%20revolutions&f=false

fabrobinet commented 10 years ago

@bhouston ah yes, then that's exactly the issue the converter will take care of when adding keyframes as needed. Thanks !

bhouston commented 10 years ago

@fabrobinet When debugging Clara.io's glTF converter, remember that we first export to Collada before the glTF conversion. So if there is an issue just export to Collada and see if that file is okay (we just try to import it into Softimage, Maya, 3DS Max, etc...)

fabrobinet commented 10 years ago

@bhouston that's exactly what I did :) and I am writting you an email at the moment.. there are some compliance issues with the COLLADA file that we can take offline.

meshula commented 10 years ago

@bhouston On movies with airplanes, we ran into issues with motion blur and propellors. If the propellor is properly animated, it will be running at 2500 rpm or so, or 60 revolutions per second. When we corrected our interpolation to allow rotation angles greater than 2pi, the blur calculations became correct. I don't think it's a good idea to say that things are fine because rotation rate can be restricted to less than pi. Historically there have been 101 solutions to this problem using tricks with textured disks and things like that, but those don't behave properly in specular.

You can see our propellors here: http://www.youtube.com/watch?v=JF0cD1O3U8M :D There's a mix of realtime and offline rendering in there. It's typical now for realtime in this sort of application to do stochastic sampling in order to render things like this properly.

bhouston commented 10 years ago

@meshula Hello! Nice to run into you again! We chatted via email back in 2008 or so.

I completely agree with you for non-real-time rendering solutions, you need full revolution support (we have it in http://clara.io for example).

The reason why I think motion blur of revolutions is rare in the glTF case is that glTF is designed to be a real-time playback format. In those situations I do not image stochastic sampling to be something very commonly used in the browser for rendering glTF scenes, at least not a common case these days.

bhouston commented 10 years ago

@meshula Red Tails is beautiful, like everything I'm does really.

You say that stochastic rendering is common in real time but I am not sure of this. Is it actually common right now? Or are you anticipating it becomes common with the next generation consoles?

meshula commented 10 years ago

Hi Ben, yes, I remember :)

Perhaps it's not common, yet. I anticipate it becomes common as we transition from solving static aliasing issues to temporal, because it has to become common since we generate moving images. TXAA reportedly uses temporal jitter to attempt to solve the issue, so I take that as support for the idea that others are thinking along these lines.

As early as The Force Unleashed, we ray traced certain volumetric elements, such as lightsabers; before and after transforms went into the shader so that blurs would look proper. An element like my propellors could also be a stochastic volume element, in an otherwise non-stochastic scenario. It would be nice for car wheels in a racing game too, much better than the older approaches such as transitioning from polys to textures with different baked angular blurs. Iterations of the engine that evolved out of the realtime previs engine in the Red Tails video had various stochastic elements, including the lens model. Since we'd been doing it for a few years I have to imagine that a lot of other people have been pursuing it as well.

The Brigade folks are getting close (i.e., convergence is happening within expected frame times in some cases) with full scene rendering - http://raytracey.blogspot.com/ To my eye, it's not ready for a game quite yet, but looks like it's getting there.

Coming back to the gltf file representation, in a racing game it is currently common to use the angular velocity of the wheel to control model LOD. In the case of physics-driven rendering, the angular velocity is of course directly available, but in the case of a playback a representation with >pi rotational resolution would be needed. (Obviously I am mentally stuck on having both quaternion and euler representations ;)

fabrobinet commented 10 years ago

@pjcozzi @tparisi and I talked today about this and are ready to move forward supporting both axis-angle and quaternions. @meshula @bhouston and @RemiArnaud were either not opposed or strongly in favor to that, so marking as resolved and flagging as converter work for the remaining tasks. (re-sample animations when needed..).

fabrobinet commented 10 years ago

And thank you guys for all feedback and use cases !.

RemiArnaud commented 10 years ago

One thought:

In the converter, you'll need a MinSamplingInterval - or MaxSamplingRate parameter. If an object is rotating at 1000 RPM, you probably don't want to produce 2000 quaternions per seconds of animations. When you hit the max sampling rate, you'll want to output a warning to let the user know they should use axis/angle instead of quaternion.

-----Original Message----- From: Fabrice Robinet notifications@github.com Date: Mon, 28 Oct 2013 10:05:41 To: KhronosGroup/glTFglTF@noreply.github.com Reply-To: KhronosGroup/glTF reply@reply.github.com Cc: Rémi Arnaudremi@acm.org Subject: Re: [glTF] Animation: quaternion vs. axis-angle (#144)

And thank you guys for all feedback and use cases !.

Reply to this email directly or view it on GitHub: https://github.com/KhronosGroup/glTF/issues/144#issuecomment-27231993

donny-dont commented 10 years ago

Sorry for chiming in late. Its not a huge deal to support both formats, but I'm wondering if this sets a precedent that will end up bloating the format. When you start walking up the stack there's going to be contention on what the right way to do things is. In this case I'm personally tending towards picking the representation that's compact and allows for easy conversion to whatever format the underlying engine supports. Axis-angle takes up the same space as a quaternion and, correct me if I'm wrong, is the easiest to convert into whatever format the underlying engine uses.

tparisi commented 10 years ago

I have to admit I have forgotten the original motivation for quaternions over axis-angle. I can certainly think more clearly in axis-angle (as I imagine is true for many people). The conversion to quaternion is straightforward; the reverse has issues as we know.

In my current branch I am converting axis-angle to quaternion... which tells me that this branch at least is using axis-angle. @fabrobinet did you change things in Master to use quaternions?

fabrobinet commented 10 years ago

No. It's still axis angle. Some of us prefer quaternion because our engines just use quaternion internally for interpolation and having to deal with axis angle requires to add intermediate keyframes for angles > 180. So supporting both should please everyone.

fabrobinet commented 10 years ago

We,ll also need to add a way to differentiate between both. I'll follow up with a proposal, feel free to suggest something in the meantime.

tparisi commented 10 years ago

I'm OK with this. Per @donny-dont 's comments, I am concerned about this setting a precedent for bloat. OTOH the perfect can be the enemy of the good here; this is a very practical concession to the needs of different engines. But we must be ever-vigilant not to do this more than we have to...

meshula commented 10 years ago

As the old saw goes, make things as simple as possible but no simpler :)

RemiArnaud commented 10 years ago

Just wanted to point out that axis/angle can be converted to quaternion in the app, but not the other way around. So to Tony's point, keeping the spec/converter as-is, would fit all requirements and not bloat the spec.

On Mon, Oct 28, 2013 at 9:58 PM, Nick Porcino notifications@github.comwrote:

As the old saw goes, make things as simple as possible but no simpler :)

— Reply to this email directly or view it on GitHubhttps://github.com/KhronosGroup/glTF/issues/144#issuecomment-27278771 .

fabrobinet commented 10 years ago

just a new property will be added that is orientation for quaternions and a converter option.

fabrobinet commented 10 years ago

So orientation export is now supported as an option. We could either have enabled by default or no, but for now @pjcozzi @RemiArnaud @tparisi we want to test it in our engines before merging. (at least one of us, not sure when I'll time to do it :().

pjcozzi commented 9 years ago

Given that we haven't tested this in our engines and time is tight, I suggest we do not include this in the draft 1.0 spec.

pjcozzi commented 9 years ago

Any thoughts on pushing this post 1.0?

tparisi commented 9 years ago

It's easy enough implement and pretty common. I think we should consider keeping this for 1.0

On Tue, Sep 1, 2015 at 6:09 AM, Patrick Cozzi notifications@github.com wrote:

Any thoughts on pushing this post 1.0?

— Reply to this email directly or view it on GitHub https://github.com/KhronosGroup/glTF/issues/144#issuecomment-136713934.

Tony Parisi tparisi@gmail.com Founder, Third Eye http://www.thirdeye.gl/ Follow me on Twitter! http://twitter.com/auradeluxe Read my blog at http://www.tonyparisi.com/ Learn WebGL http://learningwebgl.com/ Mobile 415.902.8002 Skype auradeluxe

Read my books! Learning Virtual Reality http://www.amazon.com/Learning-Virtual-Reality-Experiences-Applications/dp/1491922834

Programming 3D Applications in HTML5 and WebGLhttp://www.amazon.com/Programming-Applications-HTML5-WebGL-Visualization/dp/1449362966 http://www.amazon.com/Programming-Applications-HTML5-WebGL-Visualization/dp/1449362966WebGL, Up and Running http://www.amazon.com/dp/144932357X

pjcozzi commented 9 years ago

Will you be able to test the converter and a client-side implementation in time for 1.0?

If not, we could consider pushing 1.0 or target it for 1.0.1 or an extension.

KhronosGroup / glTF

Animation: quaternion vs. axis-angle #144