Re: [osg-users] 3DLabs ShaderGen
I have a copy I've put it here for you temporarily: http://www.starstonesoftware.com/files/ShaderGen-3.0.exe Richard On Apr 1, 2008, at 2:31 PM, Jean-Sébastien Guay wrote: Hi all, I was looking for the ShaderGen program which 3DLabs made a while ago. I'm looking to make some shaders to emulate the fixed pipeline and would be interested in seeing this program. However, it doesn't seem to be available on 3DLabs' website anymore. http://www.3dlabs.com/downloads/shadergen/index.htm http://developer.3dlabs.com/downloads/shadergen/ Both are dead. I was wondering if anyone would have a copy somewhere (mew maybe? :-) ). Or if someone knows of some other program that does the same thing, I'd be interested. I know about RenderMonkey et al, but that's not what I'm after. I'm more curious than anything else. Thanks in advance, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Terrain (.osga) optimization tips
lots of in depth best practice advice? I didn't realize it was that complicated a question, I'm sorry. If someone asked for some general performance tips for using OpenGL, I could probably spout off about 10 or so cold. I didn't realize OSG was so complicated that you needed a training class. I just wanted to know if the way I was loading the terrain was typical or not, and if not how other people are doing it. My 'clue' that my approach was perhaps naive was that I thought the performance could be better, and I might have overlooked something obvious. I apologize if my first message was unclear, I'm not trying to focus on the performance per-se, I realize no one can do performance tuning via e-mail. This is how everyone load's terrain in OSG. The lower rez terrains render quite fast, and for higher rez terrains is might be slow on some systems. Specific performance tuning is something of a black art. I did not miss anything obvious, that's just the way it is. I can accept that as an answer. Richard On Jan 25, 2008, at 10:22 AM, Robert Osfield wrote: Hi Richard, I'm afraid you're best to go to a training course if want lots of in depth best practice advice. As for why things are going slow, well the high draw time is great place to start, sounds very much likely a driver the OpenGL badly optimized for the type of data the OSG is throwing at it. If you have another machine/OS available try the same data there. Robert. On Jan 25, 2008 2:20 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: Robert, I didn't give all those details because I'm looking for more of a best practices type of advice. Just loading the terrain just works, but is this the typical usage scenario for most users? What are some of the common ways to speed up a terrain database created with osgdem in this way? When I created the database with osgdem, I made it to level 10. My specific case is just terrain and imagery. It's made from a ten meter DEM of the island of Oahu. The osga file is just shy of a gig. I'm not-impressed with performance because from looking at what is on screen, I've seen way better performance from my hardware (MacBook Pro w/ATI x1600 a Mac Pro w/ATI 2400). The window is small and not fill limited. Basically, I'm not looking for a detailed analysis of my particular situation, but wanted to know if there is something obvious that everyone else knows about for loading these types of files that I had missed. Bringing it into the Cocoa viewer, I get 1.03fps from an elevated view looking down on the Island. Timeing stats are: Event: 0.02 Update: 0.04 Cull: 0.41 Draw: 932.81 So... doing the math, looks like rendering is taking a pretty long time ;-) I'm thinking there is some utility node or flag that most people turn on that I have overlooked. Richard On Jan 25, 2008, at 4:56 AM, Robert Osfield wrote: Hi Richard, Way too little information to be able to know what is up with performance, so lets start with a few questions to get the information needed to guide you in the right direction: What platform are you working on? What hardware? Did you compile a release build? What performance did you get? What is the update, cull, draw, GPU stats like? How big is the database? Is it terrain, imagery, terrain+imagery? Other cultral data in there??? Robert. On Jan 25, 2008 3:54 AM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm loading a terrain set created with osgdem (.osga) via something like this: pTerrain = osgDB::readNodeFile(oahu-10.osga); Easy as pie. However, for a really dense terrain, the performance is a bit lack-luster. I wonder if everybody knows a trick that I haven't discovered yet for speeding this up a bit. Some standard optimization node configuration or setting that a newbie might have missed that can make a big difference. Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Terrain (.osga) optimization tips
Robert, I didn't give all those details because I'm looking for more of a best practices type of advice. Just loading the terrain just works, but is this the typical usage scenario for most users? What are some of the common ways to speed up a terrain database created with osgdem in this way? When I created the database with osgdem, I made it to level 10. My specific case is just terrain and imagery. It's made from a ten meter DEM of the island of Oahu. The osga file is just shy of a gig. I'm not-impressed with performance because from looking at what is on screen, I've seen way better performance from my hardware (MacBook Pro w/ATI x1600 a Mac Pro w/ATI 2400). The window is small and not fill limited. Basically, I'm not looking for a detailed analysis of my particular situation, but wanted to know if there is something obvious that everyone else knows about for loading these types of files that I had missed. Bringing it into the Cocoa viewer, I get 1.03fps from an elevated view looking down on the Island. Timeing stats are: Event: 0.02 Update: 0.04 Cull: 0.41 Draw: 932.81 So... doing the math, looks like rendering is taking a pretty long time ;-) I'm thinking there is some utility node or flag that most people turn on that I have overlooked. Richard On Jan 25, 2008, at 4:56 AM, Robert Osfield wrote: Hi Richard, Way too little information to be able to know what is up with performance, so lets start with a few questions to get the information needed to guide you in the right direction: What platform are you working on? What hardware? Did you compile a release build? What performance did you get? What is the update, cull, draw, GPU stats like? How big is the database? Is it terrain, imagery, terrain+imagery? Other cultral data in there??? Robert. On Jan 25, 2008 3:54 AM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm loading a terrain set created with osgdem (.osga) via something like this: pTerrain = osgDB::readNodeFile(oahu-10.osga); Easy as pie. However, for a really dense terrain, the performance is a bit lack-luster. I wonder if everybody knows a trick that I haven't discovered yet for speeding this up a bit. Some standard optimization node configuration or setting that a newbie might have missed that can make a big difference. Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Terrain (.osga) optimization tips
Ok, before we get anymore bad blood here let me just say I did not frame my original question properly, which has lead to a misunderstanding and elevated blood pressures. I basically got my answer (and then some), but I did not mean to cause a goading war. Richard On Jan 25, 2008, at 4:38 PM, Robert Osfield wrote: Hi Richard, You shouldn't have to do any performance tuning with VPB dataset, they are supposed to built well balanced in the first place. If there is a problem then its not a general problem but something very specific about your system and the way you've set things up - from the little stats its clearly a hardware/driver issue particular to your system OS. Its utterly pointless talking about giving you a full lesson in the general topic of paging when there is something really specific wrong with your setup, something I'm completely not partial to. I am human not omnipotent. As for complexity, hell yes, real-time computer graphics is hard, multi-threading is hard, the OSG strives to make it easy, but in the end its a big big hard topic. Its takes years to master, and yes taking courses really does help, you shouldn't expect others to teach you everything you need to know. If I ask a question of what's happening at your its because it needs there is NO way I can answer you question without more information. If I have to ask extra questions its because you have failed to provide the info in the first place, I don't ask questions for the fun of it and a way of avoiding answering a question, I try to get the point as quickly as possible to avoid wasting mine and your time. Perhaps I should just totally ignore posts that don't provide enough info to answer sensible? Why should I waste my time if people don't care to invest their own time in asking sensible questions. Robert. On Jan 25, 2008 9:23 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: lots of in depth best practice advice? I didn't realize it was that complicated a question, I'm sorry. If someone asked for some general performance tips for using OpenGL, I could probably spout off about 10 or so cold. I didn't realize OSG was so complicated that you needed a training class. I just wanted to know if the way I was loading the terrain was typical or not, and if not how other people are doing it. My 'clue' that my approach was perhaps naive was that I thought the performance could be better, and I might have overlooked something obvious. I apologize if my first message was unclear, I'm not trying to focus on the performance per-se, I realize no one can do performance tuning via e-mail. This is how everyone load's terrain in OSG. The lower rez terrains render quite fast, and for higher rez terrains is might be slow on some systems. Specific performance tuning is something of a black art. I did not miss anything obvious, that's just the way it is. I can accept that as an answer. Richard On Jan 25, 2008, at 10:22 AM, Robert Osfield wrote: Hi Richard, I'm afraid you're best to go to a training course if want lots of in depth best practice advice. As for why things are going slow, well the high draw time is great place to start, sounds very much likely a driver the OpenGL badly optimized for the type of data the OSG is throwing at it. If you have another machine/OS available try the same data there. Robert. On Jan 25, 2008 2:20 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: Robert, I didn't give all those details because I'm looking for more of a best practices type of advice. Just loading the terrain just works, but is this the typical usage scenario for most users? What are some of the common ways to speed up a terrain database created with osgdem in this way? When I created the database with osgdem, I made it to level 10. My specific case is just terrain and imagery. It's made from a ten meter DEM of the island of Oahu. The osga file is just shy of a gig. I'm not-impressed with performance because from looking at what is on screen, I've seen way better performance from my hardware (MacBook Pro w/ATI x1600 a Mac Pro w/ATI 2400). The window is small and not fill limited. Basically, I'm not looking for a detailed analysis of my particular situation, but wanted to know if there is something obvious that everyone else knows about for loading these types of files that I had missed. Bringing it into the Cocoa viewer, I get 1.03fps from an elevated view looking down on the Island. Timeing stats are: Event: 0.02 Update: 0.04 Cull: 0.41 Draw: 932.81 So... doing the math, looks like rendering is taking a pretty long time ;-) I'm thinking there is some utility node or flag that most people turn on that I have overlooked. Richard On Jan 25, 2008, at 4:56 AM, Robert Osfield wrote: Hi Richard, Way too little information to be able to know what is up with performance, so lets start with a few
[osg-users] Terrain (.osga) optimization tips
I'm loading a terrain set created with osgdem (.osga) via something like this: pTerrain = osgDB::readNodeFile(oahu-10.osga); Easy as pie. However, for a really dense terrain, the performance is a bit lack-luster. I wonder if everybody knows a trick that I haven't discovered yet for speeding this up a bit. Some standard optimization node configuration or setting that a newbie might have missed that can make a big difference. Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] XCode-Framework-osg BrainFart
After merrily going along my way using OSG on my Mac laptop for a few months, I got a new MacPro and started setting everything up fresh. No matter how I install OSG (download prebuild frameworks, or make them myself), when I add them to an XCode project I get a linking error framework not found osg. All the OSG frameworks including OpenThreads give me this error when I add them to the project. No other frameworks do this, just the OSG frameworks. I'm building on Leopard. Yes, I know something is fu-barred, I never had this problem on my MacBook Pro and I have built OSG many times. This is some sort esoteric Xcode problem and/or tangentially related to how OSG is built. OSG apps build on my MacBook Pro run fine on the MacPro, so the frameworks really are there... Any Mac/OSG/XCoders run into this before? I'm using GLUT, and the XCode project included (I'm using OSG 2.2 from source) that builds OSG works, but I cannot find any compiler or linker settings in that project that when transported to the other do the trick. Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg in Visual C++ Express Edition 2008
I can state with full confidence that OpenGL is most certainly not emulated by DirectX on Windows Vista. There is a direct3D wrapper for OpenGL 1.4 only, and it is only enabled when certain games are detected by Microsoft. Both ATI and NVidia have real ICD OpenGL drivers for Windows Vista. You must however download and install these drivers after installing Vista. As for CMake on Windows... I have no standing ;-) For further reference on OpenGL on Vista, see this article: http://www.opengl.org/pipeline/article/vol003_7/ Richard On Dec 31, 2007, at 3:51 PM, Percy Camilo Triveño Aucahuasi wrote: Windows vista uses directx to emulate opengl calls, so the develop of any software related to osg on that plataform isn't the best idea, is much better to develop on *nix (basd, linux or even macOS), and if you have a good drivers (to linux or bsd for instance) then is more convenient. Greetings pd: By the way i think is a good idea to use windows xp , the .Net framework 3 works on XP and there isn't any emulation of opengl here. That is my case :P, i had to uninstall windows vista ... any way this is only a tip ;) Happy new year :P 2007/12/31, Wojciech Lewandowski [EMAIL PROTECTED]: I have not done it myself so I am not 100 % sure but from what I've heard CMAKE simply does not find your VS 2008 installation on standard predefined paths. Workaround is to run cmake from VS 2008 command prompt. This is what I've heard. If this does not help ask again in new year. My collegues who use 2008 with OSG will be back I am sure they will know the answer... Linking apllication built with VS 2008 against VS 2005 or VS 2003 libs is bad idea. There will be a conflict between OSG runtime and your program runtime libs (crashes and exceptions). So the only option is to get CMAKE work and rebuild whole OSG. Other option would be to go back to VS 2005 but I would rather wait few days ;-) Happy New Year, Wojtek - Original Message - From: Sashidhar Guntury To: OpenSceneGraph Users Sent: Monday, December 31, 2007 4:01 PM Subject: [osg-users] osg in Visual C++ Express Edition 2008 Hi I've been using osg in linux this far. Today I tried installing it in windows vista with VC++ express edition 2008. I also downloaded the latest cmake from their site and religiously followed the instructions given in the wiki, but when I tried to configure it, it says visual studio 8.0 was not found. Could anybody please tell me where am I going wrong? Since the building wasn't working, I downloaded the binaries and installed them. But now wierd things keep happening. A very simple code of just loading a model and displaying it doesn't seem to work. It gives an error like this -- Unhandled exception at 0x00a10017 in CameraControl.exe: 0xC005: Access violation writing location 0x004205b8. I tried both the debug as well the release build, but the same error is given. Please help me... :( thanks and happy new year to all the guys at osg :) bye Sashidhar ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg in Visual C++ Express Edition 2008
Performance-wise, developers can expect a decrease of around 10-15% on Windows as compared to Windows XP. Sometimes it's even worse ;-) XP drivers are basically highly evolved Windows NT drivers... the vendors have had a lot of years to tune them into oblivion... with Vista, they basically had to start over (at least this is what one NVidia engineer told me). Developers will also find a whole new set of driver bugs to contend with. Richard On Dec 31, 2007, at 4:24 PM, Percy Camilo Triveño Aucahuasi wrote: Nice info, thank you, i read the link and find this: Performance-wise, developers can expect a decrease of around 10-15% on Windows as compared to Windows XP. So i think the people to try to develop on vista have to follow a few tips of this interesting article. Greetings 2007/12/31, Richard S. Wright Jr. [EMAIL PROTECTED]: I can state with full confidence that OpenGL is most certainly not emulated by DirectX on Windows Vista. There is a direct3D wrapper for OpenGL 1.4 only, and it is only enabled when certain games are detected by Microsoft. Both ATI and NVidia have real ICD OpenGL drivers for Windows Vista. You must however download and install these drivers after installing Vista. As for CMake on Windows... I have no standing ;-) For further reference on OpenGL on Vista, see this article: http://www.opengl.org/pipeline/article/vol003_7/ Richard On Dec 31, 2007, at 3:51 PM, Percy Camilo Triveño Aucahuasi wrote: Windows vista uses directx to emulate opengl calls, so the develop of any software related to osg on that plataform isn't the best idea, is much better to develop on *nix (basd, linux or even macOS), and if you have a good drivers (to linux or bsd for instance) then is more convenient. Greetings pd: By the way i think is a good idea to use windows xp , the .Net framework 3 works on XP and there isn't any emulation of opengl here. That is my case :P, i had to uninstall windows vista ... any way this is only a tip ;) Happy new year :P 2007/12/31, Wojciech Lewandowski [EMAIL PROTECTED] : I have not done it myself so I am not 100 % sure but from what I've heard CMAKE simply does not find your VS 2008 installation on standard predefined paths. Workaround is to run cmake from VS 2008 command prompt. This is what I've heard. If this does not help ask again in new year. My collegues who use 2008 with OSG will be back I am sure they will know the answer... Linking apllication built with VS 2008 against VS 2005 or VS 2003 libs is bad idea. There will be a conflict between OSG runtime and your program runtime libs (crashes and exceptions). So the only option is to get CMAKE work and rebuild whole OSG. Other option would be to go back to VS 2005 but I would rather wait few days ;-) Happy New Year, Wojtek - Original Message - From: Sashidhar Guntury To: OpenSceneGraph Users Sent: Monday, December 31, 2007 4:01 PM Subject: [osg-users] osg in Visual C++ Express Edition 2008 Hi I've been using osg in linux this far. Today I tried installing it in windows vista with VC++ express edition 2008. I also downloaded the latest cmake from their site and religiously followed the instructions given in the wiki, but when I tried to configure it, it says visual studio 8.0 was not found. Could anybody please tell me where am I going wrong? Since the building wasn't working, I downloaded the binaries and installed them. But now wierd things keep happening. A very simple code of just loading a model and displaying it doesn't seem to work. It gives an error like this -- Unhandled exception at 0x00a10017 in CameraControl.exe: 0xC005: Access violation writing location 0x004205b8. I tried both the debug as well the release build, but the same error is given. Please help me... :( thanks and happy new year to all the guys at osg :) bye Sashidhar ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users
Re: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.3.1 dev release
Checked out the latest trunk on Leopard OSX10.5.1. Using XCode 3.0 (gcc 4.01) ./configure make Errors in src/osgUtil/Tessellator.cpp (lines 44,45,46, 47, 48) I fixed this by making a different typdef: typedef GLvoid (*CallBack)(); And replacing (GLU_TESS_CALLBACK) with (Callback) Same in src/osgPlugins/low/Tessellator (lines 49, 50, 51, 52). again in src/osgPlugins/dw/ReadWritterDW (lines 757, 758, 759, 769, 761) Finallly at 99% I get: ld: cycle in dylib re-exports with /usr/X11R6/lib/libGL.dylib collect2: ld returned 1 exit status make[2]: *** [lib/osgPlugins-2.3.0/osgdb_freetype.so] Error 1 make[1]: *** [src/osgPlugins/freetype/CMakeFiles/osgdb_freetype.dir/ all] Error 2 make: *** [all] Error 2 This is not so obvious to me how to fix myself. Richard On Dec 21, 2007, at 9:20 AM, Robert Osfield wrote: Hi All, I've just checked in a bevy of additions/bug fixes to the OSG, to wrap these all up I'm about to do a dev release. Could users do an svn update and build and let me know of any problems that arise, or successes. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.3.1 dev release
OK, thanks on the tesselator issue. I can see this could be a thorny problem to try and just fix in the source code. What about the other error: ld: cycle in dylib re-exports with /usr/X11R6/lib/libGL.dylib collect2: ld returned 1 exit status make[2]: *** [lib/osgPlugins-2.3.0/osgdb_freetype.so] Error 1 make[1]: *** [src/osgPlugins/freetype/CMakeFiles/osgdb_freetype.dir/ all] Error 2 make: *** [all] Error 2 What could be causing this? I'm sorry if this is obvious to everyone else... I'm still cutting my teeth on 'nix style building. Richard On Dec 21, 2007, at 10:40 AM, Robert Osfield wrote: Hi Richard, The Tesslleator error is a known problem that comes and goes under OSX using the CMake build. A work around is checked in the the CMake system to allow you to toggle on/off the type of parameters used in the tesselator calls. Run ccmake . and have a browse through the options. Robert. On Dec 21, 2007 3:21 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: Checked out the latest trunk on Leopard OSX10.5.1. Using XCode 3.0 (gcc 4.01) ./configure make Errors in src/osgUtil/Tessellator.cpp (lines 44,45,46, 47, 48) I fixed this by making a different typdef: typedef GLvoid (*CallBack)(); And replacing (GLU_TESS_CALLBACK) with (Callback) Same in src/osgPlugins/low/Tessellator (lines 49, 50, 51, 52). again in src/osgPlugins/dw/ReadWritterDW (lines 757, 758, 759, 769, 761) Finallly at 99% I get: ld: cycle in dylib re-exports with /usr/X11R6/lib/libGL.dylib collect2: ld returned 1 exit status make[2]: *** [lib/osgPlugins-2.3.0/osgdb_freetype.so] Error 1 make[1]: *** [src/osgPlugins/freetype/CMakeFiles/osgdb_freetype.dir/ all] Error 2 make: *** [all] Error 2 This is not so obvious to me how to fix myself. Richard On Dec 21, 2007, at 9:20 AM, Robert Osfield wrote: Hi All, I've just checked in a bevy of additions/bug fixes to the OSG, to wrap these all up I'm about to do a dev release. Could users do an svn update and build and let me know of any problems that arise, or successes. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.3.1 dev release
Thanks, that hit's the nail right on the head. For Mac OSX builds (Leopard) then, the following needs to be added to the command line: -dylib_file \ /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ libGL.dylib:\ /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ libGL.dylib Robert... shouldn't this go in the make system then? Richard On Dec 21, 2007, at 12:25 PM, Jean-Sébastien Guay wrote: Hello Richard, ld: cycle in dylib re-exports with /usr/X11R6/lib/libGL.dylib collect2: ld returned 1 exit status make[2]: *** [lib/osgPlugins-2.3.0/osgdb_freetype.so] Error 1 make[1]: *** [src/osgPlugins/freetype/CMakeFiles/ osgdb_freetype.dir/ all] Error 2 make: *** [all] Error 2 What could be causing this? I'm sorry if this is obvious to everyone else... I'm still cutting my teeth on 'nix style building. I remember reading about this on the MacOS X Platform Specifics pages on the OSG wiki. I don't have a Mac myself, mind you :-) The page in question is: http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/MacOSX10.5 See the section X11 Link problems: (or search for cycle on the page). Hope this helps, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: Reference Manual for v2.2 now available
I rather like the idea of community donated white papers, with two pro's editing and compiling them. It seems this would be quick, and bring together a wide range of experiences. I'd be happy to do the chapter OSG for Dummies... I'll throw in a bonus section on mailing list etiquette ;-) Richard A man who is silent appears wise... The fool who speaks removes all doubt. On Dec 19, 2007, at 10:46 AM, Paul Martz wrote: Thanks for the enjoyable discussion. Bob and I will meet in about 2 weeks and future documentation plans will be a topic of discussion. Some random thoughts follow. Free documentation... I charge for documentation I develop, just like I charge for software I develop. I don't think this is unreasonable. If you sincerely believe that OSG documentation should be free, contract with Bob and I and pay us to write it. Then it's yours, and you can give it away free, just like CGSD/Andes did with the Quick Start Guide. For those of you wishing there was more documentation available, rest assured Bob and I do not intend to stop where we are. However, know that OSG is large, and documenting all of it will take time. I think we've made good progress so far. Without contracts to develop documentation, Bob and I squeeze in documentation development around our (better paying) contractual software development obligations. This environment prohibits any large-scale dedicated documentation projects, and means that documentation will have to come out in small bits and pieces. The idea of writing separate whitepapers on various topics is quite appealing. I see two different approaches here: 1) Bob and I write them all, release them as they are completed, and after we reach some critical mass, we assemble them into the OSG Programming Guide and release that as a book. 2) Members of the OSG community all write articles on various aspects of OSG and submit them to Bob and I. We edit and assemble them and release the OSG Gems book. So I really see those as two different projects. Both seem doable, but the Gems book implicitly assumes community contribution, and past experience indicates the odds for this happening are quite small. (To be fair, having Bob and I write whitepapers implicitly assumes we'll have time to do it -- I think we will, but the papers might not appear as fast as we'd all like.) However, I like the idea of a community-written OSG Gems book, and I don't want to underestimate the community's willingness to contribute. So, I'll give this some thought, look into other Gems-style books' business models, and see if I can find a way to make this work (time-wise, as an editor). Initial thought: rather than here's how to use some feature in OSG type of articles, it might be better to have here's how I did this really cool thing using OSG or here's how my company is using OSG, if you know what I mean. I think this is more in line with other Gems books I've read. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DepthPartitionNode, was: Really Big Scenes and clipping
Paul, Thanks for the tip on the pseudoloaders! As it turned out, my assumption about the malfunctioning depth partition had nothing to do with the actual size of the model. It was correctly accounting for my matrix scale after all. Someone else on the list pointed to a minor tweak to some tolerance values that did the trick. Richard On Dec 19, 2007, at 1:47 PM, Paul Martz wrote: Hi Richard -- There doesn't appear (I have looked through the reference guide... of course that doesn't mean the info isn't there ;-) The Reference Manual is a start, and so far it documents only the three core libraries: osg, osgUtil, and osgDB. Plugins aren't covered. Plugin features are almost completely undocumented and very inconsistent between plugins. It'll be a bear to document. to be a way to scale the actual model data on load (which would be nice as I would not have to involve the artist again). One thing you should know about are the pseudoloaders. These are plugins that use another plugin under the hood to load the model, then parent the loaded scene graph to an additional decorator node to achieve some effect. For example, you can do the following: readNodeFile( foo.3ds.4,4,4.scale ); This invokes the scale pseudoloader. It parses the file name to determine what file to load and how to scale the loaded model. In this case, it uses the 3ds plugin under the hood to load the model, then parents it to a MatrixTransform containing a uniform scale transformation of 4 units in x, y, and z. Note that you could just as easily do this yourself by loading the 3ds file as usual without the pseudoloader, and then creating your own MatrixTransform to scale the model. In your case, you'd have to write code either way. Where the pseudoloaders really come in handy is as command line arguments to osgviewer. For example, compare these two commands: osgviewer cow.osg axes.osg osgviewer cow.osg.10,0,0.trans axes.osg Hope that helps. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: Reference Manual for v2.2 now available
Yikes... I'm already loosing sleep about all the work I have ahead because of OpenGL 3.0 ;-) Richard On Dec 19, 2007, at 2:39 PM, Paul Martz wrote: I'd be happy to do the chapter OSG for Dummies... We were counting on you for OSG SuperBible! :-) -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Robert, Yes, mastery of a new technology certainly is a long term investment ;-) Thanks for this explanation, it is a valuable insight. As I continue to grok more of the OSG philosophy, I'm sure more of this will become more intuitive to me. I have now found three different solutions to my original problem that all work, so I feel I have moved another rung or two up the ladder ;-) I will also look at the examples you recommended for further insights. Richard On Dec 18, 2007, at 4:16 AM, Robert Osfield wrote: Hi Richard, The OSG supports high level and low control over draw order via the StateSet::RenderBinDetails. Basically the rendering backend is constructed as a graph of what is called RenderStage(s) and RenderBin(s), the StateSet::RenderBinDetails tells the cull traversal how to build this graph, both the type of RenderBin to create/use and what order it should drawn in. Its a very powerful feature, but its is one of the more advanced and complex to understand ones so you'll need to be patient and steadily bite into rather than diving straight in the deep end and expect understand it all right away. To learn about making a subgraph draw first have a look at the osghangglide example - it has a skydome that it renders first, and you can switch off depth testing for it. The osgvertexprogram example also has a skybox that is view dependant. For general rendering order control have a browse through the osgreflect example. The osgprerender example also provides another example, this time using render to texture cameras. Robert. On Dec 17, 2007 11:22 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: Robert, Thanks, yes I have used the Fog approach before, it is especially effective for underwater scenes. However, I need to be able to see quite a ways distant (flight sim). If I was NOT using a scene graph, I would draw the sky dome as a unit sphere, and just rotate it by the camera transform, but not translate it (thus, appearing infinitely distant). I would draw it first, and not write to the depth buffer. Here's where the OSG newbie kicks in... doesn't the scene graph reorder the nodes at will (ok, I know it's not random, but you get my point)? Is there a way I have missed to say this node must always be drawn first? If so, I can easily manipulate the matrix of the sky dome to get the effect I want, and I bet I can turn off depth writing using the state mechanism. I have however, missed the draw me first flag ;-) Richard On Dec 17, 2007, at 11:19 AM, Robert Osfield wrote: Hi Richard, You could play multi-pass tricks like done in the osgdepthpartion example, or just manage the visible distance so that the furthest distance is never too far away. For instance a common trick is to use Fog to make far objects fade away until eventually nothing beyond a certain distance can be seen - so you simply cull it and this pull in the far plane. The skydome could also be computed dynamically to just fits the size of the scene required for that frame instead of the whole model. Robert. On Dec 17, 2007 1:17 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera- setComputeNearFarMode (osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary
Re: [osg-users] ANN: Reference Manual for v2.2 now available
Apparently I ran on and on and tried to be too clever and should have just stayed quiet. I did not intend to further the debate, but perhaps capture the nature of open source and community driven projects for those who can't understand why OSG isn't as easy to pick up as say Qt. This nature is not suitable for all developers, but it is still quite useful to many (myself included). Sometimes I enjoy playing devils advocate a little too much ;-) I do not think that OSG is worthless without documentation (to me). I also greatly appreciate the efforts of everyone on this list (including you if I'm not mistaken) to help the newbies, and create the tutorials and sample code for OSG. I do think the level of documentation is sufficient for my needs, but could always be better (I really got quite the head start via Paul's great book). Mailing lists such as these can be more valuable than many books. In fact in a previous posting weeks ago, I stated that I found OSG to be quite refreshing in that it has more tutorials and documentation than most other open source projects I have encountered. I haven't changed my mind. But I am an experienced developer who understands (and was trying to convey in a long winded way) that mastery of a new technology is a significant investment. I was simply (oh, no I suppose there was nothing simple about it) saying, this other gentleman has a valid point... but shouldn't whine about it. I think he probably expected the reference guide to be something like the MSDN reference, or Qt's Assistant. You can't go to Amazon and find several books on OSG, etc. Many people really need this level of support to pick up a new API. no one in the not enough docs camp steps up to change that. I have written one or two sample programs and tutorials in my time... when I graduate from newbie, I promise to contribute something back myself. So can we just agree to disagree? I'm not sure what we disagree on. I see both sides of the argument is all. I haven't been following the thread, and probably should not have just jumped in at the end. I think we can both agree that I haven't gotten enough sleep lately and have probably OD'd on caffeine. I promise to shut up for a while ;-) Richard On Dec 18, 2007, at 8:43 PM, Jean-Sébastien Guay wrote: Hello Richard, Warning... I'm in rare form tonight ;-) Yeah... Well... I don't really see your point in continuing this debate. No one willingly says Hey, you know what? We don't need documentation. You want to pay for it? Why bother!. I think this subject is on the top-5 (maybe even top-2) list of beating a dead horse subjects on this mailing list. On the one hand, you're saying the OSG is worthless without documentation. We all agree with the principle, but the fact of the matter is that a large number of people find what little documentation exists is sufficient to get started, and once you're rolling, everything comes easily. So either your argument is too white or black, or OSG is a counter-example to your argument. I suspect a little of both. See the documentation and tutorials sections on the wiki for great documentation that is not only free, but was also contributed freely by members of the community. See Paul Martz's books for great documentation in the more traditional sense. See the examples in the source code for short, to-the-point code samples. Of course, there can never be enough (and even less too much) documentation. But the debate in itself does not help, since we all have our take on the subject and no one in the not enough docs camp steps up to change that. So can we just agree to disagree? J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Really Big Scenes and clipping
I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera- setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Robert, Thanks, yes I have used the Fog approach before, it is especially effective for underwater scenes. However, I need to be able to see quite a ways distant (flight sim). If I was NOT using a scene graph, I would draw the sky dome as a unit sphere, and just rotate it by the camera transform, but not translate it (thus, appearing infinitely distant). I would draw it first, and not write to the depth buffer. Here's where the OSG newbie kicks in... doesn't the scene graph reorder the nodes at will (ok, I know it's not random, but you get my point)? Is there a way I have missed to say this node must always be drawn first? If so, I can easily manipulate the matrix of the sky dome to get the effect I want, and I bet I can turn off depth writing using the state mechanism. I have however, missed the draw me first flag ;-) Richard On Dec 17, 2007, at 11:19 AM, Robert Osfield wrote: Hi Richard, You could play multi-pass tricks like done in the osgdepthpartion example, or just manage the visible distance so that the furthest distance is never too far away. For instance a common trick is to use Fog to make far objects fade away until eventually nothing beyond a certain distance can be seen - so you simply cull it and this pull in the far plane. The skydome could also be computed dynamically to just fits the size of the scene required for that frame instead of the whole model. Robert. On Dec 17, 2007 1:17 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera- setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Being able to render something last... that could be useful. But I'm thinking I want to render the skydome _first_, using a painters algorithm and drawing everything else in front of it. It seems this would also be the best approach for a rendering a night time sky using point sprites for the stars, etc. Richard On Dec 17, 2007, at 6:41 PM, Thrall, Bryan wrote: Richard S. Wright Jr. wrote on Monday, December 17, 2007 5:22 PM: Robert, Thanks, yes I have used the Fog approach before, it is especially effective for underwater scenes. However, I need to be able to see quite a ways distant (flight sim). If I was NOT using a scene graph, I would draw the sky dome as a unit sphere, and just rotate it by the camera transform, but not translate it (thus, appearing infinitely distant). I would draw it first, and not write to the depth buffer. Here's where the OSG newbie kicks in... doesn't the scene graph reorder the nodes at will (ok, I know it's not random, but you get my point)? Is there a way I have missed to say this node must always be drawn first? If so, I can easily manipulate the matrix of the sky dome to get the effect I want, and I bet I can turn off depth writing using the state mechanism. I have however, missed the draw me first flag ;-) To have the skydome always rendered last, give it a StateSet and call setRenderBinMode(USE_RENDERBIN_DETAILS) and setRenderBinNumber(3). Most stuff uses RenderBin 0, (or 1 and 2 if there's transparent stuff), so this should force it to be last (you can certainly set a higher number if needed). Nested cameras and anywhere else you don't use the default StateSet RenderBinMode will complicate things, though (RenderBins can nest, and the numbers are relative order within the current RenderBin). HTH! On Dec 17, 2007, at 11:19 AM, Robert Osfield wrote: Hi Richard, You could play multi-pass tricks like done in the osgdepthpartion example, or just manage the visible distance so that the furthest distance is never too far away. For instance a common trick is to use Fog to make far objects fade away until eventually nothing beyond a certain distance can be seen - so you simply cull it and this pull in the far plane. The skydome could also be computed dynamically to just fits the size of the scene required for that frame instead of the whole model. Robert. On Dec 17, 2007 1:17 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera- setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Doh!! Thanks! Richard On Dec 17, 2007, at 8:46 PM, Jason Daly wrote: Richard S. Wright Jr. wrote: Being able to render something last... that could be useful. But I'm thinking I want to render the skydome _first_, using a painters algorithm and drawing everything else in front of it. It seems this would also be the best approach for a rendering a night time sky using point sprites for the stars, etc. Negative numbers also work for render bins. You can use -10, for example, to get it drawn first. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] stencil buffer
There is one little gottcha everyone should watch for on the stencil buffer. On Windows, ATI hardware/drivers, all pixelformats have stencil, rather you asked for it or not. This nabbed me once when I had working code on an ATI machine suddenly fail on NVidia machines... only to find it was because I had never requested a stencil buffer (it actually should not have worked at all ;-). Richard On Nov 27, 2007, at 11:58 AM, Robert Osfield wrote: On Nov 27, 2007 4:27 PM, Frédéric SPEISSER [EMAIL PROTECTED] wrote: You were right : Stencil buffer is disabled per default in Qt (strange !?) Its actually normal, stencil buffer aren't normally enabled by default by most windowing toolkits. osgViewer internal windowing support autodetects the need for stencil buffer but even this requires the scene data to be set before the windows are opened, otherwise it just defaults to assuming stencil buffer is not needed. So in constructor of the QGLWidget must be specified const QGLFormat format = QGLFormat(StencilBuffer) Note : Accumulation buffer and alpha channel are disabled per default too. Again pretty normal state of the play. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Christmas cash for Hawaii.osga anyone?
I'm somewhat new to OSG, and up until about a week ago, I was enjoying learning the API and coming up to speed relatively quickly. Now I'm learning more about GIS systems than I really have any long term need to know, and am spending way too much time trying to build a decent database using dozens of different tools, file formats, etc. On the Virtual Terrain site, I found a good source for Hawaii, 10 meter data, and a high resolution landsat image. Using osgdem and other tools, I should be able to splice together a 10 meter database of the main island of Hawaii for a flight simulator project. This is taking too much time and I would much rather go back to learning OSG ;-) I estimate that someone who knows what they are doing (and thus not a learning experience) can probably do this in a day, if they haven't already. I'm pretty much done with trial and error and am ready to do this this the old fashioned way. Pay someone else ;-) So, I have a flight sim project that I'm using to learn OSG. This is a single installation, not a big commercial project. Does someone on this list either: a. Have a ready to roll Hawaii database that I can use already made? b. Have a day to put this together for me? Yes, I am willing to pay a few bucks for your time or previous hard work. It seems this might be useful for a lot of other people as a learning or sample resource as well. I'm also willing to fund the project and just make it publicly available as a demo OSG terrain database. All of this of course assumes I'm not totally off my rocker and this isn't a month long project. I'm thinking this is trivial for someone who has been there, done that. Richard S. Wright Jr. Starstone Software Systems, Inc. Where Science Rocks http://www.starstonesoftware.com [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Christmas cash for Hawaii.osga anyone?
Um... just in case I wasn't clear. I am NOT looking for someone to build a flight simulator in a day ;-) I'm just wanting the terrain database Richard On Nov 28, 2007, at 12:20 AM, Richard S. Wright Jr. wrote: I'm somewhat new to OSG, and up until about a week ago, I was enjoying learning the API and coming up to speed relatively quickly. Now I'm learning more about GIS systems than I really have any long term need to know, and am spending way too much time trying to build a decent database using dozens of different tools, file formats, etc. On the Virtual Terrain site, I found a good source for Hawaii, 10 meter data, and a high resolution landsat image. Using osgdem and other tools, I should be able to splice together a 10 meter database of the main island of Hawaii for a flight simulator project. This is taking too much time and I would much rather go back to learning OSG ;-) I estimate that someone who knows what they are doing (and thus not a learning experience) can probably do this in a day, if they haven't already. I'm pretty much done with trial and error and am ready to do this this the old fashioned way. Pay someone else ;-) So, I have a flight sim project that I'm using to learn OSG. This is a single installation, not a big commercial project. Does someone on this list either: a. Have a ready to roll Hawaii database that I can use already made? b. Have a day to put this together for me? Yes, I am willing to pay a few bucks for your time or previous hard work. It seems this might be useful for a lot of other people as a learning or sample resource as well. I'm also willing to fund the project and just make it publicly available as a demo OSG terrain database. All of this of course assumes I'm not totally off my rocker and this isn't a month long project. I'm thinking this is trivial for someone who has been there, done that. Richard S. Wright Jr. Starstone Software Systems, Inc. Where Science Rocks http://www.starstonesoftware.com [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] I need more accuracy !
Stephane, I am fairly new to OSG, but I understand your problem quite well. I developed (and continue to maintain) a commercial solar system simulator. The scale runs from far flung trans-neptunian objects, to flying up and almost touching the ISS. Even without going to the stars, you simply cannot achieve this level of detail in a single coordinate system with OpenGL, regardless of your calculated precision. Instead of a brute force approach, you will need to partition your universe by scale. When flying between stars, you do not need the same frustum as when you are orbiting a planet. When visiting the space shuttle, you do not use the same frustum as when drawing the planet. Render the large scale universe first (but scale it down to smaller numbers). Then the intermediate, etc. I've done this myself manually... I would be interested in hearing how to achieve this with OSG from other members. I imagine you will need to create more than one scene graph and superimpose them. Richard On Nov 12, 2007, at 4:55 AM, Stephane Lamoliatte wrote: Dear mister Osfield, I currently develop a space simulator working with very hight dynamic range data. During the development I met multiple floatting point number precision problems. For now, I try to solve one of these that come from OpenSceneGraph : For my scene, I need to use Matrices, Vectors and Quaternions with a very big accuracy. (I detail an exemple of osg accuracy problem below). I wrote a Matrixr, a matrix of real, wich is a Matrix using the GMP library. The problem is that I can't simply replace all matrices in the code of OpenSceneGraph by my Matrixr. I try to change the typedef Matrixd Matrix by typedef Matrixr Matrix in osg/Matrix, but It does not work because some class don't use the Matrix but Matrixd or Matrixf. Another solution would be to develop new osg::Transform and osg::MatrixTransform using the real type and the Matrixr class. But I don't know how to make osg considers them as transform node without inherit them from the original osg::Transform node. By the way, I want to know if someone have already try to do this kind of thing, and/or if there is an accuracy node kit in development to help me. Best regard. Here is a detailed example of my problem : There is a star far far away from the center of the universe. For some reasons I MUST have this scene graph : [rootNode : osg::Group] - [starTransform : osg::MatrixTransform] - [starModel : osg::Geode] - ... The Matrix in the osg::MatrixTransform is a Matrixd that contains a very big translation vector, for example at (x=10^20, y=0, z=0) from the center of the universe. I want to move in the universe, close to this star at (x=10^5, y=0, z=0) from the star and then at (x=10^20 + 10^5, y=0, z=0) from the center of the universe. To compute the MODELVIEW matrix, osg implicitly compute (x=10^20 + 10^5, y=0, z=0) - (x=10^20, y=0, z=0) . But in fact, osg works like if the camera is in the center of the universe at (x=0, y=0, z=0). Why ? Because osg computes matrix transforms with float and double values. In double : 10^20 + 10^5 = 10^20. So I can't freely move in my universe using Matrixd and that's why I need more accuracy. -- Lamoliatte Stephane. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] I need more accuracy !
Thanks for the tip! I knew this couldn't be that unusual of a problem and that someone probably had thought of this with OSG. I forgot to mention depth buffer tricks in the previous post, but yeah, that can get messy too ;-) Richard On Nov 12, 2007, at 9:17 AM, Serge Lages wrote: On Nov 12, 2007 2:48 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: Stephane, I am fairly new to OSG, but I understand your problem quite well. I developed (and continue to maintain) a commercial solar system simulator. The scale runs from far flung trans-neptunian objects, to flying up and almost touching the ISS. Even without going to the stars, you simply cannot achieve this level of detail in a single coordinate system with OpenGL, regardless of your calculated precision. Instead of a brute force approach, you will need to partition your universe by scale. When flying between stars, you do not need the same frustum as when you are orbiting a planet. When visiting the space shuttle, you do not use the same frustum as when drawing the planet. Render the large scale universe first (but scale it down to smaller numbers). Then the intermediate, etc. I've done this myself manually... I would be interested in hearing how to achieve this with OSG from other members. I imagine you will need to create more than one scene graph and superimpose them. Richard Hi Richard, take a look at the DepthPartition example to have an idea on how doing this automatically. In our project we also have such problems to solve, but I've found that doing the partition manually depending on the object's scale, and using some tricks with the depth buffer is more reliable for us. -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] I need more accuracy !
Yes, that's me ;-) I took a look at OSG some years ago and just came back for a second look recently. It has come a long way, and I'm adopting it as part of my developer arsenal. I haven't traditionally be a huge fan of Open Source projects (no flames please ;-). OSG however seems to be the best documented and well supported project of it's kind (better than at least one commercial engine I've licensed in the past). There is a rich set of sample code, real (in my book, that just means support for OS X instead of just Linux ;-) multi- platform support, and plenty of reasonably well written Wiki entries and tutorials. For a total newbie, I've been able to boot strap myself pretty quickly. As for the Bible... yeah, I get a lot of that too. Way way back in the day, there was a whole series of Bibles from Waite Group press. They were regurgitated SDK documents... The Super Bibles were reference plus a tutorial. Of all the SuperBibles of 10-15 years ago, only mine remains, and is now in the Addison Wesley camp (for which I feel somewhat humbled). I have also encountered at least one individual who thought the book was about accounting! Paul Martz by-the-way from this list was one of my tech reviewer's last time around, and really did a lot to raise the quality of the fourth edition. I also had two excellent co-authors who contributed heavily to the New Testament section. Richard On Nov 12, 2007, at 9:37 AM, Jeremy L. Moles wrote: Aren't you the author of the OpenGL SuperBible? :) Welcome to OSG, woot. I bet a great deal of us own that book... Anyways, a funny story: A few years ago when I still lived at home my grandmother saw my copy of that book and got real suspicious. She's very religious and thought that OpenGL was some kind of cult I was in, since the title contained the word bible in it. :) Funny stuff... On Mon, 2007-11-12 at 08:48 -0500, Richard S. Wright Jr. wrote: Stephane, I am fairly new to OSG, but I understand your problem quite well. I developed (and continue to maintain) a commercial solar system simulator. The scale runs from far flung trans-neptunian objects, to flying up and almost touching the ISS. Even without going to the stars, you simply cannot achieve this level of detail in a single coordinate system with OpenGL, regardless of your calculated precision. Instead of a brute force approach, you will need to partition your universe by scale. When flying between stars, you do not need the same frustum as when you are orbiting a planet. When visiting the space shuttle, you do not use the same frustum as when drawing the planet. Render the large scale universe first (but scale it down to smaller numbers). Then the intermediate, etc. I've done this myself manually... I would be interested in hearing how to achieve this with OSG from other members. I imagine you will need to create more than one scene graph and superimpose them. Richard On Nov 12, 2007, at 4:55 AM, Stephane Lamoliatte wrote: Dear mister Osfield, I currently develop a space simulator working with very hight dynamic range data. During the development I met multiple floatting point number precision problems. For now, I try to solve one of these that come from OpenSceneGraph : For my scene, I need to use Matrices, Vectors and Quaternions with a very big accuracy. (I detail an exemple of osg accuracy problem below). I wrote a Matrixr, a matrix of real, wich is a Matrix using the GMP library. The problem is that I can't simply replace all matrices in the code of OpenSceneGraph by my Matrixr. I try to change the typedef Matrixd Matrix by typedef Matrixr Matrix in osg/Matrix, but It does not work because some class don't use the Matrix but Matrixd or Matrixf. Another solution would be to develop new osg::Transform and osg::MatrixTransform using the real type and the Matrixr class. But I don't know how to make osg considers them as transform node without inherit them from the original osg::Transform node. By the way, I want to know if someone have already try to do this kind of thing, and/or if there is an accuracy node kit in development to help me. Best regard. Here is a detailed example of my problem : There is a star far far away from the center of the universe. For some reasons I MUST have this scene graph : [rootNode : osg::Group] - [starTransform : osg::MatrixTransform] - [starModel : osg::Geode] - ... The Matrix in the osg::MatrixTransform is a Matrixd that contains a very big translation vector, for example at (x=10^20, y=0, z=0) from the center of the universe. I want to move in the universe, close to this star at (x=10^5, y=0, z=0) from the star and then at (x=10^20 + 10^5, y=0, z=0) from the center of the universe. To compute the MODELVIEW matrix, osg implicitly compute (x=10^20 + 10^5, y=0, z=0) - (x=10^20, y=0, z=0) . But in fact, osg works like if the camera
