> Order of rotations always matters.
Yep, I agree.
But having said that, a quaternion only specifies a particular
orientation, it doesn't have any history involved with it (unlike Euler
angles, which specify a sequence of 3 rotations about 3 different axes).
I think you're assuming that we're saying "given any two particular
configurations of the cube, quaternions would describe the transition
between them". This obviously isn't the case. But if you stored the
quaternion orientation at each separate 90 degree twist, then
theoretically it should work perfectly.
Unfortunately I don't have XSI in front of me to be able to test this!
Andy
> Andre,
>
> Order of rotations always matters. It is a mathematical consequence of how
> rotations are defined. (and not something we can work around in this
> universe anyway ;-)
>
> If you rotate the top face of the cube by 90 degrees and then the left
> face by 90 degress you will get a different result than rotating the left
> face followed by the top face. Using quaternions doesn't change this
> fundamental fact.
>
> I think you are confusing different things. Yes, quaternions have some
> very nice properties (for interpolation) but it doesn't help when you have
> stacked rotations. (as in a transform hierarchy)
> --
> Brent
>
> -----Original Message-----
> From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On Behalf
> Of André Adam
> Sent: Thursday, November 01, 2007 12:15 PM
> To: XSI(at)Softimage.COM
> Subject: Re: rubik's cube
>
> -snip-
> "Quaternions are not a magic bullet for rotations. It is simply a
> different way of interpolating between two orientations.
> The problem with the Rubik's cube rig is not the interpolation but rather
> the fact that for rotations the order of operations is important"
> -snip-
>
> Not really, the trick about quaternions is that there is no order of
> operations, and the path of interpolation is always a straight line. In
> Euler space, order of operations and interpolation depend on each other.
>
>
> Brent McPherson wrote:
>> Quaternions are not a magic bullet for rotations. It is simply a
>> different way of interpolating between two orientations.
>>
>> The problem with the Rubik's cube rig is not the interpolation but
>> rather the fact that for rotations the order of operations is important
>> and if we perform a rotation A followed by rotation B it will be very
>> different than if we applied B first and then rotation A.
>>
>> Therefore, the crux of the Rubik's cube rig (which seems to be a thread
>> that comes up for every 3D application at some point) is how we apply a
>> series of rotations to the cube one after the other. Therefore, most
>> solutions I have seen involve stacking all the rotations that are
>> applied to the cube.
>>
>> I haven't seen one as elegant and animator friendly as Helge's solution
>> though!
>> --
>> Brent
>>
>> -----Original Message-----
>> From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On Behalf
>> Of André Adam
>> Sent: Thursday, November 01, 2007 7:59 AM
>> To: XSI(at)Softimage.COM
>> Subject: Re: rubik's cube
>>
>> Depends on the rotation distance you are keyframing. If you rotate a
>> section by 270°, quaternions will make that a -90° move. You would then
>> have to set multiple keyframes on the way as a path guidance for the
>> quaternion math, with all those hassles regarding the fcurve
>> visualisation of quaternions introduced.
>>
>> -André
>>
>>
>> Andy Nicholas wrote:
>>
>>> What would happen if you converted the keys to quaternions? Wouldn't
>>> that
>>> solve it?
>>>
>>> Andy
>>>
>>>
>>>
>>>
>>>> Be careful, that should pretty much immediately get you into gimbal
>>>> lock
>>>> trouble.
>>>>
>>>> -André
>>>>
>>>>
>>>> pingo van der brinkloev wrote:
>>>>
>>>>
>>>>> ok I got a really easy solution.
>>>>>
>>>>> Make 9 boxes and distribute them 3x3x3 (the cube)
>>>>>
>>>>> select all the cubes and center their center in 0,0,0
>>>>>
>>>>> Now you can select sides and rotate them and it works like it should.
>>>>>
>>>>> Just remember to flatten the animation keys.
>>>>>
>>>>> cheers!
>>>>>
>>>>> pingo
>>>>>
>>>>> On 31/10/2007, at 14.47, Adam Seeley wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Oop, went too soon,
>>>>>>
>>>>>> How about .... lattices that cover each of the 6 sides, which are
>>>>>> then applied during each rotation, frozen and removed after the
>>>>>> animation?
>>>>>>
>>>>>> Again, not very interactive or scrubbable.
>>>>>>
>>>>>> Adam.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: owner-xsi(at)Softimage.COM
>>>>>>> [mailto:owner-xsi(at)Softimage.COM] On Behalf Of Adam Seeley
>>>>>>> Sent: 31 October 2007 13:38
>>>>>>> To: XSI(at)Softimage.COM
>>>>>>> Subject: RE: rubik's cube
>>>>>>>
>>>>>>> How about
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: owner-xsi(at)Softimage.COM
>>>>>>>> [mailto:owner-xsi(at)Softimage.COM] On Behalf Of Oz Adi
>>>>>>>> Sent: 31 October 2007 13:35
>>>>>>>> To: XSI(at)Softimage.COM
>>>>>>>> Subject: Re: rubik's cube
>>>>>>>>
>>>>>>>> thanks guys, for the info.
>>>>>>>>
>>>>>>>> I've already tried the freeze transforms idea, and it does
>>>>>>>>
>>>>>>>>
>>>>>>> work, the
>>>>>>>
>>>>>>>
>>>>>>>> only thing that bothers me is, when the client want to change some
>>>>>>>> animation, it should be a nightmare (I need to do a 25-30
>>>>>>>>
>>>>>>>>
>>>>>>> sec one shot
>>>>>>>
>>>>>>>
>>>>>>>> animation)
>>>>>>>>
>>>>>>>> To try and improve this method,
>>>>>>>> I am thinking of having a square curve near each of the
>>>>>>>>
>>>>>>>>
>>>>>>> cube's side,
>>>>>>>
>>>>>>>
>>>>>>>> and a ppg with 6 boolean switches, each switch for each
>>>>>>>>
>>>>>>>>
>>>>>>> sqaure curve,
>>>>>>>
>>>>>>>
>>>>>>>> as the animator, it's my responsibility to make sure, only
>>>>>>>>
>>>>>>>>
>>>>>>> one switch
>>>>>>>
>>>>>>>
>>>>>>>> can be on in a given time.
>>>>>>>> Then have a scop on each little cube, to check which switch
>>>>>>>>
>>>>>>>>
>>>>>>> in on, and
>>>>>>>
>>>>>>>
>>>>>>>> rotate with it's corresponding square curve this is of course,
>>>>>>>> some
>>>>>>>> kind of a "simulation", meaning I cannot scrub the
>>>>>>>>
>>>>>>>>
>>>>>>> timeline, because
>>>>>>>
>>>>>>>
>>>>>>>> the little cubes has no keyframes.
>>>>>>>> image: http://www.ozadi.com/pix/rubiks.jpg
>>>>>>>> but maybe after the animation is approved I can plot their
>>>>>>>>
>>>>>>>>
>>>>>>> transfomrs.
>>>>>>>
>>>>>>>
>>>>>>>> what do you think?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Joe Laffey wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Wed, 31 Oct 2007, kim aldis wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> You can pull them apart easily enough if you want to see
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> how they
>>>>>>>
>>>>>>>
>>>>>>>>>> work. Peel the colours off and you'll see the screws
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> that hold it
>>>>>>>
>>>>>>>
>>>>>>>>>> together.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> No need to remove screws to take the Rubik's apart. Just
>>>>>>>>>
>>>>>>>>>
>>>>>>>> turn one side
>>>>>>>>
>>>>>>>>
>>>>>>>>> 45 degrees, and then either stick a flathead screwdriver, or your
>>>>>>>>> thumb under the middle cube of the row and lift.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I am sure there is Google/YouTube reference for this.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Joe Laffey | Visual Effects for Film
>>>>>>>>>
>>>>>>>>>
>>>>>>> and Video
>>>>>>>
>>>>>>>
>>>>>>>>> LAFFEY Computer Imaging |
>>>>>>>>>
>>>>>>>>>
>>>>>>>> -------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>> St. Louis, MO | Show Reel
>>>>>>>>>
>>>>>>>>>
>>>>>>> http://LAFFEY.tv/?e07635
>>>>>>>
>>>>>>>
>>>>>>>>> USA
>
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
> unsubscribe xsi
>
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
> unsubscribe xsi
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
