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 <andymoo...@gmail.com> 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 > > >
