Rotate/Orient/Alignment/Quaternions...etc.

[mstarktv]

I'm trying to mess around with orienting a particle's alignment to it's vector. Or a watered down version would be a cube on a path that follows it based on the particle's vector or velocity. Basically, orienting the particle to "speed space" if that makes sense? I tried mixing Normals and Velocity to possibly get them aligned but I'm pretty much lost. 

I took a look at @mestelahere to help me out, but I'm pretty much in over my head trying to do it in Houdini. I attached my file that is just a spinning circle with box's copied onto them. I was trying to make a simple scene where the boxes rotation matches it's vector.

So nothing too out of the ordinary, but still kind of confusing. Thanks :)!

velAlign.hipnc

[mestela]

Gifstorm!

First I've used a visualizer sop to show @v coming out of the trail sop:

That makes sense so far.

To make the next step easier to understand, I've shrunk the face that sits along +Z, and coloured the +Y face green, +X red, +Z blue.

So, that done, here's that cube copied onto the points, with the v arrows overlaid too:

The copied shapes are following the velocity arrows, but they're a bit poppy and unstable. So why are they following, and why are they unstable?

The copy sop looks for various attributes to control the copied shapes, @v is one of them. If found, it will align the +Z of the shape down the @v vector. Unfortunately what it does if it has only @v is a little undefined; the shapes can spin on the @v axis when they get near certain critical angles, which is what causes the popping and spinning.

To help the copy sop know where it should aim the +Y axis, you can add another attribute, @up. I've added a point wrangle before the trail, with the code @up = {0,1,0}; ie, along the worldspace Y axis:

you can see all the green faces now try and stay facing up as much as they can (note the view axis in the lower left corner), but there's still some popping when the velocity scales to 0, then heads in the other direction. Not much you can do about that really, apart from try some other values for @up, see if they hide the problem a little better. What if we set @up to always point away from the origin? Because the circle is modelled at the origin, we can be lazy and set @up from @P (ie, draw a line from {0,0,0} to @P for each point, that's a vector that points away from the origin):

Yep, all the green faces point away from the center, but there's still popping when @v scales down to 0 when the points change direction. Oh well.

Maybe we can venture into silly territory? How about we measure the speed of v, and use it to blend to the @up direction when @v gets close to 0?

Better! Still a bit poppy, but an improvement. 

Here's the scene with that last setup:

vel_align_example.hipnc

 

To answer the other key words in your topic title, I mentioned earlier that the copy sop looks for attributes, obviously @v and @up as we've used here, but if it finds others, they'll take priority. Eg, @N overrides @v. @N is still just a single vector like @v, so it too doesn't totally describe how to orient the shapes. You could bypass the trail and the wrangle so that there's no @v or @up, set @N to {0,1,0}, and all the shapes will point their blue face towards the top. Without any other guidance, it will point the red side of the shapes down +X.

 

If you give it @N and @up, then it knows where point the green side, and you get a well defined orientation. 

 

While using 2 attributes to define rotation is perfectly valid, there are other options. The one that trumps all others is @orient. It's a single attribute, which is nice, and its party trick is that it defines orientation without ambiguity, using a 4 value vector. The downside is quaternions aren't easy to understand, but you don't really need to understand the maths behind it per-se, just understand what it represents. The simplest way is to think of it as @N and @up, but glommed into a single attribute. Another way is to think of it as a 3x3 matrix (which can be used to store rotation and scale), but isolated to just the rotation bits, so it only needs 4 values rather than 9 values.

 

In houdini, you rarely, if ever, pluck quaternion values out of thin air. You normally generate what you need via other means, then at the last minute convert to quaternion. Lots of different ways to do this, coming up with ever funkier smug ways to generate them in 1 or 2 lines of vex is something I'm still learning from funkier smug-ier co-workers.

 

Eg, we could take our fiddled @v, and convert it to a quaternion:

 

@orient = dihedral({0,0,1} ,@v);

 

What that's doing is taking the +Z axis of our shape-to-be-copied, and working out the quaternion to make it align to @v. You could then insert an attrib delete before the copy, remove @N, @v, @up, and now just with the single @orient, all the shapes rotate as you'd expect.

 

 

vel_align_example_orient.hipnc

 

 

 

[mstarktv]

This is sooooo much help. Thanks again, Matt! This is an area of Houdini that I'm trying to figure out. Alignment in other packages is just a click away or "built-in" so just trying to find how to do it has been a trek.

I found somewhere either on this forum or sidefx about using the trail sop to just output velocities so that's hwy I added it. I posted that rotating circle when I should have just posted a simple particle sim. I'm more or less interested in that; having particles orient to the vector and then adding variation into that.

As a quick aside, what are you using to export your animated gifs? That would be super helpful for the forum over posting a screenshot and describing what's happening. Thanks man!

[mestela]

Particles get v calculated automatically, so you would only need to add up if you're getting unstable rotations, or if you want to add different tilt and banking per particle. 

I use licecap for gifs, it's great. 

https://goo.gl/qG8pl

 

[mstarktv]

Thanks, Matt!