Using ConvertPts on the point output shows the correct right hand point. (The "inverted" point.)
The vector displayed for the inverted point does seem to be incorrect. I'm investigating the code, which seems very difficult for my brain to understand :-)
- Brian
In the vector.js code, line 31 creates the vectors, using orient_line_to_line. line 287 codes for the incorrect inverted vector.
this and that do not make sense to me...
I've watched only #6 and #10, so far. The perspective is about areas and volumes of linear transformations.
#10 is about Cross Product, in 2D and 3D. A negative determinate means that the 3rd vector of the cross product is in the negative direction.
So maybe the vector.js code for Cross Product, line 287, should take the determinant (3D?), and then the code in line 34 modified so that in the case of a negative
determinant, bPt1 would be modified to be (0, 0, -1), instead of (0, 0, +1). (?)
Then the third vector "c" would still follow the right hand rule.
(Note that point "c" is calculated correctly, it is just the vector display that is not correctly oriented for the case of a negative determinant.)
In Pilou's example, when the order of the Cross Product is reversed, the sign of the determinant is reversed. The displayed vector should be negated.
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.
LineToLine.gif
