Hi Tyge, I haven't implemented the Vec classes as templates previously as I haven't wanted to slow compilation and risk bloating executable size. Sometimes templates might seem like a "better" way of doing things, but you have to be careful as often then don't provide sufficient value to justify their costs.
Robert. On 8 May 2015 at 12:20, Tyge Løvset <[email protected]> wrote: > Hi, > > I have been playing with the osg::Vec classes, and also read a 2 year old > thread about this here > on the forum (not allowed to link to it because I don't have 2 posts already). > > I too find the current implementation rather inconsistent and limited so I've > made > a concise c++03 implementation that I hope will be aproved. It should be much > easier > to maintain as it is much less code, and each function is defined only once > (has no > overloaded "similar" functions either). I suppose Matrix{f,d} and other > classes > should be updated later to use the new template classes Vec2t<T>, Vec3t<T>, > Vec4t<T>. > > FULLY HARMONISED WITH TEMPLATES. > All Vec types have equal interface and can fully intermix in expressions. > Most arguments > are templated, so no unneccesary conversions or temporaries are made, which > should speed up code. > Also Vec4{*}::asRGBA() works for any type. > > SMART RETURN TYPES > Expressions returns the "natural" Vec type, e.g. Vec3i ^ Vec3d => Vec3d, > whereas Vec3s ^ Vec3i => Vec3i, > although the Vec3 ^ function is defined only once! Automatic conversion to > other Vec classes is > enabled by default in order to compile the current OSG source, but I highly > recommend that this > feature is turned off by default in the future (#define > OSG_NO_VEC_AUTO_CONVERSION) and force > explicit conversions. > > NOTE: Expressions involving integer types only (char, short, int and unsigned > types) always return > int for implementation simplicity. E.g.: -Vec3us() => Vec3i, Vec3ub + Vec3s > => Vec3i. > > EXTENSIONS > I have not added excessive new functionality, but did add a few: > * Explicit constructors that also accept number array (e.g float[]). > * Partial set() functions, which set some of the components, e.g.: > > Code: > osg::Vec4 color1, color2; > color2.set<0,1,2>( color1.rgb() ); > > > * normalized() const. returns unity vector. > * equivalent(u,v) implemented for Vecs. > NOTE: In partial set<>() above, the indices 0,1,2 are actually compile-time > checked to be < 4 > and unequal to each other! The rgb() function returns a Vec3, which brings us > to the next point. > > SWIZZLE FUNCTIONS > From a set of macros, a complete set of very convenient swizzle functions are > generated, > e.g. v.wyxx(), v.xy(), v.bgr(), etc. This could potentially slow down > compilation or create bigger > executables. However, I have not seen any of those effects with neither VC > nor GCC. > > FILES AND IMPLEMENTATION > The implementation is done in files Vec2, Vec3, Vec4 and VecFwd. The > remaining osg/Vec{*} > files are needed for backward compability only, and osg/Export, osg/Config > and osg/Math > are included only so the test can be compiled standalone. > > NB: Code which predeclares class Vec2i; class Vec3f, etc. must #include < > osg/VecFwd > instead. > > Thank you! > > Cheers, > Tyge > > ps: I have contributed a few lines of code earlier. > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=63672#63672 > > > > > Attachments: > http://forum.openscenegraph.org//files/osg_vec_850.zip > > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
