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.
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.
LineToLine.gif
