Re: [osg-users] 64bit question
Hi Paul, On Jan 24, 2008 10:18 PM, Paul Pocock [EMAIL PROTECTED] wrote: I was wondering this myself - If I build with cmake in 64 bit linux, how do I know I'm getting 64 bit. Does Cmake do auto detecting of architectures and is this reliable ? It will default to 64bit if your OS is 64bit. On linux the CMake build will by default set the LIB_POSTFIX variable to 64, its not full proof a sign that you have 64 bit though, as this is a variable you can override. This is the only sign I've spotted so far for a 64 bit build though. Perhaps someone more expert in CMake will be able to show us more clearly. Potentially one could add a flag to CMake build just to show whether its 32 or 64bit build just for information purposes. Robert. ___ 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
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
Re: [osg-users] PagedLOD node page callback
Hi Paul, osg::observer_ptr is the only public example of osg::Observer in action that I can think of. Robert. On Jan 25, 2008 12:26 AM, Paul Pocock [EMAIL PROTECTED] wrote: Hi Robert, I was wondering how you would use osg::Observer and are there any examples. Would you construct it as osg::observer_ptrosg::Object pagedLODObserver ? and catch page unloads by testing for objectDeleted() ? On Thu, 2008-01-24 at 09:01 +, Robert Osfield wrote: Hi Michael, To monitor file loads you just need to assign a custom osdDB::Registry::ReadCallback to the Registry.. To catch unloads you have two routes, add an custom osg::Observer to PagedLOD objects to get informed when they get deleted or to create your own DatabasePager subclass. Robert. On Jan 23, 2008 10:47 PM, Guerrero, Michael (CIV) [EMAIL PROTECTED] wrote: Hi, I'm searching for a convenient way to be alerted when a PagedLOD node gets either paged in or out. Is there a preferred method of doing this? Thanks, Michael ___ 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 IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ 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] Re How to override plugins...
On Jan 25, 2008 10:00 AM, [EMAIL PROTECTED] wrote: Hi Robert, Thanks for that. I thought it would be easier to derive from existing zip reader, but evidently that wasn't the way to do it as I then ended up creating two zip reader instances as the proxy construction and the class definition for the base zip reader are in the cpp file. I've fixed my problem by simply deriving from ReaderWriter instead. This brings me to a more general question about readers. Is there a reason why some employ the .h .cpp conventions, whilst others roll them all into one - either .h or .cpp ? Thanks again for the info. It all depends upon on the needs of the code you are writing, if its a small little plugin then just wrap it all into one .cpp if its a big beast like OpenFlight or Collada plugins then do something appropriate for that type of code base. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Re How to override plugins...
Hi Robert, Thanks for that. I thought it would be easier to derive from existing zip reader, but evidently that wasn't the way to do it as I then ended up creating two zip reader instances as the proxy construction and the class definition for the base zip reader are in the cpp file. I've fixed my problem by simply deriving from ReaderWriter instead. This brings me to a more general question about readers. Is there a reason why some employ the .h .cpp conventions, whilst others roll them all into one - either .h or .cpp ? Thanks again for the info. Neil ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FBO and Antialiasing
Hi Stephane, The OSG's FBO implementation doesn't yet support anti-aliasing, but it shouldn't be difficult extension to add support for. I do have this on my TODO list, just unfortunately quite within grasp as I've been so swamped with other work. Robert. On Jan 24, 2008 9:49 PM, Stephane Lamoliatte [EMAIL PROTECTED] wrote: Hi, I want to know if it is possible to render a scene to a frame buffer object with antialiasing (MSAA). If it is possible, how to do that with OpenSceneGraph ? -- Stephane Lamoliatte ___ 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] osgHUD 0.1.4 (testing)
On Fri, 2008-01-25 at 10:17 -0500, Jean-Sebastien Guay wrote: Hi Jeremy, Here are some screenshots, Wow, very nice! The potential for this is endless! How is performance compared to just a normal texture that you would map onto a quad? Well, the way it current works is that the image (osgCairo::SurfaceImage, which is derived from both osg::Image and the Cairo surface type) renders to a memory buffer (which is provided by osg::Image, so wherever it actually stores the data...?) and then you call -dirty() on the image and apply it to a quad. You can do this as often as you like to update the texture. In terms of performance, Cairo itself makes every attempt to be as fast as possible, and provides multiple surfaces types for us to use. I use the memory buffer surface, since it maps so well to the memory osg::Image provides, but there are also PDF, PS, and SVG surfaces. There is also an OpenGL accelerated surface type called Glitz, but it's CVS hasn't been updated in a year and I have the hardest time getting it to play nice with other OpenGL apps. Thus, I opted to go with the software Cairo rendering surface, but as long as you aren't redrawing a surface every frame, you should be fine. In fact, my intentions really are to make it so that all images are generated once at load time, so that they are only ever drawn once in the lifetime of the program. Conceptually it would be no different than actually loading the images from files, save that you could define various criteria that control at what resolution the images are rendered for maximum awesomeness. :) I hope to be able to test this on Windows soon and give you some feedback on that front. J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.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
[osg-users] Recurse on a private mutex (FreeBSD)
Occurs on OSG 2.x on FreeBSD 6.2. Definitely a FreeBSD-specific problem. Already tried single-threading. Fatal error 'Recurse on a private mutex.' at line 986 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 0) Abort trap: 6 ___ 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
I sent you a personal email Richard with a few suggestions. What I believe Richard was getting at, is there any global settings that should be made to the system. What I instantly thought of was this : osgDB::DatabasePager* pPager = osgDB::Registry::instance()-getOrCreateDatabasePager(); pPager-setDoPreCompile(mPaging_Precompile); osgDB::ReaderWriter::Options* options = new osgDB::ReaderWriter::Options; options-setObjectCacheHint(osgDB::ReaderWriter::Options::CACHE_ALL); osgDB::Registry::instance()-setOptions(options); //pPager-setTargetFrameRate(mPaging_Frame_Rate_Targeted); //pPager-setExpiryDelay(mPaging_ExpiringDelay); pPager-setMaximumNumOfObjectsToCompilePerFrame(mMaximumObjectsToCompile); //pPager-setThreadPriorityDuringFrame(OpenThreads::Thread::THREAD_PRIORITY_NOMINAL);//HIGH); //pPager-setThreadPriorityOutwithFrame(OpenThreads::Thread::THREAD_PRIORITY_NOMINAL);//HIGH); Partially off topic, I did not feel like the osg training sessions I received were beneficial; as I already came from Opengl course / directx course backgrounds. From: [EMAIL PROTECTED] on behalf of Richard S. Wright Jr. Sent: Fri 1/25/2008 5:03 PM To: OpenSceneGraph Users Subject: 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
Re: [osg-users] Terrain (.osga) optimization tips
Allen, Thanks very much! I had seen traffic about the database pager, but I thought it was an alternate way to load terrain data (more of a lower level hands-on approach). This tells me I glossed over the wrong material ;-) Although new to OSG, I am most certainly not new to software engineering, nor how to do 3D graphics. I realize it is my own pride that makes me feel patronized at times. This is not the first time I have farted at the dinner table so to speak. I need to be better about communicating that when I ask a vague question, I actually _am_ looking for a vague answer that just points me towards where I should be focusing my attention. Richard On Jan 25, 2008, at 11:14 PM, Danklefsen, Allen M wrote: I sent you a personal email Richard with a few suggestions. What I believe Richard was getting at, is there any global settings that should be made to the system. What I instantly thought of was this : osgDB::DatabasePager* pPager = osgDB::Registry::instance()-getOrCreateDatabasePager(); pPager-setDoPreCompile(mPaging_Precompile); osgDB::ReaderWriter::Options* options = new osgDB::ReaderWriter::Options; options-setObjectCacheHint(osgDB::ReaderWriter::Options::CACHE_ALL); osgDB::Registry::instance()-setOptions(options); //pPager-setTargetFrameRate(mPaging_Frame_Rate_Targeted); //pPager-setExpiryDelay(mPaging_ExpiringDelay); pPager- setMaximumNumOfObjectsToCompilePerFrame(mMaximumObjectsToCompile); //pPager- setThreadPriorityDuringFrame (OpenThreads::Thread::THREAD_PRIORITY_NOMINAL);//HIGH); //pPager- setThreadPriorityOutwithFrame (OpenThreads::Thread::THREAD_PRIORITY_NOMINAL);//HIGH); Partially off topic, I did not feel like the osg training sessions I received were beneficial; as I already came from Opengl course / directx course backgrounds. From: [EMAIL PROTECTED] on behalf of Richard S. Wright Jr. Sent: Fri 1/25/2008 5:03 PM To: OpenSceneGraph Users Subject: 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,
Re: [osg-users] Object flags in OpenFlight files
Hi Yefei, If my memory is correct I believe this flag is used by Creator for the Calculate shading operation. Using this flag to enable flat shading didn't work very well. Do you have a model that renders incorrectly? Regards Brede On Jan 25, 2008 11:16 PM, Yefei He [EMAIL PROTECTED] wrote: Hello, Brede, I did an update on OSG yesterday, and noticed that in the OpenFlight plugin, it used to set the shade model of an object to flat shaded when the flag FLAT_SHADED was set, but the latest version does not do it any more. Was this left out by intention? Thanks, Yefei ___ 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] VPB Question
Hi Brian; Try to use osgdem --xx 10 --yy 10 -d heightmap.png -t texturemap.png -o land.ive -a land.osga -v 0.08 -l 5 command! if it doesn't work look at the http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/osgdem link. But I advice you to use coordinated images and elevations to make your own osga database! To get these coordinated images look at the http://seamless.usgs.gov/ link. And you should look at http://www.palomino3d.org/pal/openscenegraph/ to learn how to download these kind of images! Ümit UZUN Date: Fri, 25 Jan 2008 08:39:16 -0500 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: [osg-users] VPB Question I am trying to use the SVN version(Jan 24,2008) of Virtual Planet Builder on windows XP. It is creating terrian with a texture, but it has no height. I used the following osgdem --xx 10 --yy 10 -d heightmap.png -t texturemap.png -o land.ive -a land.osga The images are 2048x2048. Is there something wrong with my command line? Brian _ Windows Live Messenger'ın için Ücretsiz 30 İfadeyi yükle http://get.live.com___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VPB Question
I am trying to use the SVN version(Jan 24,2008) of Virtual Planet Builder on windows XP. It is creating terrian with a texture, but it has no height. I used the following osgdem --xx 10 --yy 10 -d heightmap.png -t texturemap.png -o land.ive -a land.osga The images are 2048x2048. Is there something wrong with my command line? Brian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Object flags in OpenFlight files
Hi, Brede, Actually, no. I was just looking for the place to migrate my custom code that writes the object flags to the comment field of the converted node. In particular, we are using the daylight, dusk and night flags. I'll add it in readRecord(), as before. I believe OSG still doesn't provide a specific place for these flags. That's why we mark them in the comments. Thanks, Yefei -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Brede Johansen Sent: Friday, January 25, 2008 5:13 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Object flags in OpenFlight files Hi Yefei, If my memory is correct I believe this flag is used by Creator for the Calculate shading operation. Using this flag to enable flat shading didn't work very well. Do you have a model that renders incorrectly? Regards Brede ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Object flags in OpenFlight files
Hello, Brede, I did an update on OSG yesterday, and noticed that in the OpenFlight plugin, it used to set the shade model of an object to flat shaded when the flag FLAT_SHADED was set, but the latest version does not do it any more. Was this left out by intention? Thanks, Yefei ___ 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] osgHUD 0.1.4 (testing)
Sweet! I see the movies are in wmv... eww, haha. That may help Windows users but then Linux and Mac users can't watch them (without finding codecs). A standard video format would be nicer... But anyways, I found some more issues when building. If I try to build with Lua I get compiler errors that it can't find lua.h. On my ubuntu machine, I have Lua 5.0 installed, and apparently it has a separate directory (lua50)... and so does Lua 5.1 (lua5.1)... so the current package lookup for lua doesn't work. And I don't get the option to set my own path to Lua if it's not found. I'm not a CMake wiz either so I hunted down some FindLua cmake files here: http://trac-hg.assembla.com/CMakeLua/browser/Modules?rev=109%3Adabdf86e8763 So I changed my local CMake to pick up the lua50 package, and I get another error that luaL_openlibs could not be found. I think that is a lua 5.1 call? So back to CMake, haha. So maybe a note that lua requires lua 5.1... and it's all compiling now (had to change the package from lua to lua5.1). Lucas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] user meeting (WAS Siggraph Course)
Hi everyone, I put up a page for past events on the wiki: http://www.openscenegraph.org/projects/osg/wiki/Community/PastEvents I also moved the old past events from the old wiki (which only contained the Highland Gathering 2006). Please make corrections where appropriate (both the old and the new). Also please add other memorable past events to the page, as I'm sure there have been more than just those two! Siggraph BOFs for example, or anything else. Thanks, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgHUD 0.1.4 (testing)
On Fri, 2008-01-25 at 09:30 -0500, Lucas Goss wrote: Sweet! I see the movies are in wmv... eww, haha. That may help Windows users but then Linux and Mac users can't watch them (without finding codecs). A standard video format would be nicer... Trust me, I tried, but I was unable to find a tool in Linux that would encode a video that would work easily on both operating systems. No matter what I did with ffmpeg (or anything else that might use the same libraries it does), I couldn't get one. If you know the invocation, please by all means tell me. :) But anyways, I found some more issues when building. If I try to build with Lua I get compiler errors that it can't find lua.h. On my ubuntu machine, I have Lua 5.0 installed, and apparently it has a separate directory (lua50)... and so does Lua 5.1 (lua5.1)... so the current package lookup for lua doesn't work. And I don't get the option to set my own path to Lua if it's not found. I'm not a CMake wiz either so I hunted down some FindLua cmake files here: http://trac-hg.assembla.com/CMakeLua/browser/Modules?rev=109%3Adabdf86e8763 Well, nothing fancy should really be required if pkg-config is properly reporting values. I'm using Fedora these days and the FindPkgConfig module for CMake should take care of that. However, I'll grab an Ubuntu machine here in the office later today and test this out more--thanks for the heads up. So I changed my local CMake to pick up the lua50 package, and I get another error that luaL_openlibs could not be found. I think that is a lua 5.1 call? So back to CMake, haha. So maybe a note that lua requires lua 5.1... and it's all compiling now (had to change the package from lua to lua5.1). Yeah, Lua 5.1 is definitely required, so I'll make a note of that. :) Lucas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Small VPB patches for Windows
Hello Robert, Sorry for turning this into a troubleshooting thread. Bringing it back to osg-users instead of osg-submissions. But please integrate the code I sent yesterday when you have a chance. Thanks. Seems I spoke too soon. With only 2 levels, it works well, but with 4 levels, for some reason, front-facing tiles are paged out when they shouldn't be... During the class I actually generated other databases using osgdem directly from the command line with 4 levels, and they worked quite well, so I don't know what vpbmaster is doing wrong. I fiddled a bit more with this while I was at the airport waiting for my plane (I always wanted to say that! :) It's only when outputting to an archive that the problem occurs. I have attached the two scripts I use (which were created with osgdem options --so file), but the only difference is the line: ArchiveName world_20k_10k_4.osga Without that line, the result is what you would expect (an .ive file with all the subtiles, and it looks good in osgviewer). With that line, I get an .osga file, but when it loads, the tiles directly in front of the viewer disappear and the ones behind page in, until I'm left with a hemisphere of the back of the Earth that just stays like that no matter what the point of view is. I'm also attaching the two log files for the runs of vpbmaster. Maybe something there will give you a hint. At first glance, I think the run that created the archive was way too fast... At least, much faster than the other, so that might indicate a problem. Note that I ran the two vpbmaster invocations in different directories so that they did not interfere with each other, and did not use the same cache. Also, the suffixes (_noarchive and _archive) are just to differentiate the attached files, they were named without those when I ran vpbmaster. I can place the two resulting databases on my web server if you want (they're not too big with just 4 levels). But if you can reproduce the problem on your side, it might not be necessary. Hope this helps. Thanks, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ world_20k_10k_4_noarchive.vpb Description: Binary data world_20k_10k_4_archive.vpb Description: Binary data 0.084254 :setDistributedBuildSplitLevel=2 0.149745 :Generated tasks file = build_master.tasks 0.14983 :Begining run 0.149897 :scheduling task : build_root_L0_X0_Y0.task 0.150552 :scheduling task : build_subtile_L1_X0_Y0.task 0.159357 :scheduling task : build_subtile_L1_X1_Y0.task 0.178568 :localhost : running osgdem --run-path C:\Documents and Settings\jeang\Desktop\CourseData\osg_terrain\tests\4 -s build_master.source --record-subtile-on-leaf-tiles -l 2 --task build_root_L0_X0_Y0.task --cache world_20k_10k_4.cache --log build_root_L0_X0_Y0.log 0.192798 :localhost : running osgdem --run-path C:\Documents and Settings\jeang\Desktop\CourseData\osg_terrain\tests\4 -s build_master.source --subtile 1 0 0 --task build_subtile_L1_X0_Y0.task --cache world_20k_10k_4.cache --log build_subtile_L1_X0_Y0.log 19.0355 :localhost : completed in 18.227400 seconds : osgdem --run-path C:\Documents and Settings\jeang\Desktop\CourseData\osg_terrain\tests\4 -s build_master.source --record-subtile-on-leaf-tiles -l 2 --task build_root_L0_X0_Y0.task --cache world_20k_10k_4.cache --log build_root_L0_X0_Y0.log result=0 19.0391 :localhost : running osgdem --run-path C:\Documents and Settings\jeang\Desktop\CourseData\osg_terrain\tests\4 -s build_master.source --subtile 1 1 0 --task build_subtile_L1_X1_Y0.task --cache world_20k_10k_4.cache --log build_subtile_L1_X1_Y0.log 55.9277 :localhost : completed in 55.091100 seconds : osgdem --run-path C:\Documents and Settings\jeang\Desktop\CourseData\osg_terrain\tests\4 -s build_master.source --subtile 1 0 0 --task build_subtile_L1_X0_Y0.task --cache world_20k_10k_4.cache --log build_subtile_L1_X0_Y0.log result=0 55.9287 :localhost : completed in 36.424900 seconds : osgdem --run-path C:\Documents and Settings\jeang\Desktop\CourseData\osg_terrain\tests\4 -s build_master.source --subtile 1 1 0 --task build_subtile_L1_X1_Y0.task --cache world_20k_10k_4.cache --log build_subtile_L1_X1_Y0.log result=0 56.9284 :End of TaskSet: tasksPending=0 taskCompleted=3 taskRunning=0 tasksFailed=0 56.9285 :End of run: tasksPending=0 taskCompleted=3 taskRunning=0 tasksFailed=0 56.9285 :MachinePool::reportTimingStats() 56.9286 :Machine : localhost 56.9286 :Task::type='' minTime=18.883900 maxTime=55.767005 averageTime=37.181202 totalComputeTime=111.543605 numTasks=3 56.9287 :Finished run successfully. 56.9287 :Total elapsed time = 56.928693 0.0155517 :setDistributedBuildSplitLevel=2 0.0434921 :Generated tasks file = build_master.tasks 0.0435734 :Begining run 0.0436019 :scheduling task : build_root_L0_X0_Y0.task 0.0495624 :scheduling task : build_subtile_L1_X0_Y0.task 0.04986 :scheduling task : build_subtile_L1_X1_Y0.task
Re: [osg-users] Terrain (.osga) optimization tips
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 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,
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
