Gerrit Voss wrote: > Hi, > > On Fri, 2007-07-27 at 09:53 -0500, Aron Bierbaum wrote: >> I am working on a project that requires higher precision than >> currently offered by OpenSG. After a discussion on the mailing list a >> few months ago we came to the conclusion that we should first try to >> modify the RenderTraversal to use double precision matrices. In order >> to do this I need to make it possible to multiply matrices with >> different types. For example we need to multiply the Matrix4d stored >> in the MatrixStore by the Matrix4f in the Transform node core. What >> are people's thoughts on this? Is this something that we should allow? >> It is proving to be difficult because I have to define a lot of member >> templates to make things work. For example: >> >> template<class ValueTypeR> >> void mult (const TransformationMatrix<ValueTypeR>& mat); >> >> template<class ValueTypeR> >> void multLeft (const TransformationMatrix<ValueTypeR>& mat); >> >> Am I going about this completely wrong? My thought was that as long as >> I am storing the MatrixStore as double precision and maybe add a >> double percision transform node core, I should be able to get the >> precision that I need. > > assuming OSG2 and IIRC the discussion, what was the reason not to use > the same mechanism we used for fixed point math and switch > Matrixr and the other r type to double. This should switch most of > the internal structures (transform matrices, volumes, camera parameter) > to double.
This was our first thought too, but there were some problems that we came up against and I think Dirk pointed out some problems as well. That said, when looking through the code we didn't really fully understand how the XXXr symbols were supposed to work and what they were meant to allow in the system. The path we started down yesterday was two pronged: - We extended the Matrix class to allow interoperability between Real32 and Real64 types. (multiplication, transforms, comparison, assignment, etc). - We changed the MatrixStore code to track all accumulated transformations matrices as double Matrices. This seems to be working well so far and did not require too many changes in code. If you (or anyone else) can think of a better way to do this, please let us know ASAP. If there is enough interest, I suggest we have a conference call on Monday or Tuesday to discuss the options and come to a consensus so we can get the code implemented in the next couple of days. -Allen > What it does not switch right now would be the RenderTrav action because > we used the old RenderAction but this is just renaming Matrix to Matrixr > and Vec3f to Vec3r so it should not involve any code changes, except > for gl calls which should be added to the GLProfile.h. > > I can run the RenderTrav action through the fixed point math system and > make the changes on Monday (need my office machine). > > kind regards, > gerrit > > > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Opensg-core mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-core > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
