On the distinction between orientation and rotation, it's not hard and fast but I tend to use "orientation" when talking about a static pose, and "rotation" when talking about applying a transform (i.e.actively turning something). The final orientation is the product of the successive rotations that something took to get to that pose, but it's also the rotation that you would apply to get to that orientation from an unrotated pose in one step.
It's a bit like positions and translations. The final position is the sum of all the translations that have been performed, and it's also the translation that you woould apply to get there from (0, 0, 0). Make sense? gray From: [email protected] [mailto:[email protected]] On Behalf Of Bradley Gabe Sent: Tuesday, March 05, 2013 06:34 PM To: [email protected] Subject: Re: Orientation and vectors, foundations Based on what you just wrote here, it's clearer what you want to do with this knowledge, and believe it or not, there's a simple answer. Remember that an orientation vector gives you an offset from origin so you can create an x-axis (1,0,0) y-axis (0,1,0) and z-axis vector (0,0,1), and then set their visualization colors to red, green, blue. Use 3 [Rotate Vector] nodes and whatever orientation input and you will be able to visualize the orientation's resulting offset from origin. This is literally converting your rotation to position reference vectors. Of course, setting your rotation visualization to axis gives you the same kind of visual info, but this way, at least the concept of how the orientation is affecting position vectors gets illustrated. Now something TD's might be initially confused with is direction to rotation in ICE. When using a direction constraint for rigging, it's the x-axis that points at the target, and the y-axis that's used to establish the up-vector. With ICE, remember that particle systems often use sprites, which we want to face the camera... so direction to rotation uses the y-axis for point at, and the x (or z) axis to resolve the up vector. On Tue, Mar 5, 2013 at 5:13 PM, Andy Moorer <[email protected]<mailto:[email protected]>> wrote: ah I see where your going with this Andy, so how can I get a particles rotation into a current direction of rotation vector? say its spinning or 'tumbling' how to get the vector to rotate with it. I was thinking an 'up vector' but particles dont have them Yeah kinda, but more generally. I had a situation where I had an array of vectors which I was using to represent a "direction", and had occasion to pull out a "rotate vector" node, and around that point I got irritated that there were "rotations" and "orientations" which are being treated as separate-but-interchangeable types and this made me realize that I clearly wasn't following someone's logic. But it's also stuff I've been wrapping my head around for some time. I remember once when I was fortunate enough to be working with Brad on a job he spent some time helping me out with visualizing matrices and warned me it would take about a year to get a feel for them. He was right, and having been told that I kept plugging away, comforted to know visualizing this sort of thing generally isn't intrinsic, but practiced. This is kind of a superset of that - I "get it" now with using matrices to swap around frames of reference and it's been a huge benefit and opened up a lot of fun things. But there are a lot of loose ends to getting a "complete" picture where I can translate in my mind what I'm doing into the several ways one can go about doing the same operations... As Grahame puts it the different "formats," or as in Brads answer the different "heuristics." As a in-the-trenches TD it's easy to maintain a "it just works" way of thinking without seeing a bigger picture (because you're busy!) and I realized that it's very easy to fall into this with rotations in ICE, because we have pretty good tools for getting things done practically in a series of defined workflows. And next thing you know, you're reaching for a node and realizing you've lost sight of what you're really doing under the hood. :P Your example is a good one, though, if I get what you're saying... an easy and common sense way to think would be that you could take a "get particle orientation" node and want to translate that orientation into a vector which you could then rotate with a "rotate vector" node and expect that to give you a local rotation. Which, of course, doesn't work - and if you look for some kind of "convert orientation to vector" you're going to come up empty, and for good reason. But it's not so silly to think that it might work that way, and I remember a time when I could have fallen into this kind of trap. But the reason why this seemingly simple operation doesn't make sense gets difficult to express, at least for me. I'm not at a point where, if an artist asked me to help them (having gone down this path) I could teach them how to look at it. And I figure if I can't teach something, I probably don't understand it well enough. :P
<<attachment: winmail.dat>>
