Re: [eigen] Patch for quaternion normalization and cross product for Vector4f

[ Thread Index | Date Index | More Archives ]

short answers:

- start<3>() returns an expression of the first 3 coeffs.

- for matrices, I think the default Transform is perfect for that.

- I'll commit the cross3 optimized routine in Geometry now
 => immediate consequence: people can do their own cooking to mimic
vec3 using vec4, including cross products.

- and then if you write a small doc/tutorial to explain how to best
use vec4 to mimic vec3, then I'll be please to include it as well.

for the rest (more transparent support of vectorized vec3) we can see
later, very low priority to me even though I mostly deal with vec3
objects !


On Wed, Mar 11, 2009 at 2:15 PM, Rohit Garg <rpg.314@xxxxxxxxx> wrote:
> <snip>
>> about vector3 ops using aligned vector4, currently I would say that's
>> up to the user to correctly use vector4 to ensure the last coeff is
>> zero when it really as to be 0 (dot/norm) and uses .start<3> when
>> there is no alternative (minCoeff). Am I right if I say that in that
>> context the only missing feature is a vectorized cross product ? If
>> so, then the easiest way is to add a cross3() function. Another option
>> would be to check the MaxSizeAtCompileTime value to automatically
>> vectorize:
>> a.start<3>().cross(b.start<3>()), the problem is the return type which
>> have to be a Vector4.
> Yes it(keep the last coeff 0) is, I volunteer to write the docs for
> this (use of vec4f instead of vec3f to use sse) in case it is
> accepted. I too can't recall any other thing which is nonvectorized.
> Cross of two vec3's producing a vec4 is pretty confusing and non
> orthogonal from API cleanliness POV. People are immediately going to
> ask "what in the name of god makes vec3 cross vec3 = vec4?" IMHO, A
> good API is one where the ins and outs are predictable.
> BTW, what is start<3> and what does it do?
>> Another related thing: we already can do:
>> typedef Matrix<float,3,1,0,4,1> AlignedVector3;
>> so if we improve the vectorization to better take into account the
>> Max{Row|Cols|Size}AtCompileTime values, then all coeff wise ops could
>> be easily vectorized. Likewise, the cross product could automatically
>> return an "AlignedVector3". The only problems I see are:
>>  1 - the dot/norm stuff (we would need specialized versions of ei_predux)
>>  2 - the evaluation to a temporary if the Max*AtCompileTime values are
>> not taken into account (I don't remember how it behaves)
> Benoit -> "Things get more complicated with 3x3 matrices. Here it seems that for
> good performance with matrix products, what we need is to embed the
> 3x3 matrix as top-left corner in a 4x4 matrix with zeros outside. So
> it is really getting complicated, and very wasteful of memory.
> Probably a reason to not think of matrices for now."
> @Benoit: as far as matrices are concerned, their issues are a natural
> extension of the issues with vectors. I think the best way would be
> just to let people use vec3 class and only those which actually need
> sse use vec4 but make the vectorization complete(ie do all ops) for
> them. For some people, using 3 instead of 4 is a waste, for others it
> isn't. Let people choose what they need instead of deciding for them.
> Regards,
> --
> Rohit Garg
> Senior Undergraduate
> Department of Physics
> Indian Institute of Technology
> Bombay

Mail converted by MHonArc 2.6.19+