Am 16.08.2013 21:38, schrieb Anthony D. Baye:

>>       object {
>>         ...
>>         translate A
>>         rotate B
>>       }
>>
>> /obviously/ not only translates the object, but also rotates it. If the
>> object in question is a sphere originally created at <0,0,0> this
>> doesn't matter, but if it is, say, a cube, then this changes the
>> orientation of its edges in space.
>>
>> To compensate for this, you'd have to apply the inverse rotation to the
>> object first, /then/ translate by A, and finally apply the rotation by
>> B. This will indeed effectively apply a rotation to the A vector used
>> for translation, while leaving the object's orientation in space
>> effectively unchanged.
>>
>> I think there's no need for additional clarification in the docs, as
>> this should be obvious enough once you think a few moments about the
>> features involved (translate, rotate, and vrotate). The docs can't
>> account for /all/ exotic combinations of features.
>
> I wasn't considering the object's orientation, only it's position w/r/t to the
> origin, so I guess I was at least partially wrong.
>
> Still, the transformation is not at all as obvious as you say it is: Not
> everyone is a wiz at visualizing complex 3D transformations.
>
> Reminds me of math teachers talking to the chalkboard and saying "The obvious
> conclusion is..." when it's obvious to them, but they aren't the student.

Sorry for the ambiguous wording; I didn't mean to call the details of 
the inverse rotation "obvious" (I'm well aware that it isn't), just the 
plain fact that

        object {
          ...
          translate A
          rotate B
        }

applies a rotation to the object, while

        object {
          ...
          translate vrotate(A,B)
        }

doesn't (and as far as the latter is concerned I'm also aware that it's 
not necessarily obvious at first glance, hence "obvious enough once you 
think a few moments [...]").

Post a reply to this message