[OpenWalnut-Dev] Eigen3 Transition

Wed May 4 15:32:43 CEST 2011

Its Done!

I, Ich and Io done the job that was intended to be done by everyone (with help of André). We now have our own fixed size vectors and matrices. I ported all the code to the new classes. There are some things to mention:

 * Default Constructor creates a zero-initialized Vector/Matrix (unlike the eigen3 types)
 * All the operations that are not expressable by operators are done as Non-Friend Non-Members (unlike osg::Vec)
   * this mostly concerns things like normalize, length, dot and cross for vectors
   * DO NOT add these functions as members
 * Operations with matrices/vectors of different integral type (double vec multiplied by float matrx) are possible.
   * In these cases, the resulting matrix/vec uses the better of both types.
 * The vectors are implicitly cast-able to osg::Vec types.
 * The matrices are implicitly cast-able to osg::Matrix types and Eigen3 Matrix Types (of same size)
 * There might be ambiguities with these cast operator:
   : Assume the following situation: you have an WVector3d, which is a 3D vector of type double.
   : Additionally you have a function f with two signatures: void f( osg::Vec3d ) and f( osg::Vec3f ).
   : If you call WVector3d v; f(v); you get a compiler error due to ambiguity, since v is implicitly 
   : cast-able to osg::Vec3f AND osg::Vec3d. If this problem occurs: use f( v.as< osg::Vec3d >() );

Maybe I forgot something. If you have questions, ask me

Bye
Sebastian

On Thu, 21 Apr 2011, Sebastian Eichelbaum wrote:

> Hi
> 
> I have added our new WMatrix. It is a fixed size matrix implementation covering our needs. It is able to be casted into eigen types easily and uses several eigen algorithms internally. 
> 
> The only warnings that exist are now related to WVector3D. I removed all ocurances of our old WMatrix4x4. If you want to port some of your code, just include "comman/math/linearAlgebra/WMatrix.h" -> this header contains everything you need to work with vectors and matrices. So if you port your code from WVector3D to our new WVector3d_2, use this new header. Many functions the OSG vector has as member functions are implemented as non-friend-non-meber functions in our implementation. This should be the only "problem" during porting.
> 
> If you encounter problems, mail me. I will port most of the graphicsEnine code from the old Vector to our new one in the first week of may.
> 
> Bye
> 
> On Fri, 08 Apr 2011, Stefan Philips wrote:
> 
> > And yet another mail. While I changed code to use the Eigen vectors
> > and matrices, I determined two things to look out for.
> > 
> > 1. In contrast to the old vector and matrix types, the Eigen types
> > are not initialized. So if you need them to be initialized, you have
> > to call setZero()
> > 
> > 2. The resize of a Eigen vector seems to destroy any values stored in it.
> > 
> > from the Eigen documentation: "If the current number of coefficients
> > of |*this| exactly matches the product /rows/ * /cols/, then no
> > memory allocation is performed and the current values are left
> > unchanged. In all other cases, including shrinking, the data is
> > reallocated and all previous values are lost."
> > 
> > Am 07.04.2011 12:18, schrieb Sebastian Eichelbaum:
> > >And another mail:
> > >
> > >- Eigen Matrices are Column Major by default. The old WMatrix was Row-Major. This means, if you use the operator( size_t, size_t ), the first argument is still the row. But if you use operator[], you need to transpose your indexing. Btw. do not use operator[]! This makes your code hard to understand.
> > >
> > >- Self-assignment;
> > >   * m = m*m  works
> > >   * v = m*v works
> > >   * v = v.dot() does not!
> > >     ->  use v.dotInPlace() instead
> > >   * generally: if you do not use standard operators but special member functions, use the InPlace version instead of self-assignment.
> > >
> > >Bye
> > >
> > >
> > >On Thu, 07 Apr 2011, Sebastian Eichelbaum wrote:
> > >
> > >>Hi
> > >>
> > >>Most of the module have an "owner". Those who don't will be fixed by me or someone else. One of these candidates might be Marching Cubes. Another "problem" is the nav slices module. I'll write a completely new one. This is especially important for the color-mapping.
> > >>
> > >>One hint for all:
> > >>  * the WVector3D_2 can't be casted to an osg::Vec3!
> > >>  * use toOsgVec3f in WVector.h
> > >>    * We did NOT (and you should'nt either) provide a copy constructor to WVector3D which allows this since an automatic replace of WVector3D with WVector3d_2 would break this.
> > >>
> > >>Another thing:
> > >>  * If you need to change an API in common for example which uses WVector3D
> > >>    ->  will break other modules and API
> > >>    ->  possible work-around: use the conversion methods in WVector3D to provide the same method with the other, new WVector3D_2 and mark the old function deprecated.
> > >>
> > >>ALL methods/classes marked deprecated will be removed by me afterwards. So please use it extensively!
> > >>
> > >>Bye
> > >>Sebastian
> > >>
> > >>
> > >>On Thu, 07 Apr 2011, Alexander Wiebel wrote:
> > >>
> > >>>Hi Sebastian,
> > >>>>* Check your modules
> > >>>What do you mean by "your modules". I had worked on/with many
> > >>>modules but I would regard only a few to be "my own". What happens
> > >>>with modules noone thinks they are "there own"? Will they be broken,
> > >>>deactivated or is there any other idea how to handle them? This
> > >>>question also applies to the color mapping change.
> > >>>
> > >>>Cheers,
> > >>>Alex
> > >>>_______________________________________________
> > >>>OpenWalnut-Dev mailing list
> > >>>OpenWalnut-Dev at lists.informatik.uni-leipzig.de
> > >>>http://lists.informatik.uni-leipzig.de/mailman/listinfo/openwalnut-dev
> > >>
> > >>-- 
> > >>Dipl.-Inf. Sebastian Eichelbaum
> > >>Universität Leipzig
> > >>Institut für Informatik
> > >>Abteilung Bild- und Signalverarbeitung
> > >>PF 100920
> > >>D-04009 Leipzig
> > >>_______________________________________________
> > >>OpenWalnut-Dev mailing list
> > >>OpenWalnut-Dev at lists.informatik.uni-leipzig.de
> > >>http://lists.informatik.uni-leipzig.de/mailman/listinfo/openwalnut-dev
> > >>
> > 
> 
> > _______________________________________________
> > OpenWalnut-Dev mailing list
> > OpenWalnut-Dev at lists.informatik.uni-leipzig.de
> > http://lists.informatik.uni-leipzig.de/mailman/listinfo/openwalnut-dev
> 
> 
> -- 
> Dipl.-Inf. Sebastian Eichelbaum
> Universität Leipzig
> Institut für Informatik
> Abteilung Bild- und Signalverarbeitung
> PF 100920
> D-04009 Leipzig
> _______________________________________________
> OpenWalnut-Dev mailing list
> OpenWalnut-Dev at lists.informatik.uni-leipzig.de
> http://lists.informatik.uni-leipzig.de/mailman/listinfo/openwalnut-dev
> 

-- 
Dipl.-Inf. Sebastian Eichelbaum
Universität Leipzig
Institut für Informatik
Abteilung Bild- und Signalverarbeitung
PF 100920
D-04009 Leipzig