[Flightgear-devel] Shaders: Urban Water= conflicting ?
Hello, With GUI custom settings , shaders options: When i modify the water value there is within the scenery, an ugly interference on the Urban effect, is it just me ? Anyhow it does not explain the wrong effect of it, at some view positions ( refer to a previous mail FG Git Master Branch today ) Thank Ahmad -- GrthTeam https://sites.google.com/site/grtuxhangar -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders vs. frame rate;
Spoke too soon. The trees look great, but the frame rate hit makes it unusable (from 30-35 to 2-4) even with the other shaders disabled. Thank you! I haven't had seen trees in FlightGear for ages (can't run with shaders). I didn't realize the trees were supported at all without shaders. Trees are still done with shaders - all that is being discussed is if the menu option 'material shaders' should deactivate trees as well, or if it is sufficient to just (de)-activate trees using their own checkbox. * Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders vs. frame rate;
Am 20.11.11 12:55, schrieb Anders Gidenstam: On Sun, 20 Nov 2011, ThorstenB wrote: Since some effects may be aircraft specific it might be useful to make the advanced dialog dynamic - one way would be to add a checkbox for each *-effect property found in /sim/rendering/shaders/ . Potentially scenery objects or MP aircraft might load some new effects (general or not) so the set of control properties might change (grow) at runtime. Cheers, Anders Me, personally: +10 for this proposal here from Anders (saying more to myself, its not a vote I know). Hm, getting such a useful menu, I hope this does not shift the impact from shaders to the GUI itself. (While designing such a menu in recent prehistoric GUI might look like a mission impossible, but I am sure we can get it.) Another question is probably where this inherits-from-system goes at the moment. I.e. 737-300 733reflect.eff inherits from reflect effects, but sets most values again/new, while i.e. 747-400 744reflect.eff makes really use of inheriting, changing only the values that have to be changed. I dont know if this could affect performance too, the 737-300 example ? 737-300 is a good example anyway, it inherits also from clouds. Does this mean switching off the cloud shaders switch contrails off too ? nameEffects/733reflect/name inherits-fromEffects/reflect/inherits-from nameEffects/contrail/name inherits-fromEffects/cloud/inherits-from nameEffects/contrail2/name inherits-fromEffects/cloud/inherits-from Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders vs. frame rate;
Spoke too soon. The trees look great, but the frame rate hit makes it unusable (from 30-35 to 2-4) even with the other shaders disabled. On Sun, Nov 20, 2011 at 5:49 PM, Gary Carvell gary.carv...@gmail.com wrote: Thank you! I haven't had seen trees in FlightGear for ages (can't run with shaders). I didn't realize the trees were supported at all without shaders. Could that fix be applied automatically so the trees are visible whether shaders are on or off? Gary On Sun, Nov 20, 2011 at 5:52 AM, Gijs de Rooy gijsr...@hotmail.com wrote: Hi all! Martin wrote: Does anyone know how to have the random trees without all this ? In Effects/trees.eff, comment out/remove line 23. !--property/sim/rendering/shader-effects/property-- If you would like to use the dialog to toggle the trees, you'll also need to edit gui/dialogs/rendering.xml and comment out line 200 to 202: !--enable property/sim/rendering/shader-effects/property /enable-- The Material Shaders options was meant (as far as I understand it) to disable all shader stuff with a single click. When the checkbox is checked, one an finetune what shaders need to be enabled, via the other checkboxes. The problem right now is that some of the shaders (eg. the reflection stuff and lightmap) only depend on that single Material Shaders property. It would be better if every single shader can be en/disabled via its own property/checkbox. But then we might end up with a pretty large rendering dialog... Cheers, Gijs -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders vs. frame rate;
HB-GRAL wrote: We count 33 vertex shader, 31 fragment shaders, 2 geometry shaders and 117 effects files using this and that. This probably has a noticable impact. Does anyone know how to have the random trees without all this ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders vs. frame rate;
Hi all! Martin wrote: Does anyone know how to have the random trees without all this ? In Effects/trees.eff, comment out/remove line 23. !--property/sim/rendering/shader-effects/property-- If you would like to use the dialog to toggle the trees, you'll also need to edit gui/dialogs/rendering.xml and comment out line 200 to 202: !--enable property/sim/rendering/shader-effects/property /enable-- The Material Shaders options was meant (as far as I understand it) to disable all shader stuff with a single click. When the checkbox is checked, one an finetune what shaders need to be enabled, via the other checkboxes. The problem right now is that some of the shaders (eg. the reflection stuff and lightmap) only depend on that single Material Shaders property. It would be better if every single shader can be en/disabled via its own property/checkbox. But then we might end up with a pretty large rendering dialog... Cheers, Gijs -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders vs. frame rate;
On 20.11.2011 11:52, Gijs de Rooy wrote: The problem right now is that some of the shaders (eg. the reflection stuff and lightmap) only depend on that single Material Shaders property. It would be better if every single shader can be en/disabled via its own property/checkbox. But then we might end up with a pretty large rendering dialog... I already find the current dialog a bit overloaded. But how about creating an advanced, separate dialog which lists all the shaders and provides a checkbox for each? And all shaders should be modified to check the main switch (/sim/rendering/shader-effects) plus at least one additional switch property? MIght also be a good idea to structure the shader switches a bit and move them to a separate place, i.e. /sim/rendering/shaders/enable (main switch) /sim/rendering/shaders/forrest-effect /sim/rendering/shaders/water-effect /sim/rendering/shaders/reflection-effect /sim/rendering/shaders/skydome-effect ... Seems like anyone with an ASCII editor could help on this one. More ideas? Volunteers? :) cheers, Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders vs. frame rate;
I already find the current dialog a bit overloaded. But how about creating an advanced, separate dialog which lists all the shaders and provides a checkbox for each? And all shaders should be modified to check the main switch (/sim/rendering/shader-effects) plus at least one additional switch property? MIght also be a good idea to structure the shader switches a bit and move them to a separate place, i.e. /sim/rendering/shaders/enable (main switch) /sim/rendering/shaders/forrest-effect /sim/rendering/shaders/water-effect /sim/rendering/shaders/reflection-effect /sim/rendering/shaders/skydome-effect ... Seems like anyone with an ASCII editor could help on this one. More ideas? Volunteers? :) Good idea! I can make a merge request for that, so we can get some feedback before pushing it up. Will ask Vivian/Emillian on IRC about their shader-updates, as I don't want to interfer with that ;) -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders vs. frame rate;
On Sun, 20 Nov 2011, ThorstenB wrote: I already find the current dialog a bit overloaded. But how about creating an advanced, separate dialog which lists all the shaders and provides a checkbox for each? And all shaders should be modified to check the main switch (/sim/rendering/shader-effects) plus at least one additional switch property? MIght also be a good idea to structure the shader switches a bit and move them to a separate place, i.e. /sim/rendering/shaders/enable (main switch) /sim/rendering/shaders/forrest-effect /sim/rendering/shaders/water-effect /sim/rendering/shaders/reflection-effect /sim/rendering/shaders/skydome-effect ... Seems like anyone with an ASCII editor could help on this one. More ideas? Volunteers? :) Since some effects may be aircraft specific it might be useful to make the advanced dialog dynamic - one way would be to add a checkbox for each *-effect property found in /sim/rendering/shaders/ . Potentially scenery objects or MP aircraft might load some new effects (general or not) so the set of control properties might change (grow) at runtime. Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders vs. frame rate;
Hi Gijs, thanks for elaborating the details ! Gijs de Rooy wrote: But then we might end up with a pretty large rendering dialog... Well, having one where most of the available checkboxes are making just a minor difference compared to the single, big Material shaders switch isn't much better, I'd say ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders vs. frame rate;
Martin wrote: Well, having one where most of the available checkboxes are making just a minor difference compared to the single, big Material shaders switch isn't much better, I'd say ;-) Agree. But do note that 3D clouds is also disabled when disabling Material shaders. For me, 3D clouds and trees have much more impact than anything else. Over TNCM, just enabling 3D clouds and trees (and anything else disabled, apart from material shaders of course) my FPS jumps down from 175 to 100. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders vs. frame rate;
-Original Message- From: Martin Spott Sent: Sunday, November 20, 2011 1:00 PM Newsgroups: list.flightgear-devel To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Shaders vs. frame rate; Hi Gijs, thanks for elaborating the details ! Gijs de Rooy wrote: But then we might end up with a pretty large rendering dialog... Well, having one where most of the available checkboxes are making just a minor difference compared to the single, big Material shaders switch isn't much better, I'd say ;-) --- Could a tree-structure, grouping related textures, for the dialog be used to handle this possibility? Just a thought. Alan -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders vs. frame rate;
Gijs de Rooy wrote: Martin wrote: Well, having one where most of the available checkboxes are making just a minor difference compared to the single, big Material shaders switch isn't much better, I'd say ;-) Agree. But do note that 3D clouds is also disabled when disabling Material shaders. That's fine with me ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders vs. frame rate;
Thank you! I haven't had seen trees in FlightGear for ages (can't run with shaders). I didn't realize the trees were supported at all without shaders. Could that fix be applied automatically so the trees are visible whether shaders are on or off? Gary On Sun, Nov 20, 2011 at 5:52 AM, Gijs de Rooy gijsr...@hotmail.com wrote: Hi all! Martin wrote: Does anyone know how to have the random trees without all this ? In Effects/trees.eff, comment out/remove line 23. !--property/sim/rendering/shader-effects/property-- If you would like to use the dialog to toggle the trees, you'll also need to edit gui/dialogs/rendering.xml and comment out line 200 to 202: !--enable property/sim/rendering/shader-effects/property /enable-- The Material Shaders options was meant (as far as I understand it) to disable all shader stuff with a single click. When the checkbox is checked, one an finetune what shaders need to be enabled, via the other checkboxes. The problem right now is that some of the shaders (eg. the reflection stuff and lightmap) only depend on that single Material Shaders property. It would be better if every single shader can be en/disabled via its own property/checkbox. But then we might end up with a pretty large rendering dialog... Cheers, Gijs -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders vs. frame rate; Was: Fixing fgfs-construct crashes
Am 16.11.11 10:58, schrieb Martin Spott: I was annoyed by the fact that the simple act of just enabling Material shaders in the Rendering options has a noticeable effect on the rendering performance without_any_ of the other features in the entire dialogue box enabled. We count 33 vertex shader, 31 fragment shaders, 2 geometry shaders and 117 effects files using this and that. This probably has a noticable impact. But me, I have no clue what one will enable with this checkboxes. I.e. does AI traffic models use shaders too ? Maybe it will be helpful once to make a human readable list, also for future GUI development, and analyze which shader/effect would be activated with what step. Must say, really interesting question what is enabled with Material shaders. Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Shaders and ATI Radeon HD 4670
Hi all, I cannot use material shaders on my iMac (late 2009 model) equipped with an ATI graphics card (ATI Radeon HD 4670 256 MB VRAM). I only get a few fps standing on ground at an isolated airfield. There is almost no objects. Every 10 times I get 60 fps in cockpit view with no changes except restarting flightgear. Toggling through different view gives different frame rates where the tower views always gives around 60 fps and the others give 2-5 fps (except the occasional 60 fps I get in the cockpit view). In cases when I get 60 fps in cockpit view my computer maintains 60 fps with 3D clouds and skydome scattering turned on. The frame rate is stable even flying through the magnificently rendered clouds. If I turn of material shaders I always get 60 fps in all different views. (Is 60 fps a maximum reading, I never seem to get higher readings?) On my Macbook Pro (early 2008) model, I always get 60 fps staying away from the 3D clouds but the frame rate drops to 20 fps when I fly through clouds. The MBP has a GeForce 8600M GT 256 MB VRAM. The test on my iMac was done on yesterdays source from the various repositories and everything is compiled with -g -O3 (-O2 gives the same numbers). I have also tested a couple of Tat's git snapshots from the macflightgear site and they give similar negative shader effect. I read through many posts on flightgear and shaders on the web but nothing has resolved my issue. Is the above a flightgear issues or is it my hardware? I haven't noticed anything strange with my iMac and Apples extended hardware test does not report anything. Cheers, Jari -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and ATI Radeon HD 4670
Jari I cannot use material shaders on my iMac (late 2009 model) equipped with an ATI graphics card (ATI Radeon HD 4670 256 MB VRAM). I only get a few fps standing on ground at an isolated airfield. There is almost no objects. Every 10 times I get 60 fps in cockpit view with no changes except restarting flightgear. Toggling through different view gives different frame rates where the tower views always gives around 60 fps and the others give 2-5 fps (except the occasional 60 fps I get in the cockpit view). In cases when I get 60 fps in cockpit view my computer maintains 60 fps with 3D clouds and skydome scattering turned on. The frame rate is stable even flying through the magnificently rendered clouds. If I turn of material shaders I always get 60 fps in all different views. (Is 60 fps a maximum reading, I never seem to get higher readings?) On my Macbook Pro (early 2008) model, I always get 60 fps staying away from the 3D clouds but the frame rate drops to 20 fps when I fly through clouds. The MBP has a GeForce 8600M GT 256 MB VRAM. The test on my iMac was done on yesterdays source from the various repositories and everything is compiled with -g -O3 (-O2 gives the same numbers). I have also tested a couple of Tat's git snapshots from the macflightgear site and they give similar negative shader effect. I read through many posts on flightgear and shaders on the web but nothing has resolved my issue. Is the above a flightgear issues or is it my hardware? I haven't noticed anything strange with my iMac and Apples extended hardware test does not report anything. The most _likely_ cause is the ATI Radeon HD 4670/256 MB VRAM. The GeForce 8600M GT is known to be better at handling shaders. 256 Mb VRAM is in both cases a bit small for FG nowadays. There are other possible contributors to a low framerate - AI traffic is one. 60 fps could be a maximum if you are using this option - --prop:/sim/frame-rate-throttle-hz=60 It might well be on by default. Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and ATI Radeon HD 4670
On Sat, 25 Jun 2011, Vivian Meazza wrote: The most _likely_ cause is the ATI Radeon HD 4670/256 MB VRAM. The GeForce 8600M GT is known to be better at handling shaders. 256 Mb VRAM is in both cases a bit small for FG nowadays. There are other possible contributors to a low framerate - AI traffic is one. Wow. That's an incredibly small amount of video RAM for a video card that new. Can you upgrade it to something with more RAM? g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and ATI Radeon HD 4670
On 2011-06-25 17.34, Gene Buckle wrote: On Sat, 25 Jun 2011, Vivian Meazza wrote: The most _likely_ cause is the ATI Radeon HD 4670/256 MB VRAM. The GeForce 8600M GT is known to be better at handling shaders. 256 Mb VRAM is in both cases a bit small for FG nowadays. There are other possible contributors to a low framerate - AI traffic is one. Wow. That's an incredibly small amount of video RAM for a video card that new. Can you upgrade it to something with more RAM? Otherworldcomputing.com has two options; ATI Radeon HD 5670/512MB (USD180) and ATI Radeon HD 5750/1GB (USD400). 400 is a lot, will the cheaper 512MB card make a noticeable difference? And, opening an iMac isn't for the faint-hearted. Jari -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and ATI Radeon HD 4670
On 2011-06-25 16.06, Vivian Meazza wrote: The most _likely_ cause is the ATI Radeon HD 4670/256 MB VRAM. The GeForce 8600M GT is known to be better at handling shaders. 256 Mb VRAM is in both cases a bit small for FG nowadays. There are other possible contributors to a low framerate - AI traffic is one. 60 fps could be a maximum if you are using this option - --prop:/sim/frame-rate-throttle-hz=60 It might well be on by default. I am not using the frame-rate-throttle option but I tried it with a lower limit. This will naturally decrease the frame rate so it seems like 60 is a limiting number. I have to decide if the 3D clouds are worth a graphics card upgrade. Thanks for the response. Jari -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and ATI Radeon HD 4670
Am 25.06.11 17:59, schrieb Jari Häkkinen: Otherworldcomputing.com has two options; ATI Radeon HD 5670/512MB (USD180) and ATI Radeon HD 5750/1GB (USD400). 400 is a lot, will the cheaper 512MB card make a noticeable difference? And, opening an iMac isn't for the faint-hearted. Jari Hi Jari I have a ATI Radeon 5750 with 1 GB and the only difference is that (still remaining) shader issues on OSX with ATI are rendered faster. Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and ATI Radeon HD 4670
On Saturday, June 25, 2011 09:04:30 AM Jari Häkkinen wrote: On 2011-06-25 16.06, Vivian Meazza wrote: The most _likely_ cause is the ATI Radeon HD 4670/256 MB VRAM. The GeForce 8600M GT is known to be better at handling shaders. 256 Mb VRAM is in both cases a bit small for FG nowadays. There are other possible contributors to a low framerate - AI traffic is one. 60 fps could be a maximum if you are using this option - --prop:/sim/frame-rate-throttle-hz=60 It might well be on by default. I am not using the frame-rate-throttle option but I tried it with a lower limit. This will naturally decrease the frame rate so it seems like 60 is a limiting number. I have to decide if the 3D clouds are worth a graphics card upgrade. Thanks for the response. Jari The 60 FPM limit is probably because the diver is syncing to the vblank signal from the monitor. For most LCD type monitors with will either be 60Hz or 120Hz. For the nvidia X11 drivers you can turn sync to vblank on and off. I generally have mine on since there is no reason to have the video card produce a frame rate higher than the monitor refresh rate. I don't know if this is configurable in the OS/X video drivers. Hal --- --- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Shaders: Issue 294 not accepted?
Hi all For upcoming debugging weeks: Please note that issue #294 and #335 are still valid here with OSX 10.6, ATI 5750, OSG2.9.7. I still get Warning: detected OpenGL error 'invalid operation' at after RenderBin::draw(..) with every plane (i.e. 737-100) where reflect shaders are active. I don’t know how to get better debugging information with fgfs, and I apologize, can someone give me a hint again how I can get human readable error output instead of tousands of this lines above, filling up my log, pointing to nowhere ? Now all what I can say is what my shader builder on OSX says for reflect and reflect-bum-spec: --- Validation Failed: Sampler error: Samplers of different types use the same texture image unit. - or - A sampler's texture unit is out of range (greater than max allowed or negative). --- Another validation warning with reflect-bump-spec, but this needs only some small shader clean up I think ;-) --- Program link results: WARNING: vertex shader writes varying 'Normal' which is not active. --- NONE of the other shaders have problems with passing an external shader validation. Please accept the issue #294 for OSX/ATI now and assign it to shader core developers if he/she is still around. (I will try to help to fix it of course). btw. using 777-200 (see also issue #335) gives me: --- FRAGMENT glCompileShader FAILED FRAGMENT Shader infolog: ERROR: 0:58: '=' : wrong operand types no operation '=' exists that takes a left-hand operand of type 'uniform float' and a right operand of type 'const int' (or there is no acceptable conversion) glLinkProgram FAILED Program infolog: ERROR: One or more attached shaders not successfully compiled --- I will vote for removing all the shaders in aircrafts soon :-) Thanks, Yves -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders flicker
On Wed, 20 Apr 2011 02:39:42 +0200, Robert wrote in message BANLkTi=osyhxkaoky-c8pa71sqk1t3p...@mail.gmail.com: 2011/4/20 Robert dogg...@googlemail.com here is a screenshot: http://img251.imageshack.us/i/fgfsscreen077.png/ ..hum, bright white nose, external screen shots? If you ask me it looks pretty much like z-fighting artefacts. Maybe a shader that doesnt account for near and far frustum? I had to fly pretty low to cause this flickering. ..could be it takes a system load to provoke this, try pile up a bunch of web browser tabs with e.g. flash movies to eat away resources we normally want to keep for FG and see what happens. Also there is a flickering problem with panel instruments and cockpit itself, ..that's easily a 2'nd issue. ;o) But in about 300 screenshots I couldn't catch this issue because it lasts only a few frames and I don't have the reaction time of a machine :) ..piling up loads, helps. I think a video would be better to record the flickering on the cockpit-panel. ..agreed ;o), url? -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders flicker
On Tue, 19 Apr 2011 04:13:45 +0200, Robert wrote in message banlktim5dkxvgxyh5owvjwrcv23odt6...@mail.gmail.com: I also have the flickering issue with shaders on. ..white flickering? (ATI/AMD, ..which ATI/AMD? Debian, ..which Debian, Squeeze? fglrx) ..url to screenshots? ..try the radeon and radeonhd too, they may be different and I wanna see _how_ they are different. On my system the problem occurs at low framerates (30-35 fps) caused by the scenery. On lighter airports I get 60-75 fps and the problem seems to be gone. ..a WAG is you run your graphics card too hard, try throttle it at e.g. 30fps, so it _has_ time to draw every frame. I hit that one trying to draw 59.something fps of 2048x1536x24bpp on a 9250 (or a 9800?) AFAIR, backing off to 58.8fps with a new modeline, fixed my white flickering, it needed a few more milliseconds to color each frame properly. David, maybe someone of us should file a bug report here: http://code.google.com/p/flightgear-bugs/issues/list ..done, #264@ http://code.google.com/p/flightgear-bugs/issues/detail?id=264 -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders flicker
here is a screenshot: http://img251.imageshack.us/i/fgfsscreen077.png/ If you ask me it looks pretty much like z-fighting artefacts. Maybe a shader that doesnt account for near and far frustum? -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders flicker
I had to fly pretty low to cause this flickering. Also there is a flickering problem with panel instruments and cockpit itself, But in about 300 screenshots I couldn't catch this issue because it lasts only a few frames and I don't have the reaction time of a machine :) I think a video would be better to record the flickering on the cockpit-panel. 2011/4/20 Robert dogg...@googlemail.com here is a screenshot: http://img251.imageshack.us/i/fgfsscreen077.png/ If you ask me it looks pretty much like z-fighting artefacts. Maybe a shader that doesnt account for near and far frustum? -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Shaders flicker
Hi developers, I have a new computer, installed FG on it and have a problem with the graphics. The problem (beside missing runway lights) is that surfaces generated by a shader will flicker. This applies to terrain and aircraft instruments, trees and the Crop texture however do not flicker. The flicker disapears when I switch off Material shaders in the Rendering menu. It seems not to appear everywhere, but only if custom scenery is near. When I tested today, it didn't happen at airports which do not have any buildings. You find screenshots here: http://www.flightgear.org/forums/viewtopic.php?f=37t=11686. I would appreciate any help. Cheers David -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders flicker
David Glowsky wrote: Hi developers, I have a new computer, installed FG on it and have a problem with the graphics. The problem (beside missing runway lights) is that surfaces generated by a shader will flicker. This applies to terrain and aircraft Moin David, while I have no solution for the main problem, the following patch (kudos to Jester) helps here on my ATI to let runway lights shine as expected: http://git.overlays.gentoo.org/gitweb/?p=proj/gamerlay.git;a=blob;f=dev- games/simgear/files/simgear-radeon-fix-runway- lights.patch;h=a48c4bf62cd52ffe7f1c2c71dbb8f95ac41fbb09;hb=HEAD Chris -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders flicker
On Mon, 18 Apr 2011 19:56:38 +0200, David wrote in message banlktimbxl03ofww5qsvqoygszwybhs...@mail.gmail.com: Hi developers, I have a new computer, installed FG on it and have a problem with the graphics. The problem (beside missing runway lights) is that surfaces generated by a shader will flicker. This applies to terrain and aircraft instruments, trees and the Crop texture however do not flicker. The flicker disapears when I switch off Material shaders in the Rendering menu. It seems not to appear everywhere, but only if custom scenery is near. When I tested today, it didn't happen at airports which do not have any buildings. You find screenshots here: http://www.flightgear.org/forums/viewtopic.php?f=37t=11686. ..first, try take the same screenshots with today's fg-git, the shaders _may_ have been fixed since you shot your shots. I would appreciate any help. ..I suspect FG shader bugs not properly supporting ATI hardware, most if not all FG developers have Nvidea graphics on closed source nvidea drivers and noton GPL nouveau, a quick test can be done with Knoppix: http://nouveau.freedesktop.org/wiki/ http://knopper.net/knoppix/knoppix64-en.html ..I'd like to see what happen when you do exactly the same things in FG as you did here, but running your box on Knoppix and installing the same FG in your Knoppix session. http://knopper.net/knoppix/index-en.html http://knopper.net/knoppix/knoppix64-en.html ..if you don't wanna touch your disks, run Knoppix in ramdisk and install the same version FG into your ramdisk session and then try take the same screenshots as you did on Wintendo and ATI's drivers. (Usb sticks and SD etc flash cards are other possible options.) ..boot it with 'knoppix toram ' and see what happens, if that fails to do what we want, try e.g. 'knoppix toram xmodule=ati ', more ideas to try append to the boot command: ftp://ftp.uni-kl.de/pub/linux/knoppix/knoppix-cheatcodes.txt ..xmodule's I'd like to see compared, is radeon, radeonhd, and ATI's own fglrx, and on Nvidea's, nvidea and nouveau. ..note that you _may_ have to use knoppix64 to boot a 64bit kernel on a 64bit cpu, and knoppix32 or somesuch to boot a 32bit kernel on 32bit cpus, I'm not up to date on current knoppix boot cheatcodes. _Play_around_. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders flicker
I also have the flickering issue with shaders on. (ATI/AMD, Debian, fglrx) On my system the problem occurs at low framerates (30-35 fps) caused by the scenery. On lighter airports I get 60-75 fps and the problem seems to be gone. David, maybe someone of us should file a bug report here: http://code.google.com/p/flightgear-bugs/issues/list -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Shaders
Hi all Can someone point me to the history of latest changes to the default shaders? I am running a ATI 5750 now with 1 GB VRAM and get = 20 fps at default KSFO, like the last three years with much older ATI. What happened, I can’t believe. Coming back after some months and looking to the development in the shaders I am a bit disappointed, I spent a lot of work last year to get the shaders working for ATI/OSX. The quality level takes no effect to the framerate, 3d clouds are superb and takes no effect, there must be something wrong again with default shaders. What changes have been introduced here ? And can someone point me a git header where fundamental changes were (re-)made, so I dont have to go thru the whole file history ? Thanks a lot, Yves -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders
On Mon, 2011-03-21 at 08:50 +0100, HB-GRAL wrote: Hi all Can someone point me to the history of latest changes to the default shaders? I am running a ATI 5750 now with 1 GB VRAM and get = 20 fps at default KSFO, like the last three years with much older ATI. What happened, I can’t believe. Coming back after some months and looking to the development in the shaders I am a bit disappointed, I spent a lot of work last year to get the shaders working for ATI/OSX. The quality level takes no effect to the framerate, 3d clouds are superb and takes no effect, there must be something wrong again with default shaders. What changes have been introduced here ? And can someone point me a git header where fundamental changes were (re-)made, so I dont have to go thru the whole file history ? The (new) urban shader brings my system to it's knees and the fallback option to the old urban shader has no effect (I get plain white areas instead of an urban shader). I would start to look there if I where you. Erik -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders
I am running fgfs git a hd5850 on win7... Did a quick check since I did not fly ksfo for a long time. With all shaders applied I get around 38 to 60 fps depending on how much mp players are there. (fair weather) Enabling or disabling the shaders gives a gain of 3fps. Oliver -Ursprüngliche Nachricht- Von: HB-GRAL [mailto:flightg...@sablonier.ch] Gesendet: Montag, 21. März 2011 08:51 An: FlightGear developers discussions Betreff: [Flightgear-devel] Shaders Hi all Can someone point me to the history of latest changes to the default shaders? I am running a ATI 5750 now with 1 GB VRAM and get = 20 fps at default KSFO, like the last three years with much older ATI. What happened, I cant believe. Coming back after some months and looking to the development in the shaders I am a bit disappointed, I spent a lot of work last year to get the shaders working for ATI/OSX. The quality level takes no effect to the framerate, 3d clouds are superb and takes no effect, there must be something wrong again with default shaders. What changes have been introduced here ? And can someone point me a git header where fundamental changes were (re-)made, so I dont have to go thru the whole file history ? Thanks a lot, Yves -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders
Hi, @HB-GRAL: Have you downloaded FGFS or compiled it yourself? If you compile yourself, please also build a non-debug version which means, use optimization, maybe -O3 is the trick. I use these parameters to build FGFS and SG: export CFLAGS=-g -O3 -fPIC export CXXFLAGS=-g -O3 -fPIC Regard, Roland On Mon, 2011-03-21 at 23:16 +0100, Oliver Thurau wrote: I am running fgfs git a hd5850 on win7... Did a quick check since I did not fly ksfo for a long time. With all shaders applied I get around 38 to 60 fps depending on how much mp players are there. (fair weather) Enabling or disabling the shaders gives a gain of 3fps. Oliver -Ursprüngliche Nachricht- Von: HB-GRAL [mailto:flightg...@sablonier.ch] Gesendet: Montag, 21. März 2011 08:51 An: FlightGear developers discussions Betreff: [Flightgear-devel] Shaders Hi all Can someone point me to the history of latest changes to the default shaders? I am running a ATI 5750 now with 1 GB VRAM and get = 20 fps at default KSFO, like the last three years with much older ATI. What happened, I cant believe. Coming back after some months and looking to the development in the shaders I am a bit disappointed, I spent a lot of work last year to get the shaders working for ATI/OSX. The quality level takes no effect to the framerate, 3d clouds are superb and takes no effect, there must be something wrong again with default shaders. What changes have been introduced here ? And can someone point me a git header where fundamental changes were (re-)made, so I dont have to go thru the whole file history ? Thanks a lot, Yves -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel signature.asc Description: This is a digitally signed message part -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders
Am 21.03.11 23:23, schrieb Roland Häder: Hi, @HB-GRAL: Have you downloaded FGFS or compiled it yourself? If you compile yourself, please also build a non-debug version which means, use optimization, maybe -O3 is the trick. I use these parameters to build FGFS and SG: export CFLAGS=-g -O3 -fPIC export CXXFLAGS=-g -O3 -fPIC Thanks Roland, I use some optimization already. But I did a very bad, bad mistake the last two days, I compiled OSG with wrong windowing system and other bad things (just in case: it is also working, but you will get probably all the issues I posted the last two days). Hmpf! Sorry for that. All my problems have gone now. I got the cursors back, the shaders works as expected. I get a frame rate of 40 fps with all shaders enabled and quality level 4 at KSFO. Now I need some courage to fly with this rate of course. And beside that I am also trying to build a new version for built-in fgfs for my new OSX FlightGear launcher. Thanks for all the hints and support, Yves -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders
Hi, All my problems have gone now. I got the cursors back, the shaders works as expected. I get a frame rate of 40 fps with all shaders enabled and quality level 4 at KSFO. Now I need some courage to fly with this rate of course. Good to hear that. Also you don't need optimization in e.g. OSG which would cost you a lot FPS. You only need -O0 if you debug OSG or any other lib. In general words: Use -O3 for fgfs/simgear/OSG for best FPS, -g or -fPIC doesn't hurt your performance but it (-g) helps developers with a nicer backtrace. If the crash happens with the optimized version of FGFS, try to reproduce it with an unoptimized (-O0) build (called debug build) because optimization does optimize out variable values (please ask C/C++ developers for in-depth information) to speed-up things but these variable values are very often required for devs to pin-down bugs. So for short: - Play with optimized builds for best gaming experiences (much higher FPS) - If a crash happens fire the debug build up (with all command-line parameters again) with the GNU debugger and try to reproduce it. - If you were able to reproduce it, show your findings (e.g. 'bt full') to this list - Recommend way to post backtraces is to use pastebins because else they would make this mailing list unusable Regards, Roland PS: I have no ATI, but a GeForce 9500 GT here, with optimized build I got FPS ~30-40 at KSGFO and even at EDDF with GlobalObjects installed. And beside that I am also trying to build a new version for built-in fgfs for my new OSX FlightGear launcher. Thanks for all the hints and support, Yves -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel signature.asc Description: This is a digitally signed message part -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders heads up
Am 28.08.10 12:34, schrieb HB-GRAL:
Am 28.08.10 01:16, schrieb Tim Moore:
There needs to be some coordinate for the fog. You could try using
gl_FogFragCoord instead.
Tim
Thanks for your answer Tim. And what should happen when I change
gl_BackColor.a from 0.0 to 1.0 in default.vert? I see here that this
makes the terrain shaders (or the light) running at least for some older
ATI cards (and .z/.w is def. not the problem).
What do I loose with this change? What do I have to check? And could
this work for terrain also for other cards with gl_BackColor.a = 1.0?
Thanks, Yves
Ok, I can keep all the new code now with my older ATI. For my card I
only had to add 'if (gl_BackColor == 0.0) { n = -n; }' again in
default.frag and that seems finally to work with recent changes. Maybe
this makes not a lot of sense, but I do not care anymore ;-)
-Yves
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders heads up
Am 28.08.10 01:16, schrieb Tim Moore: There needs to be some coordinate for the fog. You could try using gl_FogFragCoord instead. Tim Thanks for your answer Tim. And what should happen when I change gl_BackColor.a from 0.0 to 1.0 in default.vert? I see here that this makes the terrain shaders (or the light) running at least for some older ATI cards (and .z/.w is def. not the problem). What do I loose with this change? What do I have to check? And could this work for terrain also for other cards with gl_BackColor.a = 1.0? Thanks, Yves -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders heads up
There needs to be some coordinate for the fog. You could try using gl_FogFragCoord instead. Tim On Wed, Aug 25, 2010 at 1:00 AM, HB-GRAL flightg...@sablonier.ch wrote: Am 24.08.10 23:58, schrieb HB-GRAL: Am 24.08.10 23:44, schrieb HB-GRAL: Am 14.08.10 00:20, schrieb Tim Moore: Let me know of any new problems. Tim A new problem is the last line in default.vert: fogCoord = abs(ecPosition.z / ecPosition.w); For what is this needed exactly? It kills the light or light direction here with only default shaders enabled. Really nobody else encountering such problems? I am wondering. I will give my card to a museum once. Thanks, Yves Just to add: I commented this line out and at least terrain seems to work fine. But the question remains, for what is this needed in the hack? It produce a known ATI issue, so I am going from one issue to the next (from gl_FrontFacing to .z/.w). Cheers, Yves Sorry, wrong. It does not work fine, it just breaks the terrain-default shader, and thats why it looks good and I didn’t see the new problem ;-) - Yves -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders heads up
Am 14.08.10 00:20, schrieb Tim Moore: Let me know of any new problems. Tim A new problem is the last line in default.vert: fogCoord = abs(ecPosition.z / ecPosition.w); For what is this needed exactly? It kills the light or light direction here with only default shaders enabled. Really nobody else encountering such problems? I am wondering. I will give my card to a museum once. Thanks, Yves -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders heads up
- HB-GRAL flightg...@sablonier.ch a écrit : Am 14.08.10 00:20, schrieb Tim Moore: Let me know of any new problems. Tim A new problem is the last line in default.vert: fogCoord = abs(ecPosition.z / ecPosition.w); For what is this needed exactly? It kills the light or light direction here with only default shaders enabled. Really nobody else encountering such problems? I am wondering. I will give my card to a museum once. Maybe you have ecPosition.w set to zero and the shader won't go past this point ? Normally, w is set to 1 but other, not null for a point, values are allowed. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders heads up
Am 24.08.10 23:44, schrieb HB-GRAL: Am 14.08.10 00:20, schrieb Tim Moore: Let me know of any new problems. Tim A new problem is the last line in default.vert: fogCoord = abs(ecPosition.z / ecPosition.w); For what is this needed exactly? It kills the light or light direction here with only default shaders enabled. Really nobody else encountering such problems? I am wondering. I will give my card to a museum once. Thanks, Yves Just to add: I commented this line out and at least terrain seems to work fine. But the question remains, for what is this needed in the hack? It produce a known ATI issue, so I am going from one issue to the next (from gl_FrontFacing to .z/.w). Cheers, Yves -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders heads up
Am 24.08.10 23:58, schrieb HB-GRAL: Am 24.08.10 23:44, schrieb HB-GRAL: Am 14.08.10 00:20, schrieb Tim Moore: Let me know of any new problems. Tim A new problem is the last line in default.vert: fogCoord = abs(ecPosition.z / ecPosition.w); For what is this needed exactly? It kills the light or light direction here with only default shaders enabled. Really nobody else encountering such problems? I am wondering. I will give my card to a museum once. Thanks, Yves Just to add: I commented this line out and at least terrain seems to work fine. But the question remains, for what is this needed in the hack? It produce a known ATI issue, so I am going from one issue to the next (from gl_FrontFacing to .z/.w). Cheers, Yves Sorry, wrong. It does not work fine, it just breaks the terrain-default shader, and thats why it looks good and I didn’t see the new problem ;-) - Yves -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders: implicit cast in function parameters causes fatal error
Hi Tat, - Tatsuhiro Nishioka a écrit : Hi there, First of all, I'm back to FlightGear after a bit longer vacation :-) I'm very happy that I released a fg-git for Mac OS, but immediately after that, a user gave me a bug report. X-) The core problem is that an implicit cast (especially from int to double or float) in shader code leads some nVidia drivers a fatal error: (0) : fatal error C: can't find pow function in stdlib Cg compiler terminated due to fatal error In his case, this happened when he was adjusting Performance vs Quality slider. So I grep pow in Shaders and found that urban.vert has this line: emission_factor *= 0.5*pow(tc.r+0.8*tc.g+0.2*tc.b, 2) -0.2; I changed 2 to 2.0 and the error went out. This, I believe, is a problem in some of nVidia drivers since it doesn't happen on my Macs, but it's safer not to use implicit cast in function calls. so please check your shader code and eliminate such implicit casts. This is fixed now. Thanks for reporting -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders: implicit cast in function parameters causes fatal error
Hi Fred, Thanks for the quick fix. I really appreciate it! Tat On Aug 23, 2010, at 3:55 PM, Frederic Bouvier wrote: Hi Tat, - Tatsuhiro Nishioka a écrit : The core problem is that an implicit cast (especially from int to double or float) in shader code leads some nVidia drivers a fatal error: (0) : fatal error C: can't find pow function in stdlib Cg compiler terminated due to fatal error (snip) This is fixed now. Thanks for reporting -Fred -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders: implicit cast in function parameters causes fatal error
- Tatsuhiro Nishioka a écrit : Hi Fred, Thanks for the quick fix. I really appreciate it! Tat You're welcome, you did all the diagnostic work. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Shaders: implicit cast in function parameters causes fatal error
Hi there, First of all, I'm back to FlightGear after a bit longer vacation :-) I'm very happy that I released a fg-git for Mac OS, but immediately after that, a user gave me a bug report. X-) The core problem is that an implicit cast (especially from int to double or float) in shader code leads some nVidia drivers a fatal error: (0) : fatal error C: can't find pow function in stdlib Cg compiler terminated due to fatal error In his case, this happened when he was adjusting Performance vs Quality slider. So I grep pow in Shaders and found that urban.vert has this line: emission_factor *= 0.5*pow(tc.r+0.8*tc.g+0.2*tc.b, 2) -0.2; I changed 2 to 2.0 and the error went out. This, I believe, is a problem in some of nVidia drivers since it doesn't happen on my Macs, but it's safer not to use implicit cast in function calls. so please check your shader code and eliminate such implicit casts. Best, Tat --- Tatsuhiro Nishioka http://macflightgear.sourceforge.net/ -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders heads up
HB-GRAL schrieb: Hi Tim Maybe I am the only one once again but I have some issues here: - Without shader it seems terrain works fine ;-) - When I activate 'Material Shaders' all the terrain becomes -30% darker - When I add 'Landmass shader' some of the terrain becomes normal brightness (where the landmass shader is involved in material.xml) - When I add 'Crop Shader' the crop becomes normal brightness - There is no snow on terrain where crop effect is activated (or snowlevel is not changed?) What can I do to get the brighter terrain back here when I activate Material Shaders only? Thanks, Yves I got all back with deleting some 'nonsense' (not my words) in terrain-default.eff with render-bin numbers (render-bin '-1' brings all the darkness here). I promise I do not try to talk about this small change, because it seems like it does only affect me, my card and myself. Cheers, Yves -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders heads up
Hi Yves, - HB-GRAL a écrit : Tim Moore schrieb: I've checked in some changes to the shaders in attempt to fix bugs on some platforms and generally optimize them. I've eliminated the use of gl_FrontFacing, which seems to give us problems on certain Macintosh platforms. I've also reworked the way material animations are handled. Let me know of any new problems. Tim Hi Tim Maybe I am the only one once again but I have some issues here: - Without shader it seems terrain works fine ;-) - When I activate 'Material Shaders' all the terrain becomes -30% darker - When I add 'Landmass shader' some of the terrain becomes normal brightness (where the landmass shader is involved in material.xml) - When I add 'Crop Shader' the crop becomes normal brightness - There is no snow on terrain where crop effect is activated (or snowlevel is not changed?) What can I do to get the brighter terrain back here when I activate Material Shaders only? It means the terrain-default effect has a problem for you. I can't see a difference between no shader at all and just the default shader. The crop shader has its snow level hardwired to 2000m and it is so from the beginning. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders heads up
On Wed, 2010-08-18 at 02:10 +0200, HB-GRAL wrote: Hi Tim Maybe I am the only one once again but I have some issues here: - Without shader it seems terrain works fine ;-) - When I activate 'Material Shaders' all the terrain becomes -30% darker - When I add 'Landmass shader' some of the terrain becomes normal brightness (where the landmass shader is involved in material.xml) - When I add 'Crop Shader' the crop becomes normal brightness - There is no snow on terrain where crop effect is activated (or snowlevel is not changed?) What can I do to get the brighter terrain back here when I activate Material Shaders only? I get the same and has something to do with the maximum allowed number of varying parameters supported by the hardware. There is a fix that didn't seem to affect anything on my side: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27751.html Erik -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders heads up
Frederic Bouvier schrieb: The crop shader has its snow level hardwired to 2000m and it is so from the beginning. -Fred Hi Fred What is the reason for this I miss? I mean, this is not so nice having a slider to get snow below 2000 meters and then you get it only on parts of the terrain. This looks like heated croplands here in case of snow ;-) Cheers, Yves -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders heads up
Erik Hofman schrieb: I get the same and has something to do with the maximum allowed number of varying parameters supported by the hardware. There is a fix that didn't seem to affect anything on my side: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27751.html Erik Thanks Erik, but I do not see any varyings I can remove at the moment with recent changes. And I fear the varyings are not the only problem I have here. I get the light back everywhere the landmass and the crop shader is used in materials.xml. Why does the landmass shader gives me the light back but new terrain-nocolor not? What is the reason to have three overlapping(?) defaults with - default.frag - terrain-default.frag - terrain-nocolor.frag what actually gives no light on terrain here, and why - landmass.frag - crop.frag gives it back, once activated? I tried to find the matter yesterday for some hours but the structure of the shaders becomes a bit more complicated at the moment. Thanks again, Yves -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders heads up
- HB-GRAL flightg...@sablonier.ch a écrit : Frederic Bouvier schrieb: The crop shader has its snow level hardwired to 2000m and it is so from the beginning. -Fred Hi Fred What is the reason for this I miss? I mean, this is not so nice having a slider to get snow below 2000 meters and then you get it only on parts of the terrain. This looks like heated croplands here in case of snow ;-) Why do you think bugs or missing features exist ;-) -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders heads up
Frederic Bouvier schrieb: - HB-GRAL flightg...@sablonier.ch a écrit : Frederic Bouvier schrieb: The crop shader has its snow level hardwired to 2000m and it is so from the beginning. -Fred Hi Fred What is the reason for this I miss? I mean, this is not so nice having a slider to get snow below 2000 meters and then you get it only on parts of the terrain. This looks like heated croplands here in case of snow ;-) Why do you think bugs or missing features exist ;-) -Fred I wanted to show you a real image where I have seen exactly such 'heated' croplands in the winter. Too bad I could not find the picture here at the moment. It is a temporary feature I see. Thanks anyway, Yves -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders heads up
- HB-GRAL a écrit : Frederic Bouvier schrieb: - HB-GRAL flightg...@sablonier.ch a écrit : Frederic Bouvier schrieb: The crop shader has its snow level hardwired to 2000m and it is so from the beginning. -Fred Hi Fred What is the reason for this I miss? I mean, this is not so nice having a slider to get snow below 2000 meters and then you get it only on parts of the terrain. This looks like heated croplands here in case of snow ;-) Why do you think bugs or missing features exist ;-) -Fred I wanted to show you a real image where I have seen exactly such 'heated' croplands in the winter. Too bad I could not find the picture here at the moment. It is a temporary feature I see. Thanks anyway, Yves Fly from LFPN and go south. There is a lot of crops in the Paris area. BTW: it's not me that designed this shader nor implemented the slider. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders heads up
Tim Moore schrieb: I've checked in some changes to the shaders in attempt to fix bugs on some platforms and generally optimize them. I've eliminated the use of gl_FrontFacing, which seems to give us problems on certain Macintosh platforms. I've also reworked the way material animations are handled. Let me know of any new problems. Tim Hi Tim Maybe I am the only one once again but I have some issues here: - Without shader it seems terrain works fine ;-) - When I activate 'Material Shaders' all the terrain becomes -30% darker - When I add 'Landmass shader' some of the terrain becomes normal brightness (where the landmass shader is involved in material.xml) - When I add 'Crop Shader' the crop becomes normal brightness - There is no snow on terrain where crop effect is activated (or snowlevel is not changed?) What can I do to get the brighter terrain back here when I activate Material Shaders only? Thanks, Yves -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders heads up
On 13 Aug 2010, at 23:20, Tim Moore wrote: I've checked in some changes to the shaders in attempt to fix bugs on some platforms and generally optimize them. I've eliminated the use of gl_FrontFacing, which seems to give us problems on certain Macintosh platforms. I've also reworked the way material animations are handled. Let me know of any new problems. I already communicated this on IRC, but on Ati+Mac, this is a dramatic improvement for me - for scenery (BTG) heavy scenes, my frame-rate nearly doubled. At an XML+AC heavy location (eg, Gatwick/EGKK) there was still a nice frame-rate boost of 50-70%. Thanks Tim! James -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] shaders heads up
I've checked in some changes to the shaders in attempt to fix bugs on some platforms and generally optimize them. I've eliminated the use of gl_FrontFacing, which seems to give us problems on certain Macintosh platforms. I've also reworked the way material animations are handled. Let me know of any new problems. Tim -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and textures
Frederic Bouvier schrieb: - HB-GRAL a écrit : Is it possible to add (or blend) a texture in the shaders to steep= gray instead of calculating a 'simple colour cloud'? In combination with a texture it probably looks like all the 'perhaps' and is a very nice feature. You can add the rock texture to the effect file as another texture unit and, in the shader, blend it with the base texture when the steepness criterion is met. -Fred Thank you Fred and Vivian. I will give this a try soon. I didn’t see the steepness criterion yet but I will check for it. Hard job for me, but interesting ;-) -Yves -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and textures
- HB-GRAL a écrit : Is it possible to add (or blend) a texture in the shaders to steep= gray instead of calculating a 'simple colour cloud'? In combination with a texture it probably looks like all the 'perhaps' and is a very nice feature. You can add the rock texture to the effect file as another texture unit and, in the shader, blend it with the base texture when the steepness criterion is met. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and textures
On Sat, 2010-08-07 at 01:45 +0200, HB-GRAL wrote: Hi all, I see a lot of improvements with recent shaders. But there comes some renewals I do not how to work with. - Snow: Activating the landmass shaders gives me some snow. Some material is not covered i.e. glacier. And snow is starting by default at 2000 (2000 what?). Is this real i.e. for season 'summer'? And how can I change appearance of this soft-edge 'geometrical' snow fields? The snow border height (above which the snow shader should render snow) is controlled using the rendering dialog box. Since the scenery in FlightGear is using meters I guess it's 2000 meters. - Mystic gray blobs: When I activate landmass shader everywhere there are some 'random' gray blobs now. What is the goal of this blobs? Is it possible to add a texture to this blobs? I haven't seen these.. unless this is also the snow shader. - Crop shader: This is a very interesting shader of course. But when I activate it- only one crop type is covered by this shader. Is the crop shader thought to have multiple crop effects? How can I work with this shader and different textures to get things like irregular crop and many many other crop types like we have in recent landcover? As far as I know the crop shader creates it's own appearance. That's why you can't see any repetitions (which are common when using textures). It's only one type of cover right now. Erik -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and textures
Erik Hofman schrieb: - Mystic gray blobs: When I activate landmass shader everywhere there are some 'random' gray blobs now. What is the goal of this blobs? Is it possible to add a texture to this blobs? I haven't seen these.. unless this is also the snow shader. I get this with recent GIT fgdata. Here is an example from a forum post (picture 1/3/4) http://www.flightgear.org/forums/viewtopic.php?f=5t=8968p=89056#p89056 Here is what I get in the mountains (with own experimental new texture and landmass activated) http://tinyurl.com/377ol2a As far as I know the crop shader creates it's own appearance. That's why you can't see any repetitions (which are common when using textures). It's only one type of cover right now. Erik What stands 'crop.png' in /Textures/Terrain for? Is this ornament not used and repeated? Maybe you can not see the repetition of the texture but from a less mathematical view the cropland looks all the same here when I activate the crop shader. It covers most of the terrain with the same ornament and same colors. From my point of view this is also a bit 'repetitive'. When I want to have more different croplands how should I go further with the crop shader? Building different crop.png’s and cropcolors? How can I alter this textures/ornaments for cropland terrain? And is it also possible to add a relief/normalmap to crop? Thanks- gral -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and textures
HB-GRAL schrieb: When I want to have more different croplands how should I go further with the crop shader? Building different crop.png’s and cropcolors? How can I alter this textures/ornaments for cropland terrain? And is it also possible to add a relief/normalmap to crop? Thanks- gral Sorry for my crop conclusion. I see now how I can change crop texture and 'colormap' to get another look with the shader. Here is test example http://tinyurl.com/2uez5ar The problem with the random blobs still remains. Also the snow level at 2000 meters in the summer and that some textures/landclasses are not covered by snow (like glacier). Thanks, Yves -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and textures
Vivian Meazza schrieb: The grey patches are not snow - they denote steep areas; perhaps rock, or a rock run. They are generated in crop.frag by: //steep = gray c1 = mix(vec4(n-0.42, n-0.44, n-0.51, 1.0), c1, smoothstep(0.970, 0.990, abs(normalize(Normal).z)+nvL[2]*1.3)); //snow c1 = mix(c1, clamp(n+nvL[2]*4.1+vec4(0.1, 0.1, nvL[2]*2.2, 1.0), 0.7, 1.0), smoothstep(snowlevel+300.0, snowlevel+360.0, (rawpos.z)+nvL[1]*3000.0)); not a bug but a feature :-) Vivian p.s. not my code btw Is it possible to add (or blend) a texture in the shaders to steep= gray instead of calculating a 'simple colour cloud'? In combination with a texture it probably looks like all the 'perhaps' and is a very nice feature. Here recent 'steep = gray'-blobs do not look like rock or rock run or something else at the moment - sorry for my misunderstanding. I see that some landmass reliefs are calculated also with snow. So it should be possible to add a texture to the 'steep=grays' or not? Thanks- Yves -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Shaders and textures
Hi all, I see a lot of improvements with recent shaders. But there comes some renewals I do not how to work with. - Snow: Activating the landmass shaders gives me some snow. Some material is not covered i.e. glacier. And snow is starting by default at 2000 (2000 what?). Is this real i.e. for season 'summer'? And how can I change appearance of this soft-edge 'geometrical' snow fields? - Mystic gray blobs: When I activate landmass shader everywhere there are some 'random' gray blobs now. What is the goal of this blobs? Is it possible to add a texture to this blobs? - Crop shader: This is a very interesting shader of course. But when I activate it- only one crop type is covered by this shader. Is the crop shader thought to have multiple crop effects? How can I work with this shader and different textures to get things like irregular crop and many many other crop types like we have in recent landcover? Thanks for your answer, Yves -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
Hi Erik, - Erik Hofman a écrit : Frederic Bouvier wrote: The relief (you mean the height of the buildings) can be adjusted in the effect file. The more important thing to me is to get the right horizontal scale. Nothing will change until the next scenery release because the scale is engraved in the scenery files (as texture coordinates) As far as I know the texture coordinates are normalized, so changing the coverage size in the materials.xml file changes the horizontal scale. As can be seen in the latest version of that file. BTW the heightmap changes accordingly to match the main texture. looking for coverage in the sources, I can't find something related to the texture. As far as I can see, tex coords are computed by sgCalcTexCoords, and this function is called at run time only for ocean tiles. Otherwise, in is called from Terragear, in int TGGenOutput::build( TGConstruct c ) function for terrain except airports. -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
Frederic Bouvier wrote:
looking for coverage in the sources, I can't find something related
to the texture. As far as I can see, tex coords are computed by
sgCalcTexCoords, and this function is called at run time only for
ocean tiles. Otherwise, in is called from Terragear, in
int TGGenOutput::build( TGConstruct c ) function for terrain except
airports.
It's in mat.hxx:
SGVec2f get_tex_coord_scale() const
{
float tex_width = get_xsize();
float tex_height = get_ysize();
return SGVec2f((0 tex_width) ? 1000.0f/tex_width : 1.0f,
(0 tex_height) ? 1000.0f/tex_height : 1.0f);
}
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
Frederic Bouvier wrote: The relief (you mean the height of the buildings) can be adjusted in the effect file. The more important thing to me is to get the right horizontal scale. Nothing will change until the next scenery release because the scale is engraved in the scenery files (as texture coordinates) As far as I know the texture coordinates are normalized, so changing the coverage size in the materials.xml file changes the horizontal scale. As can be seen in the latest version of that file. BTW the heightmap changes accordingly to match the main texture. Erik -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
HB-GRAL wrote: Erik Hofman schrieb: I've changed the coverage size of the textures from 1024 to 2000 meter. Hello Erik I guess it is better not to change the texture size to 2000 meters(?) in materials.xml. As I can see the size of the textures fits exactly to the relief when it is 1024 at the moment. I've already changed it in CVS and the relief/height map is still in line with the main texture. Otherwise I wouldn't have committed it. Erik -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
Erik Hofman schrieb: I've already changed it in CVS and the relief/height map is still in line with the main texture. Otherwise I wouldn't have committed it. Erik Yes, I apologize this is my conclusion with the new effect here. I changed the size yesterday in materials.xml to 1024 and I saw that the houses/roofs/streets match to the mask I sent to Frederic. -Yves -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
Le 01/03/2010 00:22, Vivian Meazza a écrit : I think both effects should be in cvs so that we can do a bit of testing. We can then make some informed comment. The urban shader is in CVS. I find that the houses are too small, compared to 3D models, and I would like to crop the texture a bit. What do you thing ? -Fred First of all: That's a really cool eye candy, good work! What I noticed from a close up is, that it seems that the floor of the buildings is below elevation zero and the roof is at elevation zero. It looks somewhat as if the cities were carved out of the landscape instead of been built uppon it. This is especially irritating when a waterway is crossing an urban area and the water surface is several meters above the ground. Torsten -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
Erik Hofman schrieb: I've changed the coverage size of the textures from 1024 to 2000 meter. Hello Erik I guess it is better not to change the texture size to 2000 meters(?) in materials.xml. As I can see the size of the textures fits exactly to the relief when it is 1024 at the moment. -Yves -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
- HB-GRAL flightg...@sablonier.ch a écrit : Erik Hofman schrieb: I've changed the coverage size of the textures from 1024 to 2000 meter. Hello Erik I guess it is better not to change the texture size to 2000 meters(?) in materials.xml. As I can see the size of the textures fits exactly to the relief when it is 1024 at the moment. The relief (you mean the height of the buildings) can be adjusted in the effect file. The more important thing to me is to get the right horizontal scale. Nothing will change until the next scenery release because the scale is engraved in the scenery files (as texture coordinates) -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
Frederic Bouvier wrote: The urban shader is in CVS. I find that the houses are too small, compared to 3D models, and I would like to crop the texture a bit. What do you thing ? Impressive! I've changed the coverage size of the textures from 1024 to 2000 meter. I guess someone thought the size should reflect the number of pixels of the texture rather that then number of squared meters it covers. Erik -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
Frederic Bouvier wrote: Le 01/03/2010 00:22, Vivian Meazza a écrit : I think both effects should be in cvs so that we can do a bit of testing. We can then make some informed comment. The urban shader is in CVS. I find that the houses are too small, compared to 3D models, and I would like to crop the texture a bit. What do you thing ? I can't help feeling a little disappointed close to - the sugar loaf houses look a bit peculiar. From a distance, it's all pretty good. The houses are probably high enough, but a bit small in the other dimensions. You have probably pushed this technique as far as it will go, but some further adjustment might be possible. I think the results with forest top might be even better suited to this treatment. Well done: I think this is all a very worthwhile step for FG. Vivian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
Le 01/03/2010 00:22, Vivian Meazza a écrit : I think both effects should be in cvs so that we can do a bit of testing. We can then make some informed comment. The urban shader is in CVS. I find that the houses are too small, compared to 3D models, and I would like to crop the texture a bit. What do you thing ? -Fred -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
Thanks you very much Frederic for work with these normalmaps - it was my dream for a few last years ) -- --- WBR, Vadym. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
Wow! David On Sun, Feb 28, 2010 at 5:41 PM, Frederic Bouvier fredfgf...@free.fr wrote: What do you think of this effect : http://www.youtube.com/watch?v=kUyH-4c0-qM http://www.youtube.com/watch?v=wYb1Vy-uTS0 and a screenshot : http://frbouvi.free.fr/flightsim/fgfs-shader-test.jpg Regards, -Fred -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
That looks really cool!! :) personally i think it works nicer on the city/building area's then on the forest covered mountains. Kind Regards Rob / Evil On 02/28/2010 11:41 PM, Frederic Bouvier wrote: What do you think of this effect : http://www.youtube.com/watch?v=kUyH-4c0-qM http://www.youtube.com/watch?v=wYb1Vy-uTS0 and a screenshot : http://frbouvi.free.fr/flightsim/fgfs-shader-test.jpg Regards, -Fred -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
Wow! This can be a great shader feature in FG! :) On Mon, Mar 1, 2010 at 12:34 PM, evilslut flightg...@evilslut82.com wrote: That looks really cool!! :) personally i think it works nicer on the city/building area's then on the forest covered mountains. Kind Regards Rob / Evil On 02/28/2010 11:41 PM, Frederic Bouvier wrote: What do you think of this effect : http://www.youtube.com/watch?v=kUyH-4c0-qM http://www.youtube.com/watch?v=wYb1Vy-uTS0 and a screenshot : http://frbouvi.free.fr/flightsim/fgfs-shader-test.jpg Regards, -Fred -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Brant Gipson -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
The city looks fantastic fr0m a distance ! I dont like the terrain shader as shown , but looks really promising if the shading could be changed per material ... Great work . Syd -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Shaders experiments
What do you think of this effect : http://www.youtube.com/watch?v=kUyH-4c0-qM http://www.youtube.com/watch?v=wYb1Vy-uTS0 and a screenshot : http://frbouvi.free.fr/flightsim/fgfs-shader-test.jpg Regards, -Fred -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
On Sunday 28 February 2010 11:41:04 pm Frederic Bouvier wrote: and a screenshot : http://frbouvi.free.fr/flightsim/fgfs-shader-test.jpg Didn't have a chance to look at the video's yet, but the screen shot looks magnificant! Cheers, Durk -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
Hi, What do you think of this effect : http://www.youtube.com/watch?v=kUyH-4c0-qM http://www.youtube.com/watch?v=wYb1Vy-uTS0 and a screenshot : http://frbouvi.free.fr/flightsim/fgfs-shader-test.jpg Regards, -Fred The first one doesn't look very interesting, but the technic behind could be used for the rocky textures. The second one is more interesing- so you have screenshots from this shader? Cheers Heiko __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
On 01/03/10 11:41, Frederic Bouvier wrote: What do you think of this effect : Very nice. Very nice indeed. The urban area in video #2 especially is a dramatic difference. How do the effects look when you get close to the ground? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
On Sunday 28 Feb 2010, Frederic Bouvier wrote: What do you think of this effect : http://www.youtube.com/watch?v=kUyH-4c0-qM http://www.youtube.com/watch?v=wYb1Vy-uTS0 and a screenshot : http://frbouvi.free.fr/flightsim/fgfs-shader-test.jpg Regards, -Fred Overlaying a geometry shader on the FG scenery is pretty cool: is there the scope to tune it to the terrain gradient i.e. adapt the shader according to the steepness of the terrain slope? LeeE -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
- leee a écrit : On Sunday 28 Feb 2010, Frederic Bouvier wrote: What do you think of this effect : http://www.youtube.com/watch?v=kUyH-4c0-qM http://www.youtube.com/watch?v=wYb1Vy-uTS0 and a screenshot : http://frbouvi.free.fr/flightsim/fgfs-shader-test.jpg Regards, -Fred Overlaying a geometry shader on the FG scenery is pretty cool: is there the scope to tune it to the terrain gradient i.e. adapt the shader according to the steepness of the terrain slope? This is not a geometry shader, but a relief mapping effect. I am not fully happy with the result yet, but the relief map (normals + heightfield in a RGBA texture) was quickly made. City from low altitude : http://frbouvi.free.fr/flightsim/fgfs-city-relief.jpg I'll bet a better artist than me could do a better job. You can test it if you install the normal map plugin for the GIMP (http://registry.gimp.org/node/69) -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
Frederic Bouvier wrote -Original Message- From: [mailto:fredfgf...@free.fr] Sent: 28 February 2010 22:41 To: Flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] Shaders experiments What do you think of this effect : http://www.youtube.com/watch?v=kUyH-4c0-qM http://www.youtube.com/watch?v=wYb1Vy-uTS0 and a screenshot : http://frbouvi.free.fr/flightsim/fgfs-shader-test.jpg That's the best forest effect so far. Not quite so sure about the urban effect, but certainly better than we have atm. How does it look close up? I think both effects should be in cvs so that we can do a bit of testing. We can then make some informed comment. Vivian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
2010/2/28 Frederic Bouvier fredfgf...@free.fr: What do you think of this effect : Wow. Congratulations, you are starting to beat graphics benchmark set by Flight Simulator X. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
If anyone here ever played Gran Turismo 5 Prologue/Time Trial Demo/Whatever knows what a graphics API from 1998 is capable of ;) On Sun, Feb 28, 2010 at 6:41 PM, Christian Buchner wrote: 2010/2/28 Frederic Bouvier What do you think of this effect : Wow. Congratulations, you are starting to beat graphics benchmark set by Flight Simulator X. No no no no, according to the slashdot comments, we use graphics engine from 1998. :-) Great work Fred, these show a *lot* of interesting potential. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
I think these effects look great. As for the urban map, you could possibly do something with a transition between this effect and actual models, as this effect obviously looks poor from close up, while models kill framerate for large areas. Good job, and I hope to see an improved version of this in CVS soon. This will definitely beat MSFS's graphics capabilities. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders (Mac, nVidia 7300GT, latest CVS)
hi james, this is not at all how it should look like. i believe that either something is wrong with lighting values in gl_FrontLightModelProduct / gl_LightSource[0] or smoothstep() does not work correctly on your system. i'm working on improving the shaders. i'll try to make a shader without smoothstep for you to check. the problem could also be mac-specific? did someone else notice strange colors with the shaders on os x? cheers, - till On Sunday 30 August 2009, James Turner wrote: Can someone familiar with the current state of the shaders/effects code inform me if I'm what I'm seeing in the following shots is: - intended - a known, generic bug (or work in progress) - an issue to specific to my setup that I need to supply more information about Shots: (dusk shot is take with the sun almost directly behind the camera) http://files.goneabitbursar.com/fg-mac-nv7300-day.png http://files.goneabitbursar.com/fg-mac-nv7300-dusk.png It seems to me that the lighting model in both cases is a very unrealistically bright green (especially for the water, but also the fields) , and further that water is not behaving similarly to screenshots from other users I've seen in the forums, in terms of specular reflections based upon sun position and viewer angle. Cheers, James -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders (Mac, nVidia 7300GT, latest CVS)
Strange colors on windows with ATI GPU, but here dominating color is red in the crop shader. I slightly modified the effects file and rendering gui to be able to enable them one at a time. both landmass and crop suffer from that, and it's triggered by camera movement. Unrelated comments : Might want to look in at disabling fixed function lighting when doing per pixel lighting, and tweak blending and alpha settings, first to avoid wasting gpu cycles on unneeded settings, like lighting when doing per pixel. but also to prevent side effects from fixed function state. Also, I was once told that stuff like a = b = c should be avoided : there is absolutely no guarantee it will be processed correctly, or in the order you think it would. GLSL is definitely not C :) Seems to work, but it's a dangerous slope if you want portability to rely on C side effects in GLSL. Common and oft repeated wisdom is if you develop on nvidia, you debug on ATI (or 3Dlabs) and if it runs there, it should run everywhere : nvidia seems to be the laxest of the GLSL spec interpretations (they all divert from the spec where they feel like it, except maybe 3dlabs who, well, created the specs) Comments inside code lines are forbidden by the specs (stuff like some_code /*comment*/; is not compliant, but some_code; /*comment*/ is) : either by itself on a line, or after all code on a line, after the; Water shader does work beautifully, albeit the geometry seams are very visible. I seem to recall that wasn't the case with the first version committed, I'll have to re-check. Thanks for all the hard work, Cheers, Nic On Mon, Aug 31, 2009 at 4:42 AM, till busch b...@bux.at wrote: hi james, this is not at all how it should look like. i believe that either something is wrong with lighting values in gl_FrontLightModelProduct / gl_LightSource[0] or smoothstep() does not work correctly on your system. i'm working on improving the shaders. i'll try to make a shader without smoothstep for you to check. the problem could also be mac-specific? did someone else notice strange colors with the shaders on os x? cheers, - till mes https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Shaders (Mac, nVidia 7300GT, latest CVS)
Can someone familiar with the current state of the shaders/effects code inform me if I'm what I'm seeing in the following shots is: - intended - a known, generic bug (or work in progress) - an issue to specific to my setup that I need to supply more information about Shots: (dusk shot is take with the sun almost directly behind the camera) http://files.goneabitbursar.com/fg-mac-nv7300-day.png http://files.goneabitbursar.com/fg-mac-nv7300-dusk.png It seems to me that the lighting model in both cases is a very unrealistically bright green (especially for the water, but also the fields) , and further that water is not behaving similarly to screenshots from other users I've seen in the forums, in terms of specular reflections based upon sun position and viewer angle. Cheers, James -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders (was Re: 3D trees)
On Dec 30, 2007 1:23 PM, Heiko Schulz [EMAIL PROTECTED] wrote: But back too the forest and trees: are imposters are possible way too, to get a good perfomance and looking? I'm not a big expert on imposters, but I'm wondering how well they would work for trees. If you cook one tree into each imposter image, then that becomes a huge amount of effort, although the result would be awsome if the imposters were updated often enough. You could get the proper aerial perspective on the trees, etc. But for efficiency and sanity, you'd probably need to cook multiple trees into each imposter, but what surface would you cook that into, and would there be problems (i.e. z-buffer fighting) since the imposters would be located very close to the terrain. How do you handle laying the imposter shapes over the changing terrain? Maybe there's a sensible way to do this? I'm just asking because from my understanding of imposters I don't know that they would work the best for trees as seen from the perspective and altitude that you'd typically have in a flight simulator. It seems like we'd want a situation where *many* smaller models get cooked into a single image, and then the likelihood of that image changing from frame to frame would need to be low. Possibly that's reasonable for trees, except the imposter surfaces would need to be so close to the terrain that I imagine that might cause some z-buffer problems? Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] shaders (was Re: 3D trees)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Mayer wrote: Josh Babcock schrieb: LeeE wrote: On Sunday 30 December 2007 09:47, Detlef Faber wrote: Hello, Could it be that the overhead of rotating many simple billboard objects accounts for the performance hit over an equivalent number of more complex static models? That does have significant overhead as it is all done on the CPU Probably has more to do with the fact that the billboards are not only UV mapped, but also have an alpha channel. These new ones appear to just be using OGL materials. I wonder, does OSG do vertex painting? That would be a great way to make these look better without adding a texture. There should be no problem with using textures for the trees on any hardware manufactured after the early part of this century. In the OSG world we will have to take some care that the trees are not depth-sorted as that will be quite expensive with high tree densities. I'm a bit out of the current 3D programming that FGFS uses... But wouldn't a vertex shader help in this case (for billboarding as well as generic trees)? They would help with a lot of things with respect to trees: * you could do the billboarding in a shader, as you mention; * there's a trick in OpenGL that is demonstrated in the OSG osgforest demo that uses a shader to create very cheap tree instances that don't incur the cost of matrix transform for each tree; * everything else you can do with shaders to make things look good. I would think that we would punt the billboarding if we can come up with a cheap 3D tree that is convincing from the air. I changed the subject because we currently have no way to specify shaders other than to hard-code them in the C++ code. In general, the parameters we specify for materials are quite limited. I've been studying the Ogre (www.ogre3d.org) materials system for a while and think that the syntax of their material scripts system, www.ogre3d.org/docs/manual/ , adapted to XML property lists and FlightGear needs, would be quite excellent. It seems quite exotic from a FlightGear point of view, but we will soon have shadows and multi-pass lighting (for landing lights) and we will need some way for materials to interact with them. CU, Christian Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHd+WseDhWHdXrDRURAph/AJ9HYi/XH8qGgkh2YHxaqkp+VubargCfRKVH inj9a/+CT3y06ItiwGH8Nwk= =nM2j -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders (was Re: 3D trees)
Hi, --- Tim Moore [EMAIL PROTECTED] schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Mayer wrote: Josh Babcock schrieb: LeeE wrote: On Sunday 30 December 2007 09:47, Detlef Faber wrote: Hello, Could it be that the overhead of rotating many simple billboard objects accounts for the performance hit over an equivalent number of more complex static models? That does have significant overhead as it is all done on the CPU Probably has more to do with the fact that the billboards are not only UV mapped, but also have an alpha channel. These new ones appear to just be using OGL materials. I wonder, does OSG do vertex painting? That would be a great way to make these look better without adding a texture. There should be no problem with using textures for the trees on any hardware manufactured after the early part of this century. In the OSG world we will have to take some care that the trees are not depth-sorted as that will be quite expensive with high tree densities. I'm a bit out of the current 3D programming that FGFS uses... But wouldn't a vertex shader help in this case (for billboarding as well as generic trees)? They would help with a lot of things with respect to trees: * you could do the billboarding in a shader, as you mention; * there's a trick in OpenGL that is demonstrated in the OSG osgforest demo that uses a shader to create very cheap tree instances that don't incur the cost of matrix transform for each tree; * everything else you can do with shaders to make things look good. I would think that we would punt the billboarding if we can come up with a cheap 3D tree that is convincing from the air. I changed the subject because we currently have no way to specify shaders other than to hard-code them in the C++ code. In general, the parameters we specify for materials are quite limited. I've been studying the Ogre (www.ogre3d.org) materials system for a while and think that the syntax of their material scripts system, www.ogre3d.org/docs/manual/ , adapted to XML property lists and FlightGear needs, would be quite excellent. It seems quite exotic from a FlightGear point of view, but we will soon have shadows and multi-pass lighting (for landing lights) and we will need some way for materials to interact with them. CU, Christian Tim your idea sounds good - that would maybe improve other things in FGFS graphic too: water (ocean...), runways and of course the objects ( building and airrafts) But back too the forest and trees: are imposters are possible way too, to get a good perfomance and looking? Regards HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html Jetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und viel mehr bietet das neue Yahoo! Mail - www.yahoo.de/mail - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
