Re: [Flightgear-devel] Further 3D Clouds updates
Frederic Bouvier wrote: I cheched your patch in but I still have the checkerboard : http://frbouvi.free.fr/flightsim/fgfs_clouds_checker.jpg but only when the weather scenario is set to none. -Fred Thanks for checking in all my patches. I'm aware that there are still checkerboard issues. That's next on my list :) -Stuart - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Further 3D Clouds updates
Well, just tested, very nice, I withnessed an improvement in performance. My specs: Athlon XP2000, 768MB ram, NVidia FX 5900 @ 1680x1050 (system: linux with nvidia drivers), no AA Using: sg + fg cvs, OSG 2.7.5; everything enabled, custom settings, using metar, no ai/mp planes around Startup: 30fps 2D/ 20fps 3D (clouds at 6000ft, scattered, thickness 600ft) Flying 400ft/440knots: 26fps 2D/ 19fps 3D (clouds at 6000ft, scattered, thickness 600ft) Flying 6300ft/440knots: 35fps 2d/ 11-22fps (clouds at 6000ft, scattered, thickness 600ft) Note: Flying within the clouds resulted in 22fps, getting very close or through clouds 11fps Changing conditions: Low vis (7000m), clouds at 8000ft(broken) and 4000ft(broken), thickness 600ft Flying @ 8000ft/440knots: 14fps 2D/ 6fps 3D Low vis being also a frame rate killer? Changing conditions: Vis (25000m), clouds at 5500ft(broken), thickness 600ft Flying @ 8000ft/440knots: 25fps 2D/ 16fps 3D Flying @ 6000ft/440knots: 20fps 2D/ 12fps 3D Hope this helps a bit, Markus Stuart Buchanan wrote: Stuart Buchanan wrote: Vivian Meazza wrote: And I have yet to see any 3d clouds. Any clues on where I should be looking (yes the box is checked :-)) Something has changed in the environment manager which means that clouds generateion is now inconsistent. I'm still tracking it down, as my recent changes shouldn't have affected this. Well, the cause was a bug in my code, but it didn't expose itself until we moved to multiple cameras. The attached patch fixes the problem. I've also put in a new heuristic to improve the frame-rate. Clouds that are already sorted are likely to still be sorted in subsequent frames. Therefore I've put in a back-off mechanism for the bubble-sort pass. This should mean that if you stay completely stationary, once the clouds become sorted they will eventually only perform a bubble sort pass every 128 frames. It would be good to get a feel for how bad performance is with 3D clouds. At the moment I don't have a handle on whether performance is almost good enough, or completely unacceptable. I'd appreciate it if people would post their observations, providing details of their machine spec, graphics options and the frame-rate with and without 3D clouds - ideally with a description of the general load on the machine. Thanks, -Stuart - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Further 3D Clouds updates
I haven't applied the patch yet, so I can't give full specs. With CVS as of a few days ago, I did notice that OSG attributed almost double the 'update' time with 3D clouds on. I assume that Tim can comment on what The 'update' time is. I assume this means that (at least prior to your patch) the 3D clouds is current CPU limited. I can't comment on the 'draw' time difference, although it does appear that there are now extra 'cameras' in the last few weeks. On my multi-GPU system I used to have num-displays+1, now I seem to have num-displays*2. Is this expected? For multi-display, this would have an impac on framerate (particular with the serialized mode that is default. I'll discuss more fully in a different email - I just wanted to touch this here in case it is clouds related. Regards... Matthew On 11/26/08, Markus Zojer [EMAIL PROTECTED] wrote: Well, just tested, very nice, I withnessed an improvement in performance. My specs: Athlon XP2000, 768MB ram, NVidia FX 5900 @ 1680x1050 (system: linux with nvidia drivers), no AA Using: sg + fg cvs, OSG 2.7.5; everything enabled, custom settings, using metar, no ai/mp planes around Startup: 30fps 2D/ 20fps 3D (clouds at 6000ft, scattered, thickness 600ft) Flying 400ft/440knots: 26fps 2D/ 19fps 3D (clouds at 6000ft, scattered, thickness 600ft) Flying 6300ft/440knots: 35fps 2d/ 11-22fps (clouds at 6000ft, scattered, thickness 600ft) Note: Flying within the clouds resulted in 22fps, getting very close or through clouds 11fps Changing conditions: Low vis (7000m), clouds at 8000ft(broken) and 4000ft(broken), thickness 600ft Flying @ 8000ft/440knots: 14fps 2D/ 6fps 3D Low vis being also a frame rate killer? Changing conditions: Vis (25000m), clouds at 5500ft(broken), thickness 600ft Flying @ 8000ft/440knots: 25fps 2D/ 16fps 3D Flying @ 6000ft/440knots: 20fps 2D/ 12fps 3D Hope this helps a bit, Markus Stuart Buchanan wrote: Stuart Buchanan wrote: Vivian Meazza wrote: And I have yet to see any 3d clouds. Any clues on where I should be looking (yes the box is checked :-)) Something has changed in the environment manager which means that clouds generateion is now inconsistent. I'm still tracking it down, as my recent changes shouldn't have affected this. Well, the cause was a bug in my code, but it didn't expose itself until we moved to multiple cameras. The attached patch fixes the problem. I've also put in a new heuristic to improve the frame-rate. Clouds that are already sorted are likely to still be sorted in subsequent frames. Therefore I've put in a back-off mechanism for the bubble-sort pass. This should mean that if you stay completely stationary, once the clouds become sorted they will eventually only perform a bubble sort pass every 128 frames. It would be good to get a feel for how bad performance is with 3D clouds. At the moment I don't have a handle on whether performance is almost good enough, or completely unacceptable. I'd appreciate it if people would post their observations, providing details of their machine spec, graphics options and the frame-rate with and without 3D clouds - ideally with a description of the general load on the machine. Thanks, -Stuart - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list
Re: [Flightgear-devel] Further 3D Clouds updates
Hi, Well, just tested, very nice, I withnessed an improvement in performance. My specs: Athlon XP2000, 768MB ram, NVidia FX 5900 @ 1680x1050 (system: linux with nvidia drivers), no AA Using: sg + fg cvs, OSG 2.7.5; everything enabled, custom settings, using metar, no ai/mp planes around Startup: 30fps 2D/ 20fps 3D (clouds at 6000ft, scattered, thickness 600ft) Flying 400ft/440knots: 26fps 2D/ 19fps 3D (clouds at 6000ft, scattered, thickness 600ft) Flying 6300ft/440knots: 35fps 2d/ 11-22fps (clouds at 6000ft, scattered, thickness 600ft) Note: Flying within the clouds resulted in 22fps, getting very close or through clouds 11fps Changing conditions: Low vis (7000m), clouds at 8000ft(broken) and 4000ft(broken), thickness 600ft Flying @ 8000ft/440knots: 14fps 2D/ 6fps 3D Low vis being also a frame rate killer? Changing conditions: Vis (25000m), clouds at 5500ft(broken), thickness 600ft Flying @ 8000ft/440knots: 25fps 2D/ 16fps 3D Flying @ 6000ft/440knots: 20fps 2D/ 12fps 3D Hope this helps a bit, Markus Here comes my test: Intel DualCore E6750 2.66 Ghz 3,6 GB RAM Nvidia 8800GT @1280x768 full AA FGFS-OSG win32 built by Fred from 11/26/2008 everything enabled Real wether fetch, framerate-throttle at 60fps Startup on TNCM: 60fps 2D/ 49fps 3D (fair weather, visibility: 25000m ) Flying 400ft/440knots: 60fps 2D/ 53fps 3D (fair weather, visibility: 25000m) Flying 6300ft/440knots: 60ps 2d/ 60fps (fair weather, visibility: 25000m) Note: Flying within the clouds no reducing of fps visible No with METAR enabled: LSZH startup cloud base at 1304ft thickness 600ft 38fps 2D/ 21fps 3d (visibility: 8000m) LSZH heading 160 8500ft altitude cloud base 1304ft thickness 600ft 48fps 2d/ 20fps 3d (visibility: 8000m) The same for beeing in the air about 2400-6500 ft altitude scattered cloudlayer seems to be a framerate-killer So I noticed the same like Markus: increasing visibility increases the fps! Regarding the ugly-borders: together with increasing visibility (decreasing fog) and better texture (third version in developement here on my pc) the ugly-borders nearly disappear and the clouds looks much better (fewer ugly edges in the clouds- sorting looks much better; much softer shading!) Is there a way to exclude the 3d-clouds by overdrawn from the fog? (like it is possible with the terrain?) http://www.flightgear.org/forums/download/file.php?id=382 Regards HHS - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Total Cameras in statistics view
Hi, Recently, I discovered that there seem to be almost the double cameras that there were previously. This is in the event/update/cull/draw page of the statistics page. Is this expected? I also notice that each camera seems to be 'paired' with another camera - as in the 2nd camera will not start it's cull and draw until after the previous one. This is in a 5 camera config across 5 displays. I am using the 'CullThreadPerCamera' model, with the gc.realize commented out with the OSG_SERIALIZE_DRAW variable turned off. Regards... Matthew -- Sent from my mobile device - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Performance and initialization patch
Hi, this is a patch to speed up startup times and some other misc things. Please kindly try it out on your configurations. Commenting on each file/change: nasal/misc.h: If p == 0 return, else call free(p). Dont go into the malloc lib for nothing, probably free() does this check 1st thing in most implementations, no need to test the malloc library. p == 0 happens, checked with debugger. logstream.cxx: Modified a bit the logstream implementation to avoid (stack) descent down into (iostream) hell if we are not logging anything anyway. As it is right now, it happily builds the string to print (iostream hell, deep stacks, strings new/delete/copy) and then discards it. I´ve counted over half a million calls to sglog() before the scenery is fully loaded (cant remember with what configuration, more on config below). Also, the global logstream is initialized once at startup (constructors, struct ignore_me), no need to check everytime it is called if it's initialized. Maybe if sglog() is used in any global constructor it could happen that it is not initialized and crash, so please, dont use it in the global constructors ;) strutils.cxx, simple..cxx, apt_loader.cxx Accelerate parsing of apt.dat. As it stands it does aprox 5 (five) million wasteful new/delete pairs, mostly in the strutils::split, vectorrunway growing and unnecessary string initializations in the main parse loop. Now it does 1 million new (1 per airport, 2 per runway/taxiway) and 100 (hundred) deletes. I find it's acceptably fast now. Also, it loads Ypenburg The Hague's runways, seems nobody flew there ever :) fg_os_osgviewer.cxx: Any particular reason to not run osg multithreaded as default? ViewPartitionNode, CameraGroup: Small compile fix for a OSG version with float matrices, instead of double. Tried to compile with float matrices to see if it affects speed, but the quantization is visible (aprox .5m) and the airplane jitters horribly. main.cxx: While showing the splash screen, limit the frame rate. I was getting 200fps at the splash screen, which is pointless wasteful, specially on single-core machines. On multicore one core is pegged at 100%, another is loading tiles. If you run with VBLANK on, on a fast single-core machine, it may not matter too much. Anyway, 15Hz redraws should be enough, quite possibly as low as 5Hz could be acceptable. Older computer owners should notice a difference. positioned.cxx: I dont know what this was for. I think it was a compile fix. I have some other changes to the codebase around, had to edit the patch files. Dont apply if everything else compiles for you :) The most important changes are the apt.dat optimization, the logstream optimization and the splash screen throttling. On this 3Ghz dual core intel E2160 with hot disk-caches and --disable-random-objects --disable-sound --aircraft=ufo it takes 6 seconds to start loading scenery tiles and 12 seconds to splash screen fade out. Airway loading is 1 second and does quite a few new/deletes, too. Maybe I´ll take a look at it. Going forward another big config issue I see is --enable-random-objects tile loading. It's orders of magnitude slower than with random-objects disabled. I'll try to take a look at it, but's all the osgDB implementation and it's big. Also, the tile loader is not concurrent, only one tile is loaded at a time. I can start 20 osgDB threads and only one of them will do anything useful. This is specially noticed with --enable-random-objects. As an interim solution it should be possible to start some threads to do the random objects addition after the base tiles have been loaded and displayed, later adding the subgraphs to the already displaying tiles and using more than one core to do the heavy random object generation. regards, yon FlightGear - Copy.patch Description: Binary data SimGear - Copy.patch Description: Binary data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Total Cameras in statistics view
Matthew Tippett wrote: Hi, Recently, I discovered that there seem to be almost the double cameras that there were previously. This is in the event/update/cull/draw page of the statistics page. Is this expected? Yes. In order to draw our huge Z range -- from the tip of your nose (more or less) out to the horizon -- without flickering and other artifacts, the scene is drawn twice. It's drawn with the near plane set to 100 meters, then the depth buffer is cleared, and the scene is drawn again with the far plane at 100 meters and the near plane at its nominal value, currently .1 meters by default. It's been done this way for some time by a ViewPartitionNode in the scene graph. I recently changed the scheme to use two slave cameras as the camera-like nature of the ViewPartitionNode was screwing up view-dependent shadow work I am doing. Plus, this is the recommended way to do such a partition, according to the wisdom of the OSG users list. There shouldn't be any performance difference in the change to slave cameras, but the statistics for the two cameras will be displayed in the stats display. I also notice that each camera seems to be 'paired' with another camera - as in the 2nd camera will not start it's cull and draw until after the previous one. This is in a 5 camera config across 5 displays. Because of the depth ordering, the far camera must be drawn before the near camera. Note that this is not new behavior, it is just now exposed in the timing statistics. I don't know why the two cull passes are serialized, unless you're simply running out of processors to run the cull passes. I am using the 'CullThreadPerCamera' model, with the gc.realize commented out with the OSG_SERIALIZE_DRAW variable turned off. I don't think that's one of the choices :) Do you mean CullThreadPerCameraDrawThreadPerContext? You might try CullDrawThreadPerContext and see if that gives better performance. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
Hi, * Yon Uriarte -- Wednesday 26 November 2008: this is a patch to speed up startup times and some other misc things. Thanks for taking care of that. Startup time is really a problem, made worse by the fact that one has to restart fgfs to use another aircraft. I'll leave commenting on the nasal, runway, and osg changes to the respective maintainers and focus on one thing: +++ misc/strutils.cxx 24 Nov 2008 17:13:29 - [...] /** +* Avoid new/delete/cpconstructor clusterfsck +*/ + int + split_whitespace_aptdat( const string str, int maxsplit, vectorstring res ) [...] + split_aptdat( const string str, const char* sep, int maxsplit, vectorstring res ) This is IMHO not acceptable! 1) If these functions are meant to be better than the existing split()/split_whitespace(), then they have to replace them. If they are different and customized for dealing with Robin PEEL's apt.dat file (as the name implies), then they have no place in SimGear. This is a set of generic libraries, and not (supposed to be) tied to FlightGear, let alone to Robin's DB. 2) The function head focuses on what the function doesn't do (avoids), rather than on what it does. If you think split()/split_whitespaces() are fscking something up, then please explain why you think they should keep doing that. 3) We value the coolness factor of f-words rather low, even when they are disguised as acronyms for file system check. Hey, even the use of WTF is prohibited to my disappointment. (Whoops. :-) BTW: you introduced tabs in files that are space-indented, and even in a way that only works with 4-position tabs, rather than the standard: 8 positions. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and initialization patch
On 26 Nov 2008, at 11:14, Yon Uriarte wrote: Hi, this is a patch to speed up startup times and some other misc things. Please kindly try it out on your configurations. Commenting on each file/change: logstream.cxx: Modified a bit the logstream implementation to avoid (stack) descent down into (iostream) hell if we are not logging anything anyway. As it is right now, it happily builds the string to print (iostream hell, deep stacks, strings new/delete/copy) and then discards it. I´ve counted over half a million calls to sglog() before the scenery is fully loaded (cant remember with what configuration, more on config below). Also, the global logstream is initialized once at startup (constructors, struct ignore_me), no need to check everytime it is called if it's initialized. Maybe if sglog() is used in any global constructor it could happen that it is not initialized and crash, so please, dont use it in the global constructors ;) Sounds good to me. strutils.cxx, simple..cxx, apt_loader.cxx Accelerate parsing of apt.dat. As it stands it does aprox 5 (five) million wasteful new/delete pairs, mostly in the strutils::split, vectorrunway growing and unnecessary string initializations in the main parse loop. Now it does 1 million new (1 per airport, 2 per runway/taxiway) and 100 (hundred) deletes. I find it's acceptably fast now. Also, it loads Ypenburg The Hague's runways, seems nobody flew there ever :) Excellent. I've been doing some similar work in that area (not yet ready for mass consumption) and also noticed the Ypenburg issue :) From a code aesthetic point of view, I can't say I like the extra runway count and taxiway count arguments to addAirport, but I appreciate the heap-traffic savings of getting the arrays correctly sized. fg_os_osgviewer.cxx: Any particular reason to not run osg multithreaded as default? I suspect this is paranoia due to some of the more exotic OSG threading modes being less well tested. I believe I can be over-riden by the OSG_THREADING environment variable in any case. Tim Moore can hopefully say for sure. positioned.cxx: I dont know what this was for. I think it was a compile fix. I have some other changes to the codebase around, had to edit the patch files. Dont apply if everything else compiles for you :) This is 'my' file, it's new in the codebase and could easily contain silly things. You patch only adds an operator, so I'm not sure if it's needed or not. dual core intel E2160 with hot disk-caches and --disable-random- objects --disable-sound --aircraft=ufo it takes 6 seconds to start loading scenery tiles and 12 seconds to splash screen fade out. Airway loading is 1 second and does quite a few new/deletes, too. Maybe I´ll take a look at it. I would hold off airways unless you have an abundance of time (or look at random objects first), or if it's a quick change, since I'm planning some more drastic changes in that area, possibly including a file format change. If it's a quick win, go for it, of course. Going forward another big config issue I see is --enable-random- objects tile loading. It's orders of magnitude slower than with random-objects disabled. I'll try to take a look at it, but's all the osgDB implementation and it's big. Also, the tile loader is not concurrent, only one tile is loaded at a time. I can start 20 osgDB threads and only one of them will do anything useful. This is specially noticed with --enable-random- objects. As an interim solution it should be possible to start some threads to do the random objects addition after the base tiles have been loaded and displayed, later adding the subgraphs to the already displaying tiles and using more than one core to do the heavy random object generation. Thanks for doing this, it's much appreciated. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Another person selling FlightGear under dubious pretenses
Hi Folks, Can whoever is working on the NZ scenery put Andrew Casey's house on the ground so we can buzz it until he complies. :) That was a joke (possibly a bad one). dave. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Total Cameras in statistics view
Comments within Original Message Subject: Re: [Flightgear-devel] Total Cameras in statistics view From: Tim Moore [EMAIL PROTECTED] To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Date: 26/11/08 09:57 AM Matthew Tippett wrote: Yes. In order to draw our huge Z range -- from the tip of your nose (more or less) out to the horizon -- without flickering and other artifacts, the scene is drawn twice. It's drawn with the near plane set to 100 meters, then the depth buffer is cleared, and the scene is drawn again with the far plane at 100 meters and the near plane at its nominal value, currently .1 meters by default. It's been done this way for some time by a ViewPartitionNode in the scene graph. I recently changed the scheme to use two slave cameras as the camera-like nature of the ViewPartitionNode was screwing up view-dependent shadow work I am doing. Plus, this is the recommended way to do such a partition, according to the wisdom of the OSG users list. There shouldn't be any performance difference in the change to slave cameras, but the statistics for the two cameras will be displayed in the stats display. Okay. So that points a smoking gun at the near camera (call it what you will :) is not getting drawn. Is the complete code submitted? It seems to be spending time in the draw for both the near and far camera. I think others have seen this too. Is there any different camera settings that are needed (I am using camera groups as described in the README.multiscreen with defaults except for the view. I also notice that each camera seems to be 'paired' with another camera - as in the 2nd camera will not start it's cull and draw until after the previous one. This is in a 5 camera config across 5 displays. Because of the depth ordering, the far camera must be drawn before the near camera. Note that this is not new behavior, it is just now exposed in the timing statistics. I don't know why the two cull passes are serialized, unless you're simply running out of processors to run the cull passes. The ordering does make sense, however it appears as the secondary cull occurs immediate after the primary draw completes. I can't get CullThreadPerCameraDrawThreadPerContext to start up reliably, so it might be related to that. Does the slave cameras honor the OSG_SERIALIZE_DRAW variable (also note that Csaba got me to remove a couple of gc.realize() calls to deserialize the CullDrawThreadPerContext draw. I am using the 'CullThreadPerCamera' model, with the gc.realize commented out with the OSG_SERIALIZE_DRAW variable turned off. I don't think that's one of the choices :) Do you mean CullThreadPerCameraDrawThreadPerContext? You might try CullDrawThreadPerContext and see if that gives better performance. As mentioned before, there seems to be deadlocks starting up with CullThreadPerCameraDrawThreadPerContext, but I have found that CullDrawThreadPerContext is quite reliable now. Regards, Matthew - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Non-orthogonal frustums for multi-camera support
Hi, I have been wrestling with this for a few weeks now. As some of you are aware, I am slowly preparing a new multi-head demo with around 8 GPUs in it (so up to 16 heads). The new camera support is great, but there are some problems with the way the frustums work. My understanding is that the fundamental controls are for a direction for the camera. With large numbers of monitors this begins to fall apart. The view frustums will overlap when you don't create an offset and begin to creat monitors in both the horizontal and vertical directions. With offsets you will have to stack the views on top of each other and in theory get the bottom of one frustum to align with the other, but then you end up having visual issues since the cameras are separate. So what I would like to be able to do is take the layout of the cameras, determine their angles to the camera, and define a frustum that has a non-orthogonal face. The first camera code that Tim released seemed to do this (which meant there was some visual quirks for monitors far out to the sides (like verticals being at angles and so on), but for the person sitting in front of all the screens it looked about right. Are there any other magic options that would allow me to get to that? (7+9 is my current plan). Regards, Matthew - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Nasal: executing commands (Unix)
FlightGear's Nasal doesn't support running external commands.
Partly because it's too dangerous, but also because Nasal's
unix module isn't fully cross-platform (read: Windows isn't
good enough for it ;-)
On Unices (Linux, OSX) it's fairly trivial to implement this
feature and to keep it sufficiently secure. Let's implement
a key binding that opens Google Maps in FireFox for the
current location:
1) Make a FIFO:
$ mkdir -p ~/.fgfs/Exportmkfifo ~/.fgfs/Export/cmdfifo
2) Write a script that scans the FIFO (attached). Always start
it together with fgfs. Add it to your fgfs start script (if
you have one) or make an alias:
$ alias fgfs=fgfs.fifo.runner fgfs;
kill $(/sbin/pidof -x fgfs.fifo.runner) /dev/null
3) Add a Nasal exec() function somewhere, for example in
~/.fgfs/Nasal/local.nas, which writes to the FIFO:
globals.exec = func {
var f = io.open(getprop(/sim/fg-home) ~ /Export/cmdfifo, w);
io.write(f, call(sprintf, arg) ~ \n);
io.close(f);
}
The globals. prefix makes the function globally available without
prefix. The function can be used with printf()-like formats:
exec(some-command --in %s --out %s, arg1, arg2);
4) And to a key definition of your choice add this binding:
binding
commandnasal/command
script
var lat = getprop(/position/latitude-deg);
var lon = getprop(/position/longitude-deg);
exec(openurl
http://maps.google.com/maps?ll=%.10f,%.10famp;z=12amp;t=h;, lat, lon);
/script
/binding
To prevent abuse, the fgfs.fifo.runner script only runs a hard-coded
set of commands and doesn't hand anything over to eval or a subshell.
If you like, make the fifo harder to find by putting it somewhere else
and giving it a non-guessable name. Just make sure to add a WRITE rule
for it to $FG_ROOT/Nasal/IOrules then. (The ~/.fgfs/Export/ directory
is write-enabled by default.)
m.
fgfs.fifo.runner
Description: application/shellscript
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal: executing commands (Unix)
* Melchior FRANZ -- Wednesday 26 November 2008: 2) Write a script that scans the FIFO (attached). Better version attached. (In this simple case we don't need the inner loop and the timeout.) m. fgfs.fifo.runner Description: application/shellscript - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Non-orthogonal frustums for multi-camera support
Matthew Tippett wrote: Hi, I have been wrestling with this for a few weeks now. As some of you are aware, I am slowly preparing a new multi-head demo with around 8 GPUs in it (so up to 16 heads). The new camera support is great, but there are some problems with the way the frustums work. My understanding is that the fundamental controls are for a direction for the camera. With large numbers of monitors this begins to fall apart. The view frustums will overlap when you don't create an offset and begin to creat monitors in both the horizontal and vertical directions. With offsets you will have to stack the views on top of each other and in theory get the bottom of one frustum to align with the other, but then you end up having visual issues since the cameras are separate. So what I would like to be able to do is take the layout of the cameras, determine their angles to the camera, and define a frustum that has a non-orthogonal face. You can't have a frustum with a non-orthogonal face unless you render to a texture and project it, which we don't do. Actually, you don't want to do that unless you're projecting the image unto a screen. OSG does have some builtin support for rendering on domes and such, but I digress. What you need to do for each screen is determine the direction from the eye-point to the plane containing the screen and encode that in the view parameters of the camera for that screen. Then you need to determine the frustum dimensions, which don't need to be symmetric, that place the screen properly in that plane. The first camera code that Tim released seemed to do this (which meant there was some visual quirks for monitors far out to the sides (like verticals being at angles and so on), but for the person sitting in front of all the screens it looked about right. Are there any other magic options that would allow me to get to that? (7+9 is my current plan). Not much magic other than getting out a tape measure and protractor. It might help to build a model of your rig in Blender or another 3D modeling program and make measurements of the model. You could also simplify your geometry by arranging the screens in a cylinder and following the curved monitor example in README.multiscreen. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Non-orthogonal frustums for multi-camera support
Thanks. I guess the frustum calculation is possibly the most difficult part (at least investing some more effort) and dusting off the maths. With the original shear code that you implemented first there did appear to be a project of some sort - the far left and right screens exhibit a level of perspective or distortion. I'll see if I can provide a camera layout that demonstrates it. How many monitors do you have (so I can see if I can demonstrate that way). I am guessing that I am missing something on the projection side. My mental model says that if the screen is not perpendicular to my eye, I need to somehow encode that. Unfortunately with the standard multiple monitor stands (2x2) you have some the screens at about 170 degrees to each other - not quite flat. I'll see if I can get something in blender to suit to show what I am using. Even a simple 2x2 layout doesn't quite sit too well at the moment - I'll send some photos later. Regards... Matthew On 11/26/08, Tim Moore [EMAIL PROTECTED] wrote: Matthew Tippett wrote: Hi, I have been wrestling with this for a few weeks now. As some of you are aware, I am slowly preparing a new multi-head demo with around 8 GPUs in it (so up to 16 heads). The new camera support is great, but there are some problems with the way the frustums work. My understanding is that the fundamental controls are for a direction for the camera. With large numbers of monitors this begins to fall apart. The view frustums will overlap when you don't create an offset and begin to creat monitors in both the horizontal and vertical directions. With offsets you will have to stack the views on top of each other and in theory get the bottom of one frustum to align with the other, but then you end up having visual issues since the cameras are separate. So what I would like to be able to do is take the layout of the cameras, determine their angles to the camera, and define a frustum that has a non-orthogonal face. You can't have a frustum with a non-orthogonal face unless you render to a texture and project it, which we don't do. Actually, you don't want to do that unless you're projecting the image unto a screen. OSG does have some builtin support for rendering on domes and such, but I digress. What you need to do for each screen is determine the direction from the eye-point to the plane containing the screen and encode that in the view parameters of the camera for that screen. Then you need to determine the frustum dimensions, which don't need to be symmetric, that place the screen properly in that plane. The first camera code that Tim released seemed to do this (which meant there was some visual quirks for monitors far out to the sides (like verticals being at angles and so on), but for the person sitting in front of all the screens it looked about right. Are there any other magic options that would allow me to get to that? (7+9 is my current plan). Not much magic other than getting out a tape measure and protractor. It might help to build a model of your rig in Blender or another 3D modeling program and make measurements of the model. You could also simplify your geometry by arranging the screens in a cylinder and following the curved monitor example in README.multiscreen. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
