Gerrit Voss wrote:

>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). 
>
Yes, there is some cruft in there related to OOBox.  I added it for a 
project I did one time and never got back to it.

>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. 
>  
>
It looks to me like it will return a float.  The definition is:

template<class DATA_TYPE, unsigned SIZE>
DATA_TYPE length(const Vec<DATA_TYPE, SIZE>& v1)

Which should force the return type to be the same as the data type.  
This has a problem in the case of a vector of ints though where there 
will be truncation on the returned type.  It would be easy enough to 
provide an overload that allowed you to specify the type you wanted 
returned though.

>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.
>  
>
I was thinking about this yesterday as well, and I think it would be 
possible.  All the template overloads "should" still work but I would 
need to test it.

>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. 
>
Comparing this to deriving from gmtl types, wouldn't this just introduce 
code duplication?

>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.
>  
>
I actually don't know why we haven't done this already.  I guess we 
didn't think about it at the beginning but I think it should be possible 
to introduce some meta information in each class that describes it's 
size.  The only problem may be in making the template specializations 
where sizes must match.  If we can do it though I think it could help out.

>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 ;-)
>  
>
This is one of those places where cute template programming can really 
pay off.  The way I look at it is that GMTL provides an interface to the 
user for doing graphics math.  As long as the implementation code 
respects that interface then it doesn't matter how we implement it (ie. 
how much template magic we use to increase performance).   In the case 
of expression templates and loop unrolling this can make a HUGE 
difference and cuts down on the amount of hand written code that is needed.

>
>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. 
>
I would love to see this type of thing introduced.  We do quite a bit of 
partial specialization right now, but none of it is to short-circut on a 
given platform.  I think that would be very helpful though.  For example 
one thing that may be very useful is to have vec op specializations for 
platforms with SSE support so we use the instructions directly.  I have 
seen some game libraries do things like this and I think it could be 
useful to us as well.

>So there might be some (partial) specializations needed in
>order to make it work. Which hopefully survive the MS compilers ;-)
>  
>
MS compilers are wonderful aren't they. :)

-Allen

>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
>
>  
>


-------------------------------------------------------------------------
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

Reply via email to