Re: [Flightgear-devel] Flightgear building thread.
Hi Mathias, On Saturday 26 May 2007 19:52:17 Mathias Fröhlich wrote: > Well, not that I do not care for older hardware. But I think that we should > better rely on double here. It eases life very much and reduces complexity > in the code ... Remember this is OSG build - not FG. OK. But what restriction implies that a 'user' has to build OSG with float matrix or double matrix then? Surely any implementation of a product that uses OSG will want it's own way to do it? What happens if another application works better with OSG build with float matrix? BTW, I am not debating/arguing here, you coders are the key - I know naff all about the way FG/OSG integration works - I am only relaying my observations when using FG. Nick - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
Hi Curt, On Saturday 26 May 2007, Curtis Olson wrote: > If this works as well as advertised (and it appears to) then this is a > really nice feature of OSG. Dealing with whole earth scales using floating > point numbers requires a few non-obvious tricks. For those not familiar > with the issue, a floating point number can represent about 7(-8?) > significant digits. The est-epsilon program in the tests directory of the > FlightGear source estimates the smallest floating point number that can be > represented. > > In practical terms, this means you run out of floating point precision > trying to accurately place yourself or objects on the surface of the world. > You could easily a several meter shift in the position of objects (or the > view point) depending on whether or not the results of your placement math > gets rounded up or rounded down. > > You can just use doubles because *everything* that opengl does uses > floating point math. > > This leads to scenery that will jitter back and forth by this amount as you > move. It's a huge problem for flight simulators, unless you are studying > alchohol effects on pilots or something. :-) > > OSG appears to have come up with a nice workaround/solution to the problem. > Cool ... Yes, this works in that way. You can already see that in fg HEAD. Robert's library is heavily used in the Viz-Sim industry and thus exactly written for our needs :) Greetings Mathias - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
On 5/26/07, Tim Moore wrote: You might not realize that OSG doesn't push / pop the matrix in each transform node to OpenGL. Instead, it accumulates the effective ModelView matrix for each drawable and and loads that when the drawable is rendered. This allows you to keep the coordinates of geometry as small values that comfortably fit in floats, relative to a transform that can have a very large (wgs84) translation. If the eyepoint is in wgs84 too, then the effective translation calculated by OSG won't be very large -- it's effectively limited by the visual range -- and will also fit nicely in a float. As Mathias says, this is much more convenient than a scheme where you translate all the tiles each frame relative to an eyepoint at 0. I doubt you can measure any difference between glLoadMatrixf and glLoadMatrixd. If this works as well as advertised (and it appears to) then this is a really nice feature of OSG. Dealing with whole earth scales using floating point numbers requires a few non-obvious tricks. For those not familiar with the issue, a floating point number can represent about 7(-8?) significant digits. The est-epsilon program in the tests directory of the FlightGear source estimates the smallest floating point number that can be represented. In practical terms, this means you run out of floating point precision trying to accurately place yourself or objects on the surface of the world. You could easily a several meter shift in the position of objects (or the view point) depending on whether or not the results of your placement math gets rounded up or rounded down. You can just use doubles because *everything* that opengl does uses floating point math. This leads to scenery that will jitter back and forth by this amount as you move. It's a huge problem for flight simulators, unless you are studying alchohol effects on pilots or something. :-) OSG appears to have come up with a nice workaround/solution to the problem. Cool ... Curt. -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mathias Fröhlich wrote: > Hi, > > On Saturday 26 May 2007, Harald JOHNSEN wrote: >> Are we talking about the matrices used for the culling and the rendering >> ? If that's the case then we don't need precision for culling and the >> gpu does nothing with doubles, they have allready some trouble to use >> floats efficiently. > These are also the matrices that control the transform from and back to the > view. > You will get jitter if these are floats. > Remember the jittering aircraft models in earlier days ... > The workaround was a complex logic to carry that scenery center with you. > Having doubles in the transform matrices is a much simpler and cleaner > solution - without scenery center ... > > What double precision problems do you have? Harald, You might not realize that OSG doesn't push / pop the matrix in each transform node to OpenGL. Instead, it accumulates the effective ModelView matrix for each drawable and and loads that when the drawable is rendered. This allows you to keep the coordinates of geometry as small values that comfortably fit in floats, relative to a transform that can have a very large (wgs84) translation. If the eyepoint is in wgs84 too, then the effective translation calculated by OSG won't be very large -- it's effectively limited by the visual range -- and will also fit nicely in a float. As Mathias says, this is much more convenient than a scheme where you translate all the tiles each frame relative to an eyepoint at 0. I doubt you can measure any difference between glLoadMatrixf and glLoadMatrixd. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGWF4PeDhWHdXrDRURAnq1AKC2f7Cy70xwAwFeMFgha3PDO+NpuQCeKc7v IMwzirJnZR9C2rmxWvp7/Xs= =dW9G -END PGP SIGNATURE- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
On Saturday 26 May 2007 14:34:44 Mathias Fröhlich wrote: > hi, > > On Saturday 26 May 2007, Nick Warne wrote: > > I hope not ;-) ... > > What compiler do you use? > What distro? gcc version 3.4.6 Slack 10 (but heavily updated from source all bar glibc [too scared to update that]). > > > I understand/stood what these options did, and hence why I tried it. I > > do not see any difference at all, other than a 100% 'responsiveness' to > > FG and super FPS. > > > > It what respect does applying a float matrix rather than a double matrix > > do? I cannot see any visible difference - in fact I do, in that it is > > 'cleaner'. > > ??? OK, what I mean by 'cleaner' is more responsive, less 'stutters', and just generally faster all round. I do not see any issues graphically - in fact, cloud layer etc. is better as it all works faster. But, having said all this, I am on a 6 year old Athlon1.2GHz via aBit MoBo - so perhaps to a newer, modern machine this all doesn't matter as it is all rendered faster anyway. Nick - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
Hi, On Saturday 26 May 2007, Harald JOHNSEN wrote: > Are we talking about the matrices used for the culling and the rendering > ? If that's the case then we don't need precision for culling and the > gpu does nothing with doubles, they have allready some trouble to use > floats efficiently. These are also the matrices that control the transform from and back to the view. You will get jitter if these are floats. Remember the jittering aircraft models in earlier days ... The workaround was a complex logic to carry that scenery center with you. Having doubles in the transform matrices is a much simpler and cleaner solution - without scenery center ... What double precision problems do you have? Greetings Mathias - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
Mathias Fröhlich wrote: >Hi, > >Hi, > >On Saturday 26 May 2007, Nick Warne wrote: > > >>I decided to start a new clean thread here, so people can find what they >>need to build FG to perform. >> >>As we know, using the CMAKE command: >> >>cmake -i . >> >>produces a question/answer type script so you can build as a 'Release' and >>configure any optimisations to suit. >> >>Using: >> >>./configure CXXFLAGS= -O3 ... >> >>will build Simgear/FG with similar optimisations. >> >> >>Today I tested again OSG, and there are two options that made me wonder - >>so I turned ON to use a float matrix rather than double: >> >>//Set to ON to build OpenSceneGraph with float matrix instead of >>// double. >>OSG_USE_FLOAT_MATRIX:BOOL=ON >> >>//Set to ON to build OpenSceneGraph with float matrix instead of >>// double. >>OSG_USE_FLOAT_PLANE:BOOL=ON >> >> >That is bad idea. >That clamps the available precision of the transform matrices to floats which >is no longer enough. > >Are you on win32? > >Greetings > > Mathias > > > Are we talking about the matrices used for the culling and the rendering ? If that's the case then we don't need precision for culling and the gpu does nothing with doubles, they have allready some trouble to use floats efficiently. Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
hi, On Saturday 26 May 2007, Nick Warne wrote: > I hope not ;-) ... What compiler do you use? What distro? > I understand/stood what these options did, and hence why I tried it. I do > not see any difference at all, other than a 100% 'responsiveness' to FG and > super FPS. > > It what respect does applying a float matrix rather than a double matrix > do? I cannot see any visible difference - in fact I do, in that it is > 'cleaner'. ??? Greetings Mathias - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
Hi Mathias, On Saturday 26 May 2007 14:18:14 Mathias Fröhlich wrote: > > //Set to ON to build OpenSceneGraph with float matrix instead of > > // double. > > OSG_USE_FLOAT_MATRIX:BOOL=ON > > > > //Set to ON to build OpenSceneGraph with float matrix instead of > > // double. > > OSG_USE_FLOAT_PLANE:BOOL=ON > > That is bad idea. > That clamps the available precision of the transform matrices to floats > which is no longer enough. > > Are you on win32? I hope not ;-) ... I understand/stood what these options did, and hence why I tried it. I do not see any difference at all, other than a 100% 'responsiveness' to FG and super FPS. It what respect does applying a float matrix rather than a double matrix do? I cannot see any visible difference - in fact I do, in that it is 'cleaner'. Nick - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear building thread.
Hi, Hi, On Saturday 26 May 2007, Nick Warne wrote: > I decided to start a new clean thread here, so people can find what they > need to build FG to perform. > > As we know, using the CMAKE command: > > cmake -i . > > produces a question/answer type script so you can build as a 'Release' and > configure any optimisations to suit. > > Using: > > ./configure CXXFLAGS= -O3 ... > > will build Simgear/FG with similar optimisations. > > > Today I tested again OSG, and there are two options that made me wonder - > so I turned ON to use a float matrix rather than double: > > //Set to ON to build OpenSceneGraph with float matrix instead of > // double. > OSG_USE_FLOAT_MATRIX:BOOL=ON > > //Set to ON to build OpenSceneGraph with float matrix instead of > // double. > OSG_USE_FLOAT_PLANE:BOOL=ON That is bad idea. That clamps the available precision of the transform matrices to floats which is no longer enough. Are you on win32? Greetings Mathias - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Flightgear building thread.
Hi All, I decided to start a new clean thread here, so people can find what they need to build FG to perform. As we know, using the CMAKE command: cmake -i . produces a question/answer type script so you can build as a 'Release' and configure any optimisations to suit. Using: ./configure CXXFLAGS= -O3 ... will build Simgear/FG with similar optimisations. Today I tested again OSG, and there are two options that made me wonder - so I turned ON to use a float matrix rather than double: //Set to ON to build OpenSceneGraph with float matrix instead of // double. OSG_USE_FLOAT_MATRIX:BOOL=ON //Set to ON to build OpenSceneGraph with float matrix instead of // double. OSG_USE_FLOAT_PLANE:BOOL=ON Oh my!!! Again a huge increase in performance on my lowly 1.2GHz machine. For the first time ever I saw 60fps+ today... three weeks ago I was lucky to see > 35fps. This gets better and better... Nick - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
