Hi,
On Wed, 2006-09-06 at 09:15 -0500, Dirk Reiners wrote:
> Hi Dan,
>
> On Wed, 2006-09-06 at 08:55 -0500, Daniel E. Shipton wrote:
> > There are are 2 parts that I would like to go after.
> >
> > The first is extending OpenSG's math classes to add functionality from
> > the math library(GMTL) that is missing(which may be on purpose).
> > This includes overloaded operators and convience functions for
> > making/extracting rotations and translations. See:
> > http://ggt.sourceforge.net/html/gmtlfaq.html
> >
> > The second part would be to see if the template meta-programming that
> > is already done for GMTL could be applied to OpenSG's math classes.
>
> Some of those were on purpose, to prevent people from doing inefficient
> things. Over the years we've added someof them, as people didn't care,
> and computers got fast enough for it not to matter. Moving to GMTL's
> template-oriented system would probably eliminate any speed reductions
> anyway.
In general it might be time to take a second look at our basic math
implementation. This is one of the last areas of our early copy&merge
approach to get things going. So there are things in there which are
of no use to OpenSG. For example the interface/storage split. This make
sense in the context of sparse matrices or if both row and column vector
access is needed for matrices but not so much for the typically dense
4x4 or 3x3 matrices OpenSG uses.
>From my short look at gmtl, one short note there seem to be a mix of old
and new stuff some of which does not work anymore (OOBox.h). Another
small item is the scalar value handling. length(Vec<uint, 3>); will
return an uint not a float which might be needed to capture the accurate
values.
The major differences I see is where the functions are defined. OpenSG
puts them inside the {Vec|Pnt}Interface whereas gmtl has them outside.
Personally I would tend towards Allen's 'use gmtl for OpenSG' solution
and probably work around the differences by deriving from the gmtl
classes and add the interfaces needed to keep it compatible. Where the
interfaces would call the appropriate gmtl functions.
Another option along this line would be to bring the math classes of
OpenSG closer to gmtl so we are able to use the gmtl functions on
OpenSG structures without directly deriving from them. They are not
that far apart anyway. As part of this one might have to generalize
gmtl functions little bit so they take the structure (e.g Vec) as an
argument and not only data type and size as it is right now. I wouldn't
go as far as introducing traits to map the differences in for example
vector classes but expect whatever vector class is used supports the
concepts needed.
On the risk of being beaten, of course I would love to have some cute
little template recursions and other magic back now that I removed them
from the Field code ;-)
Having said all of this there is one item where we have to put in some
thought. Manually unrolling things is not necessarily the best thing
to do on every platform. On fixed point hardware it is better to call
provided math function for vector/matrix operations as early as
possible. So there might be some (partial) specializations needed in
order to make it work. Which hopefully survive the MS compilers ;-)
regards,
gerrit
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Opensg-core mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensg-core
