[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
[Flightgear-devel] Auto-hiding the cursor ;-)
Hi all There is a nice new feature now with hiding the cursor. Ok, it is hard for new users to get the cursor back, I think it is wrong to set the hiding after 10 seconds to default. Maybe there are other ways to show this nice new feature ;-) Anyway I have to throw the mouse to the wall here to get the cursor back in screen. Maybe it should come back earlier. A newer issue is that the cursor does not change the form anymore when I do right clicks ? Also control-key-c is disabled on OSX, but that I will investigate further. Cheers, 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] Auto-hiding the cursor ;-)
Am 21.03.11 09:13, schrieb HB-GRAL: Hi all There is a nice new feature now with hiding the cursor. Ok, it is hard for new users to get the cursor back, I think it is wrong to set the hiding after 10 seconds to default. Maybe there are other ways to show this nice new feature ;-) Anyway I have to throw the mouse to the wall here to get the cursor back in screen. Maybe it should come back earlier. A newer issue is that the cursor does not change the form anymore when I do right clicks ? Also control-key-c is disabled on OSX, but that I will investigate further. Cheers, 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 I reported this to the bug tracker, maybe it’s a OSX/Carbon specific issue? Hope not. Cheers, 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] FlightGear launcher for snapshots/2.2 preview OSX
On 3/20/2011 1:02 PM, HB-GRAL wrote: Hi all I made a small launcher based on qt4 for FlightGear 2.2 on OSX. There is a FlightGear GIT version included for testing. The bundle contains todays master of simgear/flightgear and todays fgdata, reduced to a small and distributable selection of aircrafts. Requirement is OSX= 10.6 on a intel-based mac at the moment. You can use the whole bundle also for your own devel versions or snapshots of flightgear/fgdata, just set the path to. There is also an edit for own fgfs commandline arguments. Terrasync is included, also fgcom support, but you have to install fgcom separately (see my older mail here about fgcom for OSX). I am looking forward for some feedback, bug reports and feature requests. Hope it is useful for some mac people around. Cheers, Yves The source is here http://gitorious.org/fgx (without binary and fgdata now) Bundle with fgfs/fgdata included is here: http://fgx.sablonier.ch/fgx22pre3FULL.dmg I like the idea of using Qt for a launcher as I understand that it is cross-platform and should work just as well with Windows. I got your source and will try it out on Linux, which has been my only Qt target so far. Without having tried it yet, I suppose my first feedback would be the name. fgx strongly associates it with OSX, but I don't see why that should have to be the case. -- 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
[Flightgear-devel] Adventures in dds
A while ago I posed the question: What I have been wondering is the following: Currently I am using *.rgb textures. I have noticed that the filesize can be reduced by a factor 2 or so by going to *.png textures. However, what is the format which would most efficiently into the scenery? If *.png saves filespace at the expense of time, then there's no point in converting, but if png also loads a factor 2 faster, I would convert all texture sheets. I have now done some tests myself - and here are the (surprising?) results (I may have to add here that I have no clue what the various dds options and formats actually are...) The test texture: One 1024x1024 texture sheet (altocumulus_textures.rgb), the original is a gimp-created *.rgb file, converted with gimp to a *.png and using nvidia texture tools ./nvcompress -nomips -bc3 altocumulus_textures.png altocumulus_textures.dds into dds format. The test situation: 50.000 ft straight above TNCM, looking down with maximal view angle, 45 km visibility, creating a 50x50 sheet of Altocumulus clouds. The measurement: File size, time till the cloud sheet has appeared in the scenery, framerate after the cloud sheet has appeared in the scenery. The result: rgb: filesize 1.7 MB, time to appear 12 s, framerate for rendering 32 fps png: filesize 0.8 MB, time to appear 135 s (!), framerate for rendering 21 fps dds: filesize 1.1 MB, time to appear 13 s, framerate for rendering 20 fps I have also tried other dds options, some didn't even render properly, and none was better than the bc3 shown here. ... and the winner is: The rgb format. Given than harddisk space is cheap, whereas framerate is not, the larger impact on the framerate makes dds simply not competitive for me - if 0.6 MB space cost 10 fps, then that's a very bad deal. png really seems to be a bad guy - it slows the system down incredibly. So, my answer is, apparently it doesn't help to use a different texture format to speed the system up, rgb is as fast as it gets. Which is disappointing, but that's how it is. If I made a mistake somewhere, please let me know! Cheers, * Thorsten -- 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] FlightGear launcher for snapshots/2.2 preview OSX
Am 21.03.11 11:54, schrieb Reagan Thomas: I like the idea of using Qt for a launcher as I understand that it is cross-platform and should work just as well with Windows. I got your source and will try it out on Linux, which has been my only Qt target so far. Hi Thomas At the moment it is not cross-platform, unfortunately. I didn’t get QProcess to work here so I write to bash scripts and start this scripts via system() and terminal appplication on OSX. This works for OSX, but the whole part for starting fgfs with args should be rewritten I think. The name could change of course. I didn’t spend time yet to search for a good cross-platform name (the fg(x) comes from Linu(x) ;-). I am on OSX and Ubuntu, and I like the idea to use it for different platforms of course. I hope that someone with more experience on Qt and C++ dives into once and rewrites some parts to proper code and design anyway. Cheers, 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] Adventures in dds
On Mon, 2011-03-21 at 13:15 +0200, thorsten.i.r...@jyu.fi wrote: ... and the winner is: The rgb format. To be honest I was expecting this but didn't have proof for it. Remember that the RGB format was developed by Silicon Graphics to be used for OpenGL and it probably resembled at least the internal format used by SGI back then. 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] Adventures in dds
On 21 Mar 2011, at 11:15, thorsten.i.r...@jyu.fi wrote: rgb: filesize 1.7 MB, time to appear 12 s, framerate for rendering 32 fps png: filesize 0.8 MB, time to appear 135 s (!), framerate for rendering 21 fps dds: filesize 1.1 MB, time to appear 13 s, framerate for rendering 20 fps I have also tried other dds options, some didn't even render properly, and none was better than the bc3 shown here. Maybe you already did this, but this needs a 'average of 3' (or 5) tests, because I would be very surprised if the input file format changes the final frame-rate after loading - it's all uncompressed to the same format in GPU memory, as far as I know. The PNG loading time also seems suspicious - decompressing a PNG is certainly more work than RGB or DDS, but decompressing a 1MB PNG shouldn't take even one second on a computer of the past few years. James -- 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
[Flightgear-devel] Local weather ??????
Hi, Git version: when playing with the Local weather menu, i get the following message Nasal runtime error: setprop() value is not string or number at /../data/Nasal/weather_tile_management.nas, line 189 called from: /../data/Nasal/local_weather.nas, line 2964 called from: /../data/Nasal/local_weather.nas, line 3780 called from: /./data/Nasal/globals.nas, line 100 Is it a Bug ? , Is it just me. ? In addition i cannot get any realistic effect with the Global weather when using the predefined scenari Stormy Monday and or Thunderstorm. Was working weeks ago. Thanks -- Best regards, Henri, aka Alva Official grtux hangar maintainer -- 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] Adventures in dds
I've been doing some tests with dds textures too, only in the airplane models, and there's an increase in both performance and quality. Take the IAR-80 for example, changing liveries with .png textures takes ~6 seconds, while with the dds texture it takes ~2seconds. The increase in file size is of about one third: .png - ~12.5 MB .dds - 16 MB But what nails it for me is the quality of the normalmap effect, wich for the same texture shows a dramatic improvement. You may want to check this post I've made yesterday on the forums for some visual comparisons: http://flightgear.org/forums/viewtopic.php?p=118570#p118570 Is it just me, or is the graphic engine performing some kind of cheap texture compression? (Maybe that's why you did't notice any performance improvement). -- 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] Adventures in dds
woops sorry, link was to the last post instead of the right one: http://flightgear.org/forums/viewtopic.php?p=118547#p118547 -- 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] Auto-hiding the cursor ;-)
I wonder if it might be OSX specific. The cursor hides just fine for me here, and reappears at the touch of the mouse. Also, I get the correct cursor shape changes when right clicking. It could also be OSG version related? I'm running OSG-2.9.7 here on this machine and haven't upgraded in a while. I have up to date git for simgear/flightgear. Fedora 14 (nvidia graphics also with latest drivers as of yesterday.) Regards, Curt. On Mon, Mar 21, 2011 at 5:39 AM, HB-GRAL flightg...@sablonier.ch wrote: Am 21.03.11 09:13, schrieb HB-GRAL: Hi all There is a nice new feature now with hiding the cursor. Ok, it is hard for new users to get the cursor back, I think it is wrong to set the hiding after 10 seconds to default. Maybe there are other ways to show this nice new feature ;-) Anyway I have to throw the mouse to the wall here to get the cursor back in screen. Maybe it should come back earlier. A newer issue is that the cursor does not change the form anymore when I do right clicks ? Also control-key-c is disabled on OSX, but that I will investigate further. Cheers, 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 I reported this to the bug tracker, maybe it’s a OSX/Carbon specific issue? Hope not. Cheers, 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/ -- 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] Adventures in dds
Maybe you already did this, but this needs a 'average of 3' (or 5) tests, because I would be very surprised if the input file format changes the final frame-rate after loading - it's all uncompressed to the same format in GPU memory, as far as I know. Yes, I checked it (I couldn't believe it...). Just *maybe* the conversion by gimp screwed the pnd file and altered the texture somehow, so that all derived from the png is then problematic (?). But the effect as far as my procedure is described is real. The PNG loading time also seems suspicious - decompressing a PNG is certainly more work than RGB or DDS, but decompressing a 1MB PNG shouldn't take even one second on a computer of the past few years. Yes - now multiply this by 2500 since it's done for every cloud being loaded, and you get a large number. Of course the system *should* realize that it has the texture loaded already and doesn't need to load it any more, but evidence suggest that it actually decompresses 2500 times. Cheers, * Thorsten -- 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
[Flightgear-devel] [OT] Best pratice for debugging multi threaded programs?
Hi all, sorry - a little bit off-topic (in fact not so much as you might think, it's for a third-party software for FG): Has anyone some hints/websites/programs for debugging C -based multi threaded programs (exactly: glib based C code)? Currently I am developing with vi and a little bit gdb (command line) and very much debug output. But this setup seems to be very frustrating while searching for dead-locks and race-conditions :-( On the other hand I won't invest too much time for studying rocket engeneering only to use framework XYZ. Has anyone some ideas how to debug with less effort? Thanks, Holger -- 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] Adventures in dds
Here is one thing to consider when dealing with texture files, OpenGL, and scene graphs (like OSG or PLIB.) OpenGL has a concept called mip-mapping. When a texture is loaded, successively smaller versions are generated automatically using a simple box filter. So if you start with a 256x256 original texture, the system builds a 128x128, 64x64, 32x32 ... etc. down to a 1x1 I believe. For each smaller version, 1 pixel is the average of 4 pixels in the next size up. This scheme works pretty ok for most picture type textures and it happens automatically so artists don't have to worry about it. Then when rendering a scene, the opengl system automatically chooses the mipmap level (texture size) that best fits the triangle it is getting applied to ... has a closest to 1-to-1 match with screen space pixels. This helps prevent aliasing artifacts or texture swimming effects that you might remember from older games. Where this can lead to problems is with textures that have transparency (i.e. an alpha channel.) The box filter scheme of generating successively smaller versions of the texture doesn't work well with the alpha layer. The transition from fully opaque to fully transparent gets wider and wider relative to the overall texture and can lead to problems. More generally, the default box filter scheme of generating the smaller versions of the texture files is very simple and usually not quite optimal, and is definitely non-optimal when working with textures that have a transparency layer. In addition, the mipmaps are generally computed in software when the texture is loaded which takes some time. I suspect that some of these fancier formats might have the mipmap layers pre-computed using a more sophisticated size reducing scheme -- thus producing slightly better visual results in the end. Regards, Curt. On Mon, Mar 21, 2011 at 9:14 AM, thorsten.i.r...@jyu.fi wrote: Maybe you already did this, but this needs a 'average of 3' (or 5) tests, because I would be very surprised if the input file format changes the final frame-rate after loading - it's all uncompressed to the same format in GPU memory, as far as I know. Yes, I checked it (I couldn't believe it...). Just *maybe* the conversion by gimp screwed the pnd file and altered the texture somehow, so that all derived from the png is then problematic (?). But the effect as far as my procedure is described is real. The PNG loading time also seems suspicious - decompressing a PNG is certainly more work than RGB or DDS, but decompressing a 1MB PNG shouldn't take even one second on a computer of the past few years. Yes - now multiply this by 2500 since it's done for every cloud being loaded, and you get a large number. Of course the system *should* realize that it has the texture loaded already and doesn't need to load it any more, but evidence suggest that it actually decompresses 2500 times. Cheers, * Thorsten -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/ -- 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] [OT] Best pratice for debugging multi threaded programs?
Hi Holger, This is a very interesting question. I don't have any good answers, so I am looking forward to seeing if anyone else on the list has any good methodologies or even small hints and tips they can suggest. I could stand up on my soap box here and give my long speech on threading architectures ... but I'll spare everyone. :-) The summary though is that threaded architectures add complexity and can create timing bugs or order dependent bugs. The end result can be a system that works most of the time, and then randomly crashes for no apparent reason. Often it can take hours (if not days or weeks) of running the code to tickle the bug ... and most of the time you have to trigger the bug to see what happened and get any kind of idea where it happened so you can fix it. Also, even with a perfectly written threaded system, it's easy to come back in 6 months and forget something about the design and make a change that introduces a subtle problem. This is even more likely if someone else comes later and touches the code without having ever understood all the nuances (sequence, and timing, etc.) of how all the threads work together. Personally I try to avoid threads whenever possible, and only use them when there is no sane alternative solution. But I understand that threads are a fact of life so they can't always be avoided. When I've had to debug threaded code I've used a mix of gdb (and compiling everything with full debugging symbols) to get a back trace if there is a crash. I also like to use printf's to see the sequence or progress of the code as it runs. If I get desperate I might haul out valgrind and see if that offers any clues. I've also spent hours just staring at the code and mentally working through the sequencing of the threads and the locking/mutual-exclusion primatives trying to analyze it all in my head and look for logic bugs that way. All of this is pretty tedious, un-fun stuff. Maybe someone else has other tips and tricks. I don't think I've run across any higher level methodologies that you can work through to always sniff out any threading bug. I know other people may feel differently about the use of threads and their relative benefits and dangers ... and that's fine. I like to think of threads like nun-chucks. I'll probably get moved over to the soprano section of the choir before I manage to do anything useful too spectacular with them. :-) Curt. On Mon, Mar 21, 2011 at 9:04 AM, Holger Wirtz wrote: Hi all, sorry - a little bit off-topic (in fact not so much as you might think, it's for a third-party software for FG): Has anyone some hints/websites/programs for debugging C -based multi threaded programs (exactly: glib based C code)? Currently I am developing with vi and a little bit gdb (command line) and very much debug output. But this setup seems to be very frustrating while searching for dead-locks and race-conditions :-( On the other hand I won't invest too much time for studying rocket engeneering only to use framework XYZ. Has anyone some ideas how to debug with less effort? Thanks, Holger -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/ -- 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] FlightGear at LinuxTag and FSWeekend need
Reagan Thomas wrote: Did you get enough donations to buy the new equipment? Not yet. We're currently at 285,68 Euros of donated money and the absolute minimum for a 24 inch screen is slightly above 150 Euros (at least in our country), the 1920x1200 screens (of which we already have six) are even more expensive. We'd need at least two additional ones for the 'large' setup but having another three for the smaller, second pilot seat would be nice. Currently we're trying to figure out if we can get our hands on used equipment in order to lower the costs. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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] Adventures in dds
Hello, Where this can lead to problems is with textures that have transparency (i.e. an alpha channel.) The box filter scheme of generating successively smaller versions of the texture doesn't work well with the alpha layer. The transition from fully opaque to fully transparent gets wider and wider relative to the overall texture and can lead to problems. More generally, the default box filter scheme of generating the smaller versions of the texture files is very simple and usually not quite optimal, and is definitely non-optimal when working with textures that have a transparency layer. In addition, the mipmaps are generally computed in software when the texture is loaded which takes some time. So this is the explanantion of decreasing fps with textures with transparency? Comparing with other games/sims I'm surprised that it is so much noticeable in FGFS. I suspect that some of these fancier formats might have the mipmap layers pre-computed using a more sophisticated size reducing scheme -- thus producing slightly better visual results in the end. Slightly? Have you seen the pictures comparing .png vs .dds? This is more than slightly! Indeed .dds creates mipmap layers while converting to it. The qualitity is much better, loading seems to be much smaller compared with .png. Indeed nearly all commercial games and sims uses .dds. The only disadvantage I can see and that's why I never considered yet to use it is the fact that the size itself is increasing. As we have people here which consider space saving more important than qualitity I feared that it could lead to problems. Regards Heiko Regards, Curt. On Mon, Mar 21, 2011 at 9:14 AM, thorsten.i.r...@jyu.fi wrote: Maybe you already did this, but this needs a 'average of 3' (or 5) tests, because I would be very surprised if the input file format changes the final frame-rate after loading - it's all uncompressed to the same format in GPU memory, as far as I know. Yes, I checked it (I couldn't believe it...). Just *maybe* the conversion by gimp screwed the pnd file and altered the texture somehow, so that all derived from the png is then problematic (?). But the effect as far as my procedure is described is real. The PNG loading time also seems suspicious - decompressing a PNG is certainly more work than RGB or DDS, but decompressing a 1MB PNG shouldn't take even one second on a computer of the past few years. Yes - now multiply this by 2500 since it's done for every cloud being loaded, and you get a large number. Of course the system *should* realize that it has the texture loaded already and doesn't need to load it any more, but evidence suggest that it actually decompresses 2500 times. Cheers, * Thorsten -- 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 -- Curtis Olson:http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ -Integrierter Anhang folgt- -- 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 -Integrierter Anhang folgt- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- 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] Auto-hiding the cursor ;-)
Am 21.03.11 14:17, schrieb Curtis Olson: I wonder if it might be OSX specific. The cursor hides just fine for me here, and reappears at the touch of the mouse. Also, I get the correct cursor shape changes when right clicking. It could also be OSG version related? I'm running OSG-2.9.7 here on this machine and haven't upgraded in a while. I have up to date git for simgear/flightgear. Fedora 14 (nvidia graphics also with latest drivers as of yesterday.) Regards, Curt. Thanks Curt, I might have a look to this later. I am actually running OSG 2.9.9. -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] Adventures in dds
On Mon, Mar 21, 2011 at 9:52 AM, Heiko Schulz wrote: So this is the explanantion of decreasing fps with textures with transparency? Comparing with other games/sims I'm surprised that it is so much noticeable in FGFS. No, this is another issue I believe. When the opengl system draws a triangle with a texture that has some transparency, it needs to read back in the current color buffer and mix the pixels of the new surface with the pixels that have already been drawn before. This takes longer (sometimes *much* longer) than just writing out solid pixels. If you dig into how modern 3d hardware works, you'll fine a lot of parallelization and multiple cores. Your 3d card is really a whole computer itself. OpenGL is carefully designed so that the application can send a set of commands to the hardware and the hardware figures out the best way to render them. The problem with alpha textures is that they can disrupt the fastest pipeline operations, certain draw commands need to finish before the next one can start. I don't know if there are good ways to avoid this other than to try to minimize the amount of transparency we use. Clouds are especially bad because we stack many many layers of partially transparent surfaces on top of each other and we end up having to render the same pixels on the screen many many times over ... and do that with a slower, harder-to-optimize rendering path. There are probably tricks that could be used. I recently saw a demo engine (used for benchmarking graphics cards and systems). I forget the name now, but it was amazing. I need to start learning some of their tricks ... blades of grass waving in the breeze with dynamic shadows being cast over them from everything else in the scene ... beautiful clouds, amazing lighting effects, really cool and realistic material surface effects (like weathered/beaten metal fittings on a ship, etc.) They didn't do any reflection/glass effects though in that demo so we had them beat there. :-) The only disadvantage I can see and that's why I never considered yet to use it is the fact that the size itself is increasing. As we have people here which consider space saving more important than qualitity I feared that it could lead to problems. Most likely due to the fact that it is storing all the smaller versions of the texture along with the original ... that makes sense though because if it didn't store the mipmaps, then we'd be back to the same low quality default box filter. These days I tend to lean towards the disk space is cheap camp. (But anything taken to it's extreme is probably not good.) Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/ -- 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] Adventures in dds
Just to add to the fun, .dds has an added benefit that I didn't see mentioned here-- unlike other formats, .dds has the ability to store textures compressed in memory, not just on disk. This can result in a considerable savings of graphic card RAM. Most .dds formats are lossy though, which requires some consideration and care. The .dds format is natively supported on graphics cards, which accounts for much of the speed given all that is happening. I'm not particularly advocating .dds, but it's worth considering for certain applications, especially where large numbers of textures are used for a similar task. -Gary aka Buckaroo -- 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] Adventures in dds
Regarding mipmaps, all the pictures in the post on the forum are done without mipmaps in the dds (-nomips option in nvcompress). Just done a couple more tests, this time with pregenerated mipmaps, and texture loading time when switching liveries is 1s, with instant swithcing in subsequent runs (the first time i suspect the delay to be in fact the disk read wich is slow). So much of the texture loading time is in fact spent by the gpu (or cpu?) in genertaing mipmaps from the texture.. time we can spend just once when creating the texture. (This is done with a big 4096x4096 texture ;) ) With the clouds issue, I have this feeling that something is amiss with the way clouds are generated, but i can't put my finger on it.. :(. Thorsten, have you done the same test with individual textures instead of a big one ? -- 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] Adventures in dds
Hi, So much of the texture loading time is in fact spent by the gpu (or cpu?) in genertaing mipmaps from the texture.. time we can spend just once when creating the texture. (This is done with a big 4096x4096 texture ;) ) Yep, texture size is higher at the end, but perfomance is better. And I guess the latter is more important in my eyes. With the clouds issue, I have this feeling that something is amiss with the way clouds are generated, but i can't put my finger on it.. :(. Thorsten, have you done the same test with individual textures instead of a big one ? Taking a closer look on the Local Weather, I can see that each cloud is placed per .xml. Or better said: you can take the UFO and place each of the clouds in the scenery. But the fact is, the more .xml has to be loaded the more slower FGFS runs. That's one issue behind making Paris unusuable for most of our users. Heiko -- 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] FlightGear launcher for snapshots/2.2 preview OSX
Hi Yves, Yves wrote: At the moment it is not cross-platform, unfortunately. I didn’t get QProcess to work here so I write to bash scripts and start this scripts via system() and terminal appplication on OSX. This works for OSX, but the whole part for starting fgfs with args should be rewritten I think. I was able to build it on Windows and use the launcher, but, as expected it was unable to launch FlightGear (and I think some features of the launcher are also broken on Win). At least it looks like a nice and promising launcher! I am currently working on a Qt based TerraGear GUI, and was able to use QProcess in it. Seems to be working on both Windows and Linux (altough I don't have Linux myself, there was someone that tested it with succes on Linux)... Maybe you'd like to take a look at my use of QProcess and try it out in your launcher? Source is up at http://gitorious.org/terragear/terrageargui (please ignore the somewhat unclear code; I will optimise it when everything works :P ) Cheers, Gijs -- 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] Adventures in dds
With the clouds issue, I have this feeling that something is amiss with the way clouds are generated, but i can't put my finger on it.. :(. Thorsten, have you done the same test with individual textures instead of a big one ? Huh? Not sure what you mean, I don't think I have a single instance of just one cloud on a texture. altocumulus_textures.rgb is a sheet containing 9 different textures referenced by 10 distinct 2-layer *.ac models - all of which are part of the 2500 cloud sheet being generated. So the sheet contains about ~250 identical copies of each of the 10 distinct models. Can you be more specific what you'd like to test. Taking a closer look on the Local Weather, I can see that each cloud is placed per .xml. Or better said: you can take the UFO and place each of the clouds in the scenery. Quite so. But the fact is, the more .xml has to be loaded the more slower FGFS runs. That's one issue behind making Paris unusuable for most of our users. That's (at best) part of the issue: When I replace the rgb by a png or dds texture, the xml wrapper stays the same - and yet I see 1/3 difference in rendering speed of the final result and dramatic differences in loading speeds. I don't know what that has to do with xml - it seems generic that if I increase the number of objects to render, the framerate drops. I can see the same thing with trees (which to my knowledge are not xml-wrapped models) - if I increase tree density by a factor 10, I see my framerate drop like a rock. 5000 additional models in the scenery will affect framerate, quite possibly inversely proportional to their texture quality and proportional to the operations required by the relevant shader - regardless if that's houses or clouds. The system (as far as my experience goes) isn't particularly slow in rendering the clouds once they are in the scene. It is slow in placing them into the scene - dramatically slower (a factor 1000 or so) than with the standard 3d clouds. If you want to call that 'wrong' is in the eye of the beholder - that's how the interface for model placement from Nasal is at present. That slowdown for sure is generic for the way models are placed from Nasal - something appears to be *very* inefficient with that. I am rather skeptical if it's to be blamed on the xml wrapper - I see no supporting evidence. The dependence on texture type and detail level suggests to me that it's about uncompressing and loading textures into the GPU memory. As a side note, loading speeds depend on the presence/absence of a second available CPU. Not sure what that means. My problem is that I have no real knowledge about 3d rendering. I can do the experiments and know what scales with what, but I lack the theory to understand what is going on behind the scenes. * Thorsten -- 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] Local weather ??????
when playing with the Local weather menu, i get the following message Nasal runtime error: setprop() value is not string or number at /../data/Nasal/weather_tile_management.nas, line 189 called from: /../data/Nasal/local_weather.nas, line 2964 called from: /../data/Nasal/local_weather.nas, line 3780 called from: /./data/Nasal/globals.nas, line 100 Is it a Bug ? , Is it just me. ? I'm unable to understand what caused the error just by the message - I need to know what the nature of your 'playing around' was and I need the log output of Local Weather itself (= tick the option box). I haven't pulled all the files back from GIT yet, but my local development copy of the Nasal files which is almost identical to the one I packaged don't show an obvious problem. * Thorsten -- 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] Adventures in dds
On Monday 21 March 2011 19:53:36 thorsten.i.r...@jyu.fi wrote: With the clouds issue, I have this feeling that something is amiss with the way clouds are generated, but i can't put my finger on it.. :(. Thorsten, have you done the same test with individual textures instead of a big one ? Huh? Not sure what you mean, I don't think I have a single instance of just one cloud on a texture. altocumulus_textures.rgb is a sheet containing 9 different textures referenced by 10 distinct 2-layer *.ac models - all of which are part of the 2500 cloud sheet being generated. So the sheet contains about ~250 identical copies of each of the 10 distinct models. Can you be more specific what you'd like to test. Well that's exactly what I was proposing you to test, split the big texture into 9 smaller ones, thus making 1texture/model. If the graphic engine is somehow being stupid and forgets that it has already loaded that texture we should see a dramatic improvement in performance and loading time. (instead of loading one big texture thousand of times, we're loading smaller bits of it). If the performance stays the same, that means the problem lies elsewhere in the model placement pipeline. -- 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] Adventures in dds
Hello, I don't know what that has to do with xml - it seems generic that if I increase the number of objects to render, the framerate drops. I can see the same thing with trees (which to my knowledge are not xml-wrapped models) - if I increase tree density by a factor 10, I see my framerate drop like a rock. 5000 additional models in the scenery will affect framerate, quite possibly inversely proportional to their texture quality and proportional to the operations required by the relevant shader - regardless if that's houses or clouds. With 1.9.1 there wasn't a big difference between placing pure .ac-models and .xml-wrapped models into scenery. Both had the same fps. Now it is different. The same number of .ac-models will give higher fps than the same number of wrapped .xmls. The system (as far as my experience goes) isn't particularly slow in rendering the clouds once they are in the scene. It is slow in placing them into the scene - dramatically slower (a factor 1000 or so) than with the standard 3d clouds. If you want to call that 'wrong' is in the eye of the beholder - that's how the interface for model placement from Nasal is at present. Hmm... I did not have found time for a detailed table of fps comparement, but it seems to me that some of your clouds are decreasing fps more than the default 3d-clouds. It looked different to me at the beginning, but making some videos showed me this. That slowdown for sure is generic for the way models are placed from Nasal - something appears to be *very* inefficient with that. I am rather skeptical if it's to be blamed on the xml wrapper - I see no supporting evidence. The dependence on texture type and detail level suggests to me that it's about uncompressing and loading textures into the GPU memory. If I'm right, .xmls and nasal are handeld by the CPU. The Default clouds are mostly done by the GPU. Heiko -- 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] Adventures in dds
Hmm... I did not have found time for a detailed table of fps comparement, but it seems to me that some of your clouds are decreasing fps more than the default 3d-clouds. It looked different to me at the beginning, but making some videos showed me this. If you use default settings, you're comparing 20 km visibility with 35 km - that's 400 km^2 vs 1225 km^2 of cloud covered scene, or a factor 3. If you place the same number of clouds, I guess the fact that I use sometimes ~4 times higher texture resolution is bound to show. You possibly initially saw higher framerates around TNCM because Local Weather doesn't place many convective clouds over open water. I decided that a fair comparison is: Same scenery, same visibility, same cloud visibility, same cloud coverage in oktas, no wind drift. Under these conditions, local weather was 10% slower for a Cumulus layer in my tests. If you ask for overcast skies, than Local Weather is dramatically faster (the default clouds for me are unable to even render a decent 6/8 cover, and with the densest coverage I can get I get single digit framerates while passing through the layer - that's a factor 3 or more slower than Local Weather where I routinely get 20+ fps in rainy overcast conditions, more above the layer where the terrain isn't visible ). If you fly supersonic, then you're not dominated by rendering but by loading/unloading... and so on. So it's not clear to me what your standard of comparison is, and it's not a trivial question what it should be. But some cloud configurations (Coldfront, Tropical) are much slower than the standard 3d cloud Cumulus layer. But that's an apples/oranges comparison if you ask me. * Thorsten -- 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] Instant replay and JSBSim aircraft
Hi, not sure if anyone else had a chance to test the instant replay with JSBSim aircraft - but it indeed seems like a general issue to me. It's triggered by JSBSim doing a trim operation once playback has finished - which produces an output like this (with the F16 in this case): Trim Results: Altitude AGL: 15 wdot: -1.83e+08 Tolerance: 1e-03 Failed Pitch Angle:-19 qdot: 9.33e+07 Tolerance: 1e-04 Failed Trim Statistics: Total Iterations: 61 Sub-iterations: wdot: 0 average: 0 successful: 0 stability: 3.5272 qdot: 0 average: 0 successful: 0 stability: 3 Run Count: 1201 Soon afterwards, the entire sim locks up since the FDM numerics go wild. I can avoid this issue by suppressing the re-trim when replay has finished (by forcing needTrim = false; in the code). All works well for me then - but it completely kills the needTrim feature in JSBSim, which was probably implemented for a reason... The trim is triggered since the FDM still has its property listeners connected during replay - so it thinks the aircraft position changes, which sets the FDM's needTrim flag. Might be a good idea to disconnect the FDM property ties during a replay - but JSBSim currently doesn't allow to reconnect the ties (bind method is not implemented). And the basic problem here probably is just that something with re-trimming an aircraft doesn't work properly. Any ideas on what could go wrong when the FDM tries to trim an already trimmed aircraft? cheers, Thorsten On Sun, Mar 20, 2011 at 12:48 PM, ThorstenB bre...@gmail.com wrote: I'm seeing an issue with the instant replay feature which seems to affect JSBSim aircraft. The actual replay works, but once replay is finished, the sim locks up or goes wild when trying to resume normal flight. Looks to me as if the FDM was somehow messed up by the replay. The FDM's update is suspended during replay - but I suspect there may be an issue with the tied properties, which still allow the FDM to see the replayed movements. YASim aircraft seem to be fine though. -- 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] Quiet
Quiet?? Who said quiet? :-) -- 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] Auto-hiding the cursor ;-)
Just to report: It’s a OSG 2.9.9 issue on OSX, was going back to 2.9.7 and all works fine. Also the keyboard input. (I am a victim of the wiki too now :-P , I wrote myself months ago 2.9.7 is needed and someone changed requirement for OSX 10.6 to OSG 2.9.9. Don’t know the reason for this, but beside that, I guess the nightlies based on 2.9.9 are also not working correctly ?) Cheers, Yves Am 21.03.11 15:57, schrieb HB-GRAL: Am 21.03.11 14:17, schrieb Curtis Olson: I wonder if it might be OSX specific. The cursor hides just fine for me here, and reappears at the touch of the mouse. Also, I get the correct cursor shape changes when right clicking. It could also be OSG version related? I'm running OSG-2.9.7 here on this machine and haven't upgraded in a while. I have up to date git for simgear/flightgear. Fedora 14 (nvidia graphics also with latest drivers as of yesterday.) Regards, Curt. Thanks Curt, I might have a look to this later. I am actually running OSG 2.9.9. -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 -- 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] Adventures in dds
Heiko wrote, I don't know what that has to do with xml - it seems generic that if I increase the number of objects to render, the framerate drops. I can see the same thing with trees (which to my knowledge are not xml-wrapped models) - if I increase tree density by a factor 10, I see my framerate drop like a rock. 5000 additional models in the scenery will affect framerate, quite possibly inversely proportional to their texture quality and proportional to the operations required by the relevant shader - regardless if that's houses or clouds. With 1.9.1 there wasn't a big difference between placing pure .ac-models and .xml-wrapped models into scenery. Both had the same fps. Now it is different. The same number of .ac-models will give higher fps than the same number of wrapped .xmls. The system (as far as my experience goes) isn't particularly slow in rendering the clouds once they are in the scene. It is slow in placing them into the scene - dramatically slower (a factor 1000 or so) than with the standard 3d clouds. If you want to call that 'wrong' is in the eye of the beholder - that's how the interface for model placement from Nasal is at present. Hmm... I did not have found time for a detailed table of fps comparement, but it seems to me that some of your clouds are decreasing fps more than the default 3d-clouds. It looked different to me at the beginning, but making some videos showed me this. That slowdown for sure is generic for the way models are placed from Nasal - something appears to be *very* inefficient with that. I am rather skeptical if it's to be blamed on the xml wrapper - I see no supporting evidence. The dependence on texture type and detail level suggests to me that it's about uncompressing and loading textures into the GPU memory. If I'm right, .xmls and nasal are handeld by the CPU. The Default clouds are mostly done by the GPU. I still have some old textures in Git that I have not yet changed over to .png. Do I take it from these discussions that it would be best to leave them as is? I'm right in the middle of texturing a new model. .dds is not an option because it looks as if the loader has some co-ordinate issues. It looks OK in AC3D, but when loaded in FG it's wrong. Should I revert to .rgb rather than use .png? Vivian -- 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] Adventures in dds
Vivian, I'm right in the middle of texturing a new model. .dds is not an option because it looks as if the loader has some co-ordinate issues. It looks OK in AC3D, but when loaded in FG it's wrong. Should I revert to .rgb rather than use .png? Vivian You have to flip the .dds-texture vertically after converting to it. That's due to OpenGL. -- 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] Adventures in dds
Heiko, -Original Message- From: Schulz [mailto:aeitsch...@yahoo.de] Sent: 21 March 2011 20:35 To: vivian.mea...@lineone.net; FlightGear developers discussions Subject: Re: [Flightgear-devel] Adventures in dds Vivian, I'm right in the middle of texturing a new model. .dds is not an option because it looks as if the loader has some co-ordinate issues. It looks OK in AC3D, but when loaded in FG it's wrong. Should I revert to .rgb rather than use .png? Vivian You have to flip the .dds-texture vertically after converting to it. That's due to OpenGL. A simple vertical flip doesn't seem to work - it looks a bit more like a scaling issue here. Perhaps I need some tool? Vivian -- 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
[Flightgear-devel] Texture cache (was: Adventures in dds)
Hi. Inspired by the talk in the dds thread about cloud performance and other things, I did some quick grepping through the source about textures. I found out FG/SG has at least 5 different way of storing textures: 1. FGTextureManager in FG's Cockpit/panel.*, which at least tries to keep track of texture files which are loaded and should not load them again. This is used in some instruments and 2d panel? 2. Effects (SG: scene/material/TextureBuilder.*) have their own texture cache which reloads textures only if their parameters in effect file changes. Seems to reload the texture if e.g. clamping changes? 3. Material library (scene/material/mat.*) which handles the materials.xml. This one seems to use TextureBuilder so it might load the iamges only once, if all parameters are the same. 4. Individual pointer in subsystems. At least sky elements, splash screen, maybe trees and clouds etc use these. Texture pointers are stored inside the class and they are not exposed for other systems to use. 5, maybe worst: osg plugins which load 3d models seem to load textures directly and store them... somewhere. So no caching, if two models use the same texture it gets always loaded, no matter what. I think the problem with local weather could be that the models are always re-loaded and that's why the osg plugin re-loads the textures too... I checked some models in Models/Weather and they do point to the textures. I think this is quite a big mess currently. I think there should be only one place to store the images (maybe just the images, even if other texturing parameters change?) which should be used everywhere and the textures should be exposed so that the same image can be used in effects or animations or wherever necessary. Any thoughts on this and how to solve it? - Lauri Peltonen, Zan -- 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
[Flightgear-devel] OSG version (was Auto-hiding the cursor)
On 21.03.2011 21:04, HB-GRAL wrote: Just to report: It’s a OSG 2.9.9 issue on OSX, was going back to 2.9.7 and all works fine. Also the keyboard input. (I am a victim of the wiki too now :-P , I wrote myself months ago 2.9.7 is needed and someone changed requirement for OSX 10.6 to OSG 2.9.9. Don’t know the reason for this, but beside that, I guess the nightlies based on 2.9.9 are also not working correctly ?) htgear-devel Until some weeks ago, there was a standard recommendation in the wiki to use latest OSG-svn when running FG git (actually in several places in the wiki). But using the bleeding edge OSG sources causes issues, since OSG development is pretty active and they have frequent changes. There is no way we could keep up/test those changes on weekly/daily/hourly notice. And sometimes OSG itself is also introducing new bugs in their code (like this probably: http://code.google.com/p/flightgear-bugs/issues/detail?id=268). Recently we've seen many people reporting issues due to unstable OSG - both, in the tracker and on the mailing list. Also, we found that any normally advanced FG git user doesn't even need to run the very latest OSG sources. Those very few who actually need it (i.e. in order to adapt FlightGear), know anyway what to do (hey Tim! :) ). So, after some discussion we decided to recommend the latest _stable_ OSG release by default (which still is OSG2.8.3). And for those, who really want to be a guinea pig and test the OSG-developer versions, we found that 2.9.9 was the latest (at the time) which was working with Linux/Mac/Windows (reported by several people on irc including Tim/James, I think). That's why the wiki was changed (default: 2.8.3, and 2.9.9 for keen developers). And it was me updating the OSG wiki page: http://wiki.flightgear.org/index.php/OSG Personally, I prefer to stick with OSG stable (2.8.3) - which works great for me. There are still enough issues in FG git itself to worry about... ;-) I just noticed though, that a number of wiki pages again returned to recommend the use of latest OSG-svn *sigh*. I don't know why people keep recommending that... cheers, Thorsten -- 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] Adventures in dds
On Monday 21 March 2011 23:02:18 Vivian Meazza wrote: A simple vertical flip doesn't seem to work - it looks a bit more like a scaling issue here. Perhaps I need some tool? Use nvcompress from the nvidia-texture-tools: i.e. nvcompress -bc3 -repeat your-flipped-texture.png your-texture.dds If it's a normalmap use : nvcompress -normal -bc5 -repeat your-flipped-texture.png your-texture.dds but you'll have to flip the normal in the shader. i.e. for the reflect-bump-spec.frag add a line after line 47: n = -n; HTH Emilian -- 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] Adventures in dds
A simple vertical flip doesn't seem to work - it looks a bit more like a scaling issue here. Perhaps I need some tool? Vivian Maybe this helps you: http://www.flightgear.org/forums/viewtopic.php?f=4t=7225start=135#p118570 -- 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] Adventures in dds
Heiko, Vivian, I'm right in the middle of texturing a new model. .dds is not an option because it looks as if the loader has some co-ordinate issues. It looks OK in AC3D, but when loaded in FG it's wrong. Should I revert to .rgb rather than use .png? Vivian You have to flip the .dds-texture vertically after converting to it. That's due to OpenGL. Here's the AC3D version: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_AC3D.png And here's what I see in FG: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_FlightGear.png Vivian -- 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] Adventures in dds
On Monday 21 March 2011 23:47:51 Vivian Meazza wrote: Here's the AC3D version: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_AC3D.png And here's what I see in FG: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_FlightGear.png Vivian That's exactly what me and Heiko were saying, you need to flip the texture vertically, BEFORE converting it to a .dds. -- 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] Adventures in dds
-Original Message- From: Emilian Huminiuc [mailto:emili...@gmail.com] Sent: 21 March 2011 22:00 To: vivian.mea...@lineone.net; FlightGear developers discussions Subject: Re: [Flightgear-devel] Adventures in dds On Monday 21 March 2011 23:47:51 Vivian Meazza wrote: Here's the AC3D version: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_AC3D.png And here's what I see in FG: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_FlightGear.png Vivian That's exactly what me and Heiko were saying, you need to flip the texture vertically, BEFORE converting it to a .dds. Heiko said this: You have to flip the .dds-texture vertically after converting to it So that what I did. Now I'll try it the other way. Vivian -- 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] Adventures in dds
That's exactly what me and Heiko were saying, you need to flip the texture vertically, BEFORE converting it to a .dds. I meant BEFOR but did say after... My fault. Oops! -- 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] Adventures in dds
On Monday 21 March 2011 23:47:51 Vivian Meazza wrote: Vivian, Here's the AC3D version: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_AC3D.png And here's what I see in FG: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_FlightGear.png Vivian The workflow would be like this, you map the model onto a .png texture. You finish drawing the texture, and before loading it into flightgear these two steps should be the last ones: You flip that texture verticaly (in gimp for example), then you convert the flipped texture to .dds. -- 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
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] Adventures in dds
I wrote: -Original Message- From: Emilian Huminiuc [mailto:emili...@gmail.com] Sent: 21 March 2011 22:00 To: vivian.mea...@lineone.net; FlightGear developers discussions Subject: Re: [Flightgear-devel] Adventures in dds On Monday 21 March 2011 23:47:51 Vivian Meazza wrote: Here's the AC3D version: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_AC3D.png And here's what I see in FG: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_FlightGear.png Vivian That's exactly what me and Heiko were saying, you need to flip the texture vertically, BEFORE converting it to a .dds. Heiko said this: You have to flip the .dds-texture vertically after converting to it So that what I did. Now I'll try it the other way. Makes no difference flipping before conversion or after - Looks OK in AC3D, but not in FG. So it doesn't look like .dds is a proper option without further work. Vivian -- 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] Adventures in dds
The workflow would be like this, you map the model onto a .png texture. You finish drawing the texture, and before loading it into flightgear these two steps should be the last ones: You flip that texture verticaly (in gimp for example), then you convert the flipped texture to .dds. There is just one problem though: The Hudson Nightly Builds for win32 doesn't contain the .ddls for .dds Report to Bugtracker? -- 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] Adventures in dds
Emilian, On Monday 21 March 2011 23:47:51 Vivian Meazza wrote: Vivian, Here's the AC3D version: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_AC3D.png And here's what I see in FG: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_FlightGear.png Vivian The workflow would be like this, you map the model onto a .png texture. You finish drawing the texture, and before loading it into flightgear these two steps should be the last ones: You flip that texture verticaly (in gimp for example), then you convert the flipped texture to .dds. OK, I'll try that Vivian -- 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] Adventures in dds
Hi, Makes no difference flipping before conversion or after - Looks OK in AC3D, but not in FG. So it doesn't look like .dds is a proper option without further work. Vivian You must doing something wrong. here for Gimp, assumed that you have the plugin needed already: 1.) UVmap the aircraft in ac3d as usual with your png-file Then: 1) Take the .png-file you want convert 2)Image -- Transformation --Mirror (flip?)vertical 3)Save as name.dds 4.)a popup appears, select DXT5 and check mipmap 5) click o.k. Open the .ac-file with a text-editor and just change name.png to name.dds -- 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] Adventures in dds
Heiko, -Original Message- From: Schulz [mailto:aeitsch...@yahoo.de] Sent: 21 March 2011 22:32 To: vivian.mea...@lineone.net; FlightGear developers discussions Subject: Re: [Flightgear-devel] Adventures in dds Hi, Makes no difference flipping before conversion or after - Looks OK in AC3D, but not in FG. So it doesn't look like .dds is a proper option without further work. Vivian You must doing something wrong. here for Gimp, assumed that you have the plugin needed already: 1.) UVmap the aircraft in ac3d as usual with your png-file Then: 1) Take the .png-file you want convert 2)Image -- Transformation --Mirror (flip?)vertical 3)Save as name.dds 4.)a popup appears, select DXT5 and check mipmap 5) click o.k. Open the .ac-file with a text-editor and just change name.png to name.dds Nope, doesn't work. But this does: Map the .png file onto the AC3D model as usual - convert the .png into .dds in XnView - load the .dds into AC3D No flipping of vertical required. Perhaps XnView flips it for us? Vivian -- 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
[Flightgear-devel] Aileron and Rudder Trim indicators for the default HUD
I have added a couple of small indicators to the standard HUD, with the same format as that used for the pitch trim indicator. Attached is a patch with my small modification. It's really quite a small modification, but I find it useful mainly for helicopters, and since it's of little consequence for anything else and doesn't add much to the clutter I tought I'd submit it for review. Cheerio, Alessandro Garosi (Brandano on IRC) diff --git a/Huds/Sets/controls.xml b/Huds/Sets/controls.xml index 487e720..a1adc96 100644 --- a/Huds/Sets/controls.xml +++ b/Huds/Sets/controls.xml @@ -143,63 +143,4 @@ min-1.0/min /input /gauge - - gauge - nameRudder Trim/name - x-50/x - y-100/y - width100/width - height10/height - optionbottom/option - optionhorizontal/option - optionnotext/option - major-divisions50/major-divisions - minor-divisions0/minor-divisions - marker-offset0.0/marker-offset - tick-bottomfalse/tick-bottom - tick-topfalse/tick-top - tick-rightfalse/tick-right - tick-leftfalse/tick-left - cap-bottomfalse/cap-bottom - cap-topfalse/cap-top - cap-rightfalse/cap-right - cap-leftfalse/cap-left - enable-pointertrue/enable-pointer - pointer-typefixed/pointer-type - input - property/controls/flight/rudder-trim/property - max1.0/max - min-1.0/min - /input - /gauge - - gauge - nameAileron Trim/name - x-50/x - y90/y - width100/width - height10/height - optiontop/option - optionhorizontal/option - optionnotext/option - major-divisions50/major-divisions - minor-divisions0/minor-divisions - marker-offset0.0/marker-offset - tick-bottomfalse/tick-bottom - tick-topfalse/tick-top - tick-rightfalse/tick-right - tick-leftfalse/tick-left - cap-bottomfalse/cap-bottom - cap-topfalse/cap-top - cap-rightfalse/cap-right - cap-leftfalse/cap-left - enable-pointertrue/enable-pointer - pointer-typefixed/pointer-type - input - property/controls/flight/aileron-trim/property - max1.0/max - min-1.0/min - /input - /gauge - /PropertyList -- 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] Adventures in dds
On Tuesday 22 March 2011 00:57:07 Vivian Meazza wrote: Nope, doesn't work. But this does: Map the .png file onto the AC3D model as usual - convert the .png into .dds in XnView - load the .dds into AC3D No flipping of vertical required. Perhaps XnView flips it for us? Vivian Probably xnview sets the origin in the lower left (as is in OpenGL). Problem with .dds is that each tool used to convert the might set the origin where it wants :( So far I haven't found a way of specifying the origin... -- 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] OSG version (was Auto-hiding the cursor)
Am 21.03.11 22:12, schrieb ThorstenB: I just noticed though, that a number of wiki pages again returned to recommend the use of latest OSG-svn *sigh*. I don't know why people keep recommending that... cheers, Thorsten Because it is valid ;-) Maybe not trunk, thats always dangerous, but 2.9.9 seems to work for OSX. I see right now I did a bad mistake in OSG configuration cocoa vs. carbon. There is no Xcode support anymore with OSG 2.9.9 and there have been some changes in default cmake configuration. Oi, oi, oi. Coming back here means reading two weeks list/forum/wikis, compiling two weeks (13 days for OSG, 1 day for sg/fg), buying a new machine, do it all again, but finally: I am always happy. Now I am building again, also because I see that the hudson nightlies are working with 2.9.9 on OSX 10.6. Sorry for this confusion. I hope the new compiled OSG libs will solve all my issues posted the last two days. And after that I follow the thread Quiet. Cheers, 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] Adventures in dds
Interesting.I just did my own quick test ... converted 1 out of 3 livery (png) files to a dds with Gimp plugin .Had to flip the image vertically before converting. I changed liveries with the dialog , and the 2 png files took several seconds to change , the dds changed instantly.I saw no difference in quality , but the load time was impressive.The original png file is 158.6 KB , the dds is 16.8 MB.This should swell fgdata significantly , unless Tim does (hopefully) does the /Aircraft split... Cheers On Mon, Mar 21, 2011 at 5:04 PM, Emilian Huminiuc emili...@gmail.com wrote: On Tuesday 22 March 2011 00:57:07 Vivian Meazza wrote: Nope, doesn't work. But this does: Map the .png file onto the AC3D model as usual - convert the .png into .dds in XnView - load the .dds into AC3D No flipping of vertical required. Perhaps XnView flips it for us? Vivian Probably xnview sets the origin in the lower left (as is in OpenGL). Problem with .dds is that each tool used to convert the might set the origin where it wants :( So far I haven't found a way of specifying the origin... -- 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 -- 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
[Flightgear-devel] Stuttering at 1 Hz rate
Hello everyone, I'm new on this mailing list and hope it is the right place to discuss some of Flightgear's internal stuff. So here is my problem: Ingame (insim) I notice a small stutter that happens once every second. Did anybody of you guys notice the same thing? What can we do about it? I thought it might be something like a timed task. (reading from hard disc + malloc)? Please, could someone tell me where I can find this function in the source files? -- 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
