Hi!

I've been watching and reading a decent amount of stuff about orienting things, especially when it comes to using copytopoints. Here are some of the resources I've used:

• https://www.cgforge.com/blog/copy-to-pnts-0239751 [www.cgforge.com]
  
• https://www.tokeru.com/cgwiki/JoyOfVex17 [www.tokeru.com]
  
• https://www.toadstorm.com/blog/?p=493 [www.toadstorm.com]
  
• https://www.youtube.com/watch?v=MYRtwY-DQV8&ab_channel=JunichiroHorikawa [www.youtube.com]
  

Here's what I've gathered. There are two main options for orienting instances.

1. First, use v@N and v@up to define a new axis system. The object's original Z axis becomes oriented to the v@N vector defined on the points, and its original Y axis becomes oriented with v@up. The new X axis is computed under the hood using a cross product of v@N and v@up.
   
2. Second, use quaternions to define an axis of rotation as well as the angle of rotation around that axis. This is stored on the p@orient attribute.
   

Am I understanding this all correctly so far?

If p@orient is used, it overrides v@N and v@up (and I guess somehow v@v is also used for instance orientations?). The cgforge link states that p@rot is a quaternion that adds rotation in addition to the rotation already provided by p@orient. Is that correct? Why is that even useful?

Thanks!
Anson

that's correct, it is also pretty thoroughly explained here
https://www.sidefx.com/docs/houdini/copy/instanceattrs.html#priorities [www.sidefx.com]

Awesome, thanks! Any thoughts on why p@rot is a useful attribute when one might as well have just composed whatever additional rotation in the rot attribute to the orient attribute?

Thanks!
Anson

AnsonSavage
Awesome, thanks! Any thoughts on why p@rot is a useful attribute when one might as well have just composed whatever additional rotation in the rot attribute to the orient attribute?

Thanks!
Anson

- if you already have base rotation composed from v@N and v@up or v@v and v@up
it may be handy to be able to do additional offset as p@rot

p@rot is applied last so it so maybe another useful use case may be
- use p@rot to represent your stable alignment rotation (to the surface or whatever)
then p@orient or (v@N+v@up) can be your local space variations, or rotational offsets in local space of p@rot if you will (you can use Attrib Randomize, ... for these offsets without worrying about the main alignment)


obviously you can do any math you want and accumulate single p@orient to get the same result, but then you can also ask why do you need all those attributes if you can just use full 4@transfom matrix transform, it's simply for convenience and historical reasons