I believe the AlignToPath node (3D.Transform) is bugged, the results don’t make sense to me:
up vector is perpendicular to the up-direction specified because of crossing up with forward direction
it should (probably) align the last element of the spread with the first one. here, the LastOrDefault nodes is used wrongly and the same spread is concated to itself.
here is a version of that operation that i’d expect. up actually looks up and the resulting coordinate system is righthanded: AlighToPath_fixed.vl (31.4 KB)
okay, the more I think about it, it becomes apparent that this approach is always error prone when the up-vector comes close to the direction vector of 2 consecutive points.
this version AlighToPath_v2.vl (38.0 KB)
deals well with cases where the up-vector is perpendicular to the vector between 2 points. however, the rotations feel unnatural and will break as described above when the angle between up-vector and direction becomes smaller.
one solution that comes to my mind would be to:
take 3 points
calculate tangent as vector of 2 successive points (1st axis)
calculate the normal of the plane which the 3 points describe (obviously only possible if they don’t line up)
use this normal for the second point’s up-vector (2nd axis)
calculate the third axis as cross product of axis 1 and 2
special case: first and last point of list - deal with them e.g. by duplicating axis from previous/next points
but actually i’m not 100% sure if this way of dealing with it is actually the intended use of this node. can somebody shine a light on this?
Just confirming what you already discovered, this issue cannot be solved without looking at results of neighbors, so it’s an iterative algorithm that unfortunately cannot be calculated in parallel, i.e. not possible to implement efficiently in a shader.
But there might be ways to have a better behavior with more info at the start than just the 3d points. I had a beta patch that was working well, can look it up when back on the PC.
