I had a look to the code. I'm sure you will not find a bug. It seem that the line 35 generates the problem.
The function to create the vector-display works as follow:
- creating a line with length 1 and a cone for the tip of the base vector display
- orient this base vector display to start and end of the vector that should displayed by using "factory('orientlinetoline', that.bVec, bPt0, bPt1, tPt0, tPt1, null, 'scale, stretch');"
but it seems that here is a problem - orientlinetoline generates weired results (tested with MoI V3) when the target has the same orientation as the start orientation especially in the main directions. After the factory is initialised and get other inputs (not in the main dirs) everything works fine as espected. Maybe Michael have a look.
it's difficult to say what happens. I think that internally a transformation matrix is used for this operation/factory. To create one, you need additional informations like the rotational information that are not given by two lines and certainly not when they are parallel. I had the same problem for the getCrvSFrame. The only info you have here is the direction/tangent of the curve. To create a frame/local coordinate system I used the dominant directions of the main coordinate system. That leads to some weired effects while changing the curves geometry -> flipping axes. Another method would be to use also the center of a soothing circle, but that would fail for straight lines. And yes - it is similar to the gimbal lock. A possible workarround is to add tiny values for the display of the vector - that helps the factory to calculate the orientation.
Maybe Michael can tell us what's going on under the bonnet.
re:
> but it seems that here is a problem - orientlinetoline generates weired results (tested with MoI V3) when the
> target has the same orientation as the start orientation especially in the main directions. After the factory is
> initialised and get other inputs (not in the main dirs) everything works fine as espected. Maybe Michael have a look.
It looks like a bug in orient line to line, part of how it works is it takes the cross product between the 2 directions to make a vector to rotate around but it is not handling the case well when the 2 directions are parallel when the cross product is undefined. I'll investigate to see if I can fix up that case.
Hello Pilou,
at first - great job.
ColorVec only make sense for a bundle of vectors - then it colors the vectors dependent of their length.
Nothing more.
Hello Frederick,
it's a while ago that I wrote new nodes. But from time to time I have a look to the forum and I answer questions if possible for me.
At the moment Wayne picked up the ball and is making a great job to extend the NE. James not only shows with impessive things what is possible, he also manage the extensions for the NE.
So is the package from James a good starting point.
LineToLine.gif
