Hello everyone, it has been a while since my last post and was thinking to share a few things.
The main thing I will be talking about here is the orient attribute and using it for the rotation of your instances and models.
I often get questions about instances being rotated wrong and want to talk a bit more about how to get more control.
The Common Issue
What happens often if instances are rotated wrong or even not appearing, can come from a conflict in the merge node. When you merge different node together the changes are high they have different attribute values. The merge node itself doesn't know what value to assign when input A and B have different attributes. What the merge nodes does often is fill in 0 as value, with as result wrong rotation or scale being 0.
Here is an example of that in the spreadsheet.
The merge node itself gives a warning about this and tells you which attributes are causing the problem.
This is the reason why it is important to double check what attributes are mis-matched. Here I'm also mainly talking about pointclouds and instance. For example making sure all inputs of the merge have a decent scale value. Tip here is to stay consistent with what attributes you use on pointclouds for instancing ( N, scale, pscale, orient,...)
The merge node will take the first input as a reference for the other inputs.
Using the orient (@orient)
Now we know a bit about what could cause the issue and let's talk a bit about orient as rotation attribute.
First of all orient attribute is a Quaternion (vector 4) . Then another important thing to know is that orient has priority over the N. When your points have a N and an orient, the copy to points node will ignore the N if there is an Orient attribute.
So here comes back the fact that if you merge different nodes together you can have conflicts between N and orient. This results then in wrong rotations. So solution is again to stay consistent with the attributes once you use orient on pointclouds use them for other pointclouds as well. So there is no conflict when merging nodes.
Overall I now recommend using the orient instead of Normal for rotation. I have less issues when using the orient. The main thing being that it has priority over Normal and I don't have to worry about the normals of other nodes. For example when your tool outputs geometry and pointclouds, they both will need a normal but the normal of a model is different that the one of a pointclouds.
Convert N to orient
Let's talk about converting the Normal to an orient attribute. Since orient is a quaternion, this can make things more complex then just a vector3 for rotations. So we can convert the normal to orient as solution. You can still use a workflow where you calculate the N for the rotation and when you are done you convert it to orient to avoid issues later on, with merging for example.
Let's just use VOPs to convert it.
In the image above here we first import the Normal (@N) and the up vector. From that make an instance transform and here you can extract that matrix and the quaternion for the orient. With VOPs it is quickly done and you can wrap this up is a HDA to use this later.
There are a couple interesting nodes in VOPs here, like the rotate node. With that you can easily rotate models on a custom axis.
This is how the VOP network looks like now. Of course you can plugin a custom rotation axis in the axis, here I just used the input Normal.
That was it for the post. I hope this was helpful to understand more about what is going on for instances and their rotation.
See you on the next one :)