Re: [Flightgear-devel] [PATCH] 3D Clouds update
Nope, same fps... But clouds look much better; thanks Stuart! -- --- WBR, Vadym. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] October $250 Flight Gear Developers
On 10/06/2009 03:14 PM, Curtis Olson wrote: On Tue, Oct 6, 2009 at 7:57 AM, Tim Moore timo...@redhat.com mailto:timo...@redhat.com wrote: 3D panel does not mean that you need a 3D view of the cockpit to see the instruments. I guess I've never seen an example of anyone configuring an orthographic view in FlightGear, but I'm sure it's doable. Do we have configuration level support for this, or would it be a coding exercise? The other It's supported by the camera configuration code that also implements multiple cameras. There is some additional coding to make this fully practical for cockpit panels: an orthographic view is still a view of the entire scene. You can set the far clipping plane to avoid rendering the whole outside world, but that is still forcing the OSG culling code to do a lot of work. If there is a way to tag 3d geometry that is part of a panel, then it will be very easy to render only that geometry in the view. part is that the designer would need to carefully align the panel surface orthogonal to the view direction to assure there is no warping of the panel relative to the view plane, again, should be a relatively simple task, but would need to be done and need to be thought about. So it's definitely a solvable problem, but there are several extra steps, and I haven't seen an example to work from within FlightGear. And generally, if it's never been done before, the first person blazing the path will typically run into some unexpected surprises. True enough. Tim Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Alan Teeder wrote: Erik Sorry, I gave the wrong missing name -- I should have written alutGetError, as this is not in the older alut.h (or al.h or alc.h). Ah that was just a matter of commenting out the proper section. Should be fixed now. Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Screenshots as PNGs
If you update SG and FG, screenshots are now written as PNGs - please give it a go! In fact, it would be possibly to write out in any format which your OSG has a loadable plugin for - JPEG, BMP, whatever. All that's needed is to change the file extension we append to the name in FG. (And, I haven't tested the behaviour when OSG-DB *can't* find a suitable plugin) If anyone cares, adding a 'screenshot format' property would be easy. Note there's some other issues with the screenshot code (eg, it doesn't hide the UI before taking the shot) which I have not attempted to fix. Another thing I will probably do is adapt the 'huge screenshot code' to use osgDB, and hence remove the libjpeg optional dependency, and associated clutter in configure.in. Regards, James -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] 3D Clouds update
Same here too. And I don't even have a good graphics card! ;) -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] 3D Clouds update
Scott Hamilton wrote: On Tue, 2009-10-06 at 22:06 -0400, William Harrison wrote: Maybe it's just me, but has anyone noticed a dramatic performance decrease with 3d clouds after this patch? yep, from 30fps to 2fps... I'm very surprised that performance has decreased so significantly. However, there is a possible explanation. The code falls back to a 2D cloud layer if a 3D cloud isn't defined for a specific cloud type (st, ac etc.). IIRC previously we didn't define a 3D stratus layer, so we'd get a 2D layer instead. The updated 3D clouds include stratus layers (which look rather nice IMO), but require quite a larger number of sprites - something like 40 per cloud. I've seen a small perf hit from the new stratus layers, but nothing like what you have reported. I suspect what you are seeing if the difference between a 2D and 3D cloud. What performance change are you seeing with, say, cumulus clouds, which haven't changed much? BTW - I've updated Docs/Readme.3Dclouds with information on the new format, if anyone is interested in enhancing the clouds. -Stuart -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS / route-manager landing
James The this fault is fixed. Thanks. To cure the time and difftime under Windows all that is needed is to include time.h Alan _ From: Alan Teeder [mailto:ajtee...@v-twin.org.uk] Sent: 06 October 2009 17:38 To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] GPS / route-manager landing Also VC90 also does not this at line 70 of route_mgr.cxx. :- Compiling... route_mgr.cxx ..\..\..\src\Autopilot\route_mgr.cxx(70) : warning C4355: 'this' : used in base member initializer list ..\..\..\src\Autopilot\route_mgr.cxx(229) : error C3861: 'time': identifier not found ..\..\..\src\Autopilot\route_mgr.cxx(233) : error C3861: 'time': identifier not found ..\..\..\src\Autopilot\route_mgr.cxx(234) : error C3861: 'difftime': identifier not found Build log was saved at file://d:\fg\source\projects\VC90\FlightGear\Win32\Release\BuildLog.htm Alan _ From: Nicolas Quijano [mailto:nquij...@gmail.com] Sent: 06 October 2009 17:22 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] GPS / route-manager landing Hi all, this doesn't build on windows, it can't find the time symbol referenced at line 229 and 233 in route_mgr.cxx. Missing header ? Also, there is a reference to std::strncasecmp in positioned.cxx around line 820, which is also not available in windows (at least, not here). Since it's dealing with c strings, I've added locally an #ifdef WIN32 check which uses_stricmp instead in this case. Don't know how you want to deal with this, Cheers, Nic On Mon, Oct 5, 2009 at 3:59 AM, James Turner zakal...@mac.com wrote: On 5 Oct 2009, at 08:33, Dave wrote: That all sounds like good stuff. I'll try and migrate the KLN89 towards using it and depreciating the dclgps stuff - that should give it some testing. Sounds good to me. I've been going through the KLN89 manual, and there's definitely some more subtle options that will require extra features / flags (off the top of my head, resuming LEG mode from OBS mode, and the ability to DTO without recentering the d-bar). Many things should be achievable with a bit of Nasal glue, obviously I've tried to make simple building block functionality as much as I can. If you think an API or design is poor, or missing a feature, let me know and I'm happy to add it - I'd far rather get the core code sensible, than have each GPS device work around the same bug! In terms of API examples, I will be committing a new GPS dialog, which shows off most of the new features, and will also allow the GPS to be used in aircraft without real hardware, if we want that. I'm also going to create a wiki page for the GPS, to document what it can (and can't do). Regards, James -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] 3D Clouds update
On Wed, 2009-10-07 at 09:18 +, Stuart Buchanan wrote: Scott Hamilton wrote: On Tue, 2009-10-06 at 22:06 -0400, William Harrison wrote: Maybe it's just me, but has anyone noticed a dramatic performance decrease with 3d clouds after this patch? yep, from 30fps to 2fps... OK, I hope this reproducer scenario helps; 1. don't turn on 3D clouds from command line, don't specify any weather (manual metar), default; scattered at 4000ft and cirrus at 19500 25-31fps 2. go into rendering options, turn on 3D clouds 2-3fps 3. change 19500 from cirrus to clear 2-6fps 4. change 4000 from scattered to few remains 2-6 fps 5. change 4000 from few to clear 20-24fps 6. turn OFF 3D clouds (so there is no 3D or 2D clouds) 23-26fps I last built fgfs 2009-10-03 19:23 (Sydney time) I've now done a cvs update and 'make clean' on SimGear and FlightGear and updated data/Shaders/ 1. same as a above. The cmd line is; bin/fgfs --enable-sound --enable-hud --aircraft=A380 --airport=YSSY --runway=34L --timeofday=afternoon 28-32fps 2. go into rendering options, turn ON 3D clouds 7 fps 3. change 19500 from cirrus to clear remains 7fps 4. change 4000 from scattered to few 10-11fps 5. change 4000 from few to clear 23-27fps 6. turn OFF 3D clouds remains 23-27fps Operating System: openSuSE 11.1 (kernel2.6.27.29-0.1-default ) Model: nVidia Quadro FX 580 I'm assuming shaders need some OpenGL help; # glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_texture_from_pixmap, GLX_ARB_create_context, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_NV_swap_group, GLX_EXT_framebuffer_sRGB, GLX_NV_multisample_coverage client glx vendor string: NVIDIA Corporation client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync, GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_ARB_create_context, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_EXT_fbconfig_packed_float, GLX_EXT_texture_from_pixmap, GLX_EXT_framebuffer_sRGB, GLX_NV_present_video, GLX_NV_multisample_coverage GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_texture_from_pixmap, GLX_ARB_create_context, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_NV_swap_group, GLX_EXT_framebuffer_sRGB, GLX_NV_multisample_coverage, GLX_ARB_get_proc_address OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: Quadro FX 580/PCI/SSE2 OpenGL version string: 3.0.0 NVIDIA 180.44 I hope something here helps, as they do look good, but I can't get off the ground to see them :) cheers S. I'm very surprised that performance has decreased so significantly. However, there is a possible explanation. The code falls back to a 2D cloud layer if a 3D cloud isn't defined for a specific cloud type (st, ac etc.). IIRC previously we didn't define a 3D stratus layer, so we'd get a 2D layer instead. The updated 3D clouds include stratus layers (which look rather nice IMO), but require quite a larger number of sprites - something like 40 per cloud. I've seen a small perf hit from the new stratus layers, but nothing like what you have reported. I suspect what you are seeing if the difference between a 2D and 3D cloud. What performance change are you seeing with, say, cumulus clouds, which haven't changed much? BTW - I've updated Docs/Readme.3Dclouds with information on the new format, if anyone is interested in enhancing the clouds. -Stuart -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
Re: [Flightgear-devel] Screenshots as PNGs
On Wed, 2009-10-07 at 09:33 +0100, James Turner wrote: In fact, it would be possibly to write out in any format which your OSG has a loadable plugin for - JPEG, BMP, whatever. All that's needed is to change the file extension we append to the name in FG. (And, I haven't tested the behaviour when OSG-DB *can't* find a suitable plugin) This sounds really cool. Looking forward to trying it out. Note there's some other issues with the screenshot code (eg, it doesn't hide the UI before taking the shot) which I have not attempted to fix. One man's feature is another man's bug. :) While admittedly most screen shots don't want the UI shown, a very large percentage of screen shots I've shared were created to show the UI components as part of a tutorial or to demonstrate an issue. I would prefer the screen shot code to generate an image identical to what is shown on the screen. Another thing I will probably do is adapt the 'huge screenshot code' to use osgDB, and hence remove the libjpeg optional dependency, and associated clutter in configure.in. Perhaps at some point the 'huge screenshot code' could become the UI-less way to take a screen shot since, as I understand it, this code was intended for high-res, high-quality captures. Thanks, Ron -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots as PNGs
On Wed, Oct 7, 2009 at 8:57 AM, Ron Jensen wrote: One man's feature is another man's bug. :) While admittedly most screen shots don't want the UI shown, a very large percentage of screen shots I've shared were created to show the UI components as part of a tutorial or to demonstrate an issue. I would prefer the screen shot code to generate an image identical to what is shown on the screen. ... and if you don't want any gui elements in your screenshot, it's easy enough to turn them all off and use the F3 hot key to take the snapshot. (Close all the dialog boxes, and then F10 toggles the menu on/off) Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots as PNGs
On 7 Oct 2009, at 15:04, Curtis Olson wrote: ... and if you don't want any gui elements in your screenshot, it's easy enough to turn them all off and use the F3 hot key to take the snapshot. (Close all the dialog boxes, and then F10 toggles the menu on/off) I was aware of this (and I guess many people are), but from a pure UX point of view, it's not ideal - I realise being able to screenshot the UI is very handy in creating tutorials, bug reporting, and so on. Probably all it really needs is a FAQ entry (in the Wiki?) telling people about the F3 / F10 trick . -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] 3D Clouds update
Hi Scott, Something else to try would be to turn off the other shaders (water reflection/ground cover). When I get all of these + clouds + rain/snow, my performance really goes in the toilet too. The snow/elevation shader seems to be especially hard on frame rates, but I notice the farm field shader has a big affect too if there is a lot of farm fields in the view. I don't quite get the farm field shader purpose. Can we not do pretty much the same thing with a basic texture? I see what the terrain elevation/slope shader is doing and that's interesting, but it's a huge frame rate hit for what it offers. Regards, Curt. On Wed, Oct 7, 2009 at 6:03 AM, Scott Hamilton scott.hamil...@popplanet.biz wrote: On Wed, 2009-10-07 at 09:18 +, Stuart Buchanan wrote: Scott Hamilton wrote: On Tue, 2009-10-06 at 22:06 -0400, William Harrison wrote: Maybe it's just me, but has anyone noticed a dramatic performance decrease with 3d clouds after this patch? yep, from 30fps to 2fps... OK, I hope this reproducer scenario helps; 1. don't turn on 3D clouds from command line, don't specify any weather (manual metar), default; scattered at 4000ft and cirrus at 19500 25-31fps 2. go into rendering options, turn on 3D clouds 2-3fps 3. change 19500 from cirrus to clear 2-6fps 4. change 4000 from scattered to few remains 2-6 fps 5. change 4000 from few to clear 20-24fps 6. turn OFF 3D clouds (so there is no 3D or 2D clouds) 23-26fps I last built fgfs 2009-10-03 19:23 (Sydney time) I've now done a cvs update and 'make clean' on SimGear and FlightGear and updated data/Shaders/ 1. same as a above. The cmd line is; bin/fgfs --enable-sound --enable-hud --aircraft=A380 --airport=YSSY --runway=34L --timeofday=afternoon 28-32fps 2. go into rendering options, turn ON 3D clouds 7 fps 3. change 19500 from cirrus to clear remains 7fps 4. change 4000 from scattered to few 10-11fps 5. change 4000 from few to clear 23-27fps 6. turn OFF 3D clouds remains 23-27fps Operating System: openSuSE 11.1 (kernel2.6.27.29-0.1-default ) Model: nVidia Quadro FX 580 I'm assuming shaders need some OpenGL help; # glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_texture_from_pixmap, GLX_ARB_create_context, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_NV_swap_group, GLX_EXT_framebuffer_sRGB, GLX_NV_multisample_coverage client glx vendor string: NVIDIA Corporation client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync, GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_ARB_create_context, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_EXT_fbconfig_packed_float, GLX_EXT_texture_from_pixmap, GLX_EXT_framebuffer_sRGB, GLX_NV_present_video, GLX_NV_multisample_coverage GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_EXT_texture_from_pixmap, GLX_ARB_create_context, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, GLX_NV_swap_group, GLX_EXT_framebuffer_sRGB, GLX_NV_multisample_coverage, GLX_ARB_get_proc_address OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: Quadro FX 580/PCI/SSE2 OpenGL version string: 3.0.0 NVIDIA 180.44 I hope something here helps, as they do look good, but I can't get off the ground to see them :) cheers S. I'm very surprised that performance has decreased so significantly. However, there is a possible explanation. The code falls back to a 2D cloud layer if a 3D cloud isn't defined for a specific cloud type (st, ac etc.). IIRC previously we didn't define a 3D stratus layer, so we'd get a 2D layer instead. The updated 3D clouds include stratus layers (which look rather nice IMO), but require quite a larger number of sprites - something like 40 per cloud. I've seen a small perf hit from the new stratus layers, but nothing like what you have reported. I suspect what you are seeing if the difference between a 2D and 3D cloud. What performance change are you seeing with, say, cumulus clouds, which haven't changed much? BTW - I've updated Docs/Readme.3Dclouds with information on the new format, if anyone is interested in enhancing the clouds. -Stuart -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only
Re: [Flightgear-devel] [PATCH] 3D Clouds update
On Wednesday 07 October 2009 11:18:07 am Stuart Buchanan wrote: I'm very surprised that performance has decreased so significantly. However, there is a possible explanation. FWIW, I've run into one situation where the new cloud code significantly slowed down my system. I found that reducing the range setting from 20km to approximately 11-12 kilometers gave me back decent performance, without too mach sacrificing of detail. It seemed to be a rather sharp transition, so I'm wondering whether texture memory use has something to do with it. Just thinking out loud, Would it be feasable to impement some sort of LOD scheme, where sprites are dynamically added as they are getting closer? That way, it might be possible to have clouds across a much larger area with as much of an impact on performance. Cheers, Durk -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] 3D Clouds update
On Wed, Oct 7, 2009 at 10:33 AM, Durk Talsma d.tal...@xs4all.nl wrote: On Wednesday 07 October 2009 11:18:07 am Stuart Buchanan wrote: I'm very surprised that performance has decreased so significantly. However, there is a possible explanation. FWIW, I've run into one situation where the new cloud code significantly slowed down my system. I found that reducing the range setting from 20km to approximately 11-12 kilometers gave me back decent performance, without too mach sacrificing of detail. It seemed to be a rather sharp transition, so I'm wondering whether texture memory use has something to do with it. Just thinking out loud, Would it be feasable to impement some sort of LOD scheme, where sprites are dynamically added as they are getting closer? That way, it might be possible to have clouds across a much larger area with as much of an impact on performance. I also noticed a huge frame rate drop when I was in or close to being in the cloud layer, so that the clouds consumed the greatest percentage of the screen real estate ... that is when the frame rates were the worst. If we are drawing zillions of transparent quads and suddenly they are sized to cover nearly the whole screen, then we are basically rendering the whole screen (or most of the screen) for each cloud quad, or enough of them that are near by to pull the frame rates down to very low levels. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] 3D Clouds update
Hi, I also noticed a huge frame rate drop when I was in or close to being in the cloud layer, so that the clouds consumed the greatest percentage of the screen real estate ... that is when the frame rates were the worst. If we are drawing zillions of transparent quads and suddenly they are sized to cover nearly the whole screen, then we are basically rendering the whole screen (or most of the screen) for each cloud quad, or enough of them that are near by to pull the frame rates down to very low levels. Curt. I coulden't try the new cloud patch yet- I'm waiting that someone makes a binary snapshot for win32-users ;-) So much I understood, there is a certain level of sprites numbers needed, so that the single clouds is correctly shaded. But as transpareny is one of the strongest factor which slows down, it is no wonder that the fps might decreases... As our technic is very similar to the one of X-Plane and MSFS, it is quite interesting how they got managed to have a bit better perfomance: X-Plane: they use one sprite for one single cloud- that looks sometimes funny viewed from above (rotation of the clouds), but seems to give a good perfomance. But they don't give this realistic shading from white to grey as we can see on the real clouds in the sky or here in FGFS... MSFS: depending if default or Add-on. The recent Add-On called REX looks really good, but also seems to use only sprite per single cloud. The default clouds tried in the demo once a time uses some more sprites. Their clouds system shows a quite nice shading similar to our. I prefer our shading from white to grey of the clouds, as it looks really realistic, but as I understood Stuart it only works good and without any errors with a certain number of sprites. I wonder if it would be possible to have this shading from white to grey from top to bottom without many sprites. This would help a lot, and we already can define the number of sprites uisng the slider in the rendering menu. Correct me if I'm wrong in any points here Regards HHS -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fg-home on windows and mac
In Linux the users flightgear directory is at /home/username/.fgfs. As I don't have a windows pc and haven't yet tried flightgear on my mac, I wonder if someone can enlighten me to the path for the users directory on those systems. Thanks! -- Jacob -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots as PNGs
Ron Jensen wrote: [...] I would prefer the screen shot code to generate an image identical to what is shown on the screen. Good point, especially as you can easily initiate a screen dump by pressing Alt-Fsomething (or maybe F3, I've forgotten ), thus you don't need the menu to create one, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RSync for TerraSync down
Daniel Vigano wrote: Sorry, but I can't use SVN because I use a old FG version. (1.0.0; It's in the ubuntu repository.) Using an old version of FlightGear still doesn't prevent you from picking a 'terrasync' binary from a recent build, since the communication protocol is unchanged, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS / route-manager landing
Hey all, I also added time.h on my side, in an #ifdef, since it's somehow already included nix side :) That said, why not simply assign 0 to the two time_t rather than a function call ? Then, it's only a matter of dealing with difftime. Don't we already have time (and timing ?) abstracted facilities though SG ? Shouldn't we first use that, or add the necessary abstracted functionality there ? Also, if we have two consistent time_t, why not simply subtract one from the other, ABS it, and voila you have the time difference ? Or am I missing something regarding usage of difftime ? Cheers, Nic On Wed, Oct 7, 2009 at 5:39 AM, James Turner zakal...@mac.com wrote: On 7 Oct 2009, at 10:32, Alan Teeder wrote: James The “this” fault is fixed. Thanks. To cure the time and difftime under Windows all that is needed is to include time.h That's what I'd hoped, thanks for confirming. I would still prefer to use something more robust than the C-library functions, so I'm investigating that, but obviously it's more important to get Windows building again. Regards, James -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Hi Erik, I think I have found a small bug in the new sound system: When I fly past (well, over) the markers (inner, middle or outer) the marker beeps has a very neat fade in/out and doppler effect, but I'm fairly sure the device producing the sound ought to be right there next to me in the cockpit even though the radio waves are emitted from the ground. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Hi Anders, Anders Gidenstam wrote: Hi Erik, I think I have found a small bug in the new sound system: When I fly past (well, over) the markers (inner, middle or outer) the marker beeps has a very neat fade in/out and doppler effect, but I'm fairly sure the device producing the sound ought to be right there next to me in the cockpit even though the radio waves are emitted from the ground. Just to be sure; was this with the latest code as of today? I did commit a code change that should have resolved this. Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
On Wed, 7 Oct 2009, Erik Hofman wrote: Hi Anders, Just to be sure; was this with the latest code as of today? I did commit a code change that should have resolved this. Ah, probably not - I last updated a few hours ago and I see that there has been some changes to sound files since. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] 3D Clouds update
Durk Talsma wrote: On Wednesday 07 October 2009 11:18:07 am Stuart Buchanan wrote: I'm very surprised that performance has decreased so significantly. However, there is a possible explanation. FWIW, I've run into one situation where the new cloud code significantly slowed down my system. I found that reducing the range setting from 20km to approximately 11-12 kilometers gave me back decent performance, without too mach sacrificing of detail. It seemed to be a rather sharp transition, so I'm wondering whether texture memory use has something to do with it. Just thinking out loud, Would it be feasable to impement some sort of LOD scheme, where sprites are dynamically added as they are getting closer? That way, it might be possible to have clouds across a much larger area with as much of an impact on performance. That's a very interesting idea - I'll add it to my list of things to investigate. Unfortunately the 3D cloud performance seems to be very graphics-card specific. My card is a couple of years old, but doesn't seem to have the same problems. -Stuart -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] 3D Clouds update
Heiko Schulz wrote:aeitsch...@yahoo.de I coulden't try the new cloud patch yet- I'm waiting that someone makes a binary snapshot for win32-users ;-) So much I understood, there is a certain level of sprites numbers needed, so that the single clouds is correctly shaded. But as transpareny is one of the strongest factor which slows down, it is no wonder that the fps might decreases... As our technic is very similar to the one of X-Plane and MSFS, it is quite interesting how they got managed to have a bit better perfomance: I think a big difference is that MSFS uses Impostors. These effectively pre-render a set of sprites onto a texture, and use the resulting texture until the view angle changes significantly. This saves a lot of transparency rendering. Unfortunately, last time I tried it, the OSG Impostor implimentation was very broken, and I didn't have the skills to fix it. I may have another look to see if it has been improved in recent OSG releases. -Stuart -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Fwd: fg-home on windows and mac
In Linux the users flightgear directory is at /home/username/.fgfs. As I don't have a windows pc and haven't yet tried flightgear on my mac, I wonder if someone can enlighten me to the path for the users directory on those systems. Thanks! -- Jacob -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
