Re: [Flightgear-devel] Local Weather menu structure
Am 22.01.2012 21:27, schrieb Stuart Buchanan: On Sun, Jan 22, 2012 at 5:34 PM, Torsten Dreyer wrote: And I just pushed that to FGDATA. Global Weather and Local Weather is dead. Long live Basic Weather and Advanced Weather :-) Thanks Torsten. That looks great. BTW, if this change is merged into the 2.6.0 branch, we should also include commit a38820828c5343dbcb77d97a65597d736c845ff4, which removes a now-redundant reference to the local_weather_tiles menu item. I've also made the co-requisite change to The Manual (773db8825336521c42fd4d0edb22ca2d1bcc06ea) that should also be merged. I have just cherry-picked the Basic/Advanced Weather patches into release/2.6.0 - including Stuarts change to local_weather.nas. We don't have release branches for the getstart repository (The Manual), so there is nothing to merge/pick there. Torsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather menu structure: Wind settings
I just faild to set the wind speed and direction in the new weather menue structure (up to date next-branch). My intention was to set the wind profile from ground up to 3000ft. Hence I used the Basic Weather menue and set the desired values in the table. But I found that I got the wind speed and direction from the Advanced Weather Menue instead. Is this a bug/feature or am I simply to stupid to set the values correctly? Not sure what exactly you were trying to do. When you run Advanced Weather, it always uses its own wind model - it can't know what you entered in the Basic Weather config dialog and it doesn't care - we're not so far along the road to a merged weather system (if you were running Basic weather and it was ignoring its own config, that'd be a bug though). Advanced Weather has a few wind modes - constant (wind is the same everywhere), constant in tile (wind is the same in each chunk of 40x40 km, but may change between tiles), aloft interpolated (wind is interpolated based on the values entered in the wind dialog which is visible when you press 'show winds' and aloft waypoints (wind is interpolated based on a set of vectors both in altitude and in position - this is *very* cumbersome to enter manually and intended to run with online weather). Even the aloft interpolated modes don't allow you to select an arbitrary wind profile though, the low altitude interpolation altitude values are always 0, 5000 ft and 1 ft (this choice made following advice from TorstenD who had plans to get online aloft winds automatically in this format, something which isn't implemented yet), so you can only have a linear profile between these altitudes. The system doesn't allow you to specify wind conditions in the boundary layer, because it wants to compute them itself. You get a boundary layer which adapts to terrain roughness and local elevation, for instance there is no boundary layer slowdown of winds at mountaintops, and significantly less on upper mountain slopes than on the ground (which is somewhat important for ridge lift to work properly), boundary layer slowdown is far less pronounced over open water than in mountain terrain,... I suspect you were interested in specifying especially this region? In case you want to do something to the boundary layer computation, you'd have to dig into the code, this can't be done from config. Hope that helps. BTW: I'm totally impressed by the capabilities of the weather system, especially for glider pilots. I must admit that the weather system is a big motivation for me to keep up the development of a hangglider for FlightGear. Up to now the results are very promising. Soaring feels very realistic! Thanks. There's a lot of real life glider flying experience behind the convective cloud system and the thermals :-) If I find the time (which doesn't happen too often) I enjoy going cross-country with the ASK-13 very much. Like in real life, there are all sorts of surprises which can happen, and I always find mountain-soaring very exciting. Still need to implement that wave lift model at some point... Cheers, * Thorsten -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather menu structure
The change is releatively small but I'd feel better if ThorstenR tested it before it gets picked. The menu structure works like a charm - I think the switching button is a very elegant solution. I did a couple of tests yesterday, and I didn't run into any problems here. I've also had a look at the impostor code. I tried a benchmark situation with some thin, detailed (= many cloudlets) and hence framerate-expensive layers to gauge the effect. It didn't really even work to set up the benchmark properly. * in sunrise/sunset conditions, I could see the impostors. They don't inherit the lighting from the shader, so they were showing up with the wrong colors which didn't look very natural, but at least there was something visible * in noon conditions, I couldn't even really see the impostors, as they were so faint and the sudden change in layer properties from visible to faint clouds was rather drastic * using the basic weather clouds, the differences where not quite as drastic and I could see the impostors, but I could still see quite well where the impostors started * under no conditions was I able to detect any significant framerate gain - just maybe something like 32 fps vs 30 fps, but that may have been driven by other factors - I think that agrees pretty well with Stuart's findings. So, I think that's functionality which is better left optional - it doesn't seem to do an equally good job for all cloud types, and the framerate gain doesn't seem to be there for everyone. Cheers, * Thorsten -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather menu structure
I am hesitating from picking this into the release branch as one could argue if that was a bug fix. But if it's general consensus that this a an improvement that should make it into the release, we should do it. The change is releatively small but I'd feel better if ThorstenR tested it before it gets picked. Since the sunrise work is finished, I will catch up with master today and test a few things (I rather suspect that the water shader/environment interface may be rendered non-functional by some recent developments...). I'll also give the impostors a good try. BTW, if this change is merged into the 2.6.0 branch, we should also include commit a38820828c5343dbcb77d97a65597d736c845ff4, which removes a now-redundant reference to the local_weather_tiles menu item. I'm hoping this is local_weather_config.xml... local_weather_tiles.xml is actually the relevant menu :-) If nobody sees any issues, I would argue for deleting the menu itm also in the release branch, because a non-functioning menu can be considered a bug in my book. I also plan to make a list of by now obsolete files and textures. I'm too late for the release (I had this in mind a while ago, but the 6 weeks without computer really threw my schedule off the track), but I think it's useful to do some housekeeping. * Thorsten -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather menu structure
On Mon, Jan 23, 2012 at 8:08 AM, Thorsten Renk wrote: Stuart Buchanan wrote: BTW, if this change is merged into the 2.6.0 branch, we should also include commit a38820828c5343dbcb77d97a65597d736c845ff4, which removes a now-redundant reference to the local_weather_tiles menu item. I'm hoping this is local_weather_config.xml... local_weather_tiles.xml is actually the relevant menu :-) local_weather_tiles.xml is the dialog, which remains, and is referenced from the new Weather menu item. There used to be a menu item called local_weather_tiles (which also referred to the local_weather_tiles.xml dialog), which is no-longer used and was being enabled/disabled. The menu item local_weather_config has also been removed. -Stuart -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather menu structure
So, let's add a Advanced-- button to the global weather dialog which closes the global-weather dialog, enabled local weather and opens the local weather dialog. In return, the local-weather dialog gets a Basic-- button which disables local weather, closes the local-weather-dialog and opens the global-weather-dialog. This sounds very convincing to me - I'm in favour of this solution. And we'd like to go that road further anyway :-) And I just pushed that to FGDATA. Global Weather and Local Weather is dead. Long live Basic Weather and Advanced Weather :-) Torsten -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather menu structure
On Sun, Jan 22, 2012 at 5:34 PM, Torsten Dreyer wrote: And I just pushed that to FGDATA. Global Weather and Local Weather is dead. Long live Basic Weather and Advanced Weather :-) Thanks Torsten. That looks great. BTW, if this change is merged into the 2.6.0 branch, we should also include commit a38820828c5343dbcb77d97a65597d736c845ff4, which removes a now-redundant reference to the local_weather_tiles menu item. I've also made the co-requisite change to The Manual (773db8825336521c42fd4d0edb22ca2d1bcc06ea) that should also be merged. -Stuart -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather menu structure
Am 22.01.2012 21:27, schrieb Stuart Buchanan: On Sun, Jan 22, 2012 at 5:34 PM, Torsten Dreyer wrote: And I just pushed that to FGDATA. Global Weather and Local Weather is dead. Long live Basic Weather and Advanced Weather :-) Thanks Torsten. That looks great. BTW, if this change is merged into the 2.6.0 branch, we should also include commit a38820828c5343dbcb77d97a65597d736c845ff4, which removes a now-redundant reference to the local_weather_tiles menu item. I've also made the co-requisite change to The Manual (773db8825336521c42fd4d0edb22ca2d1bcc06ea) that should also be merged. Ah - thanks. I wasn't aware of that line of code. We should make sure, ThorstenR has backported that into his codebase when commiting a new version from him. I am hesitating from picking this into the release branch as one could argue if that was a bug fix. But if it's general consensus that this a an improvement that should make it into the release, we should do it. The change is releatively small but I'd feel better if ThorstenR tested it before it gets picked. Torsten -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather menu structure
Just an idea: as global and local weather are mutually exclusive, what about having just one single weather menu item and add button in each, global and local weather dialog causing the current dialog disappear and open the other dialog. While we are at it, I'd like to rename global and local weather to basic and advanced weather. So, let's add a Advanced-- button to the global weather dialog which closes the global-weather dialog, enabled local weather and opens the local weather dialog. In return, the local-weather dialog gets a Basic-- button which disables local weather, closes the local-weather-dialog and opens the global-weather-dialog. This sounds very convincing to me - I'm in favour of this solution. And we'd like to go that road further anyway :-) * Thorsten -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather menu structure
On Fri, Jan 20, 2012 at 9:59 AM, Thorsten Renk wrote: My GIT is now a week old, but in all likelihood this hasn't changed and is in the release branch: In reaction to concerns about a confusing menu structure, I moved all relevant configurations to /gui/dialogs/local_weather_tiles.xml (insofar as they are not controlled by the rendering dialog, which now affects e.g. cloud visibility range). This means that the second dialog /gui/dialogs/local_weather_config.xml contains only obsolete options - with one important exception, which is the checkbox determining if the Local Weather Nasal module is loaded. This cannot simply be moved to the other menu, because it also de-activates the 'Local Weather' menu item, so if it is deactivated, the only option (short of the property browser) to activate the menu would be on the deactivated dialog. I don't know what the solution should be, but I don't think the current state of offering a configuration dialog which doesn't affect anything is very good for a release. On the other hand, it should be clearly recognizable that the Nasal module has to be loaded before the system becomes functional. If anyone of those who originally suggested that the config menu is removed could please take care of this? It's not clear from your mail whether the local_weather_config dialog in the release branch can be removed once this checkbox issues is resolved. Can you confirm? Also, I noticed that there's another local_weather.xml dialog under gui/dialogs that appears to be obsolete. Can you confirm that it can be deleted? I'd suggest moving the /nasal/local_weather/enabled checkbox to the top of the tiles dialog, and disabling the rest of the dialog when this is not set. That way the dialog can be available at all times, while users will not be able to set any local weather config without enabling it. Does that sound like a good solution to you? I'm happy to take a look at making this change later today. It should be very straightforward. I don't know whether this change should be in the release or not. It's pretty late in the day. -Stuart -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather menu structure
On Fri, Jan 20, 2012 at 12:21 PM, Stuart Buchanan wrote: Also, I noticed that there's another local_weather.xml dialog under gui/dialogs that appears to be obsolete. Can you confirm that it can be deleted? Scratch that - I've just noticed this is used in the Debug menu. -Stuart -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather menu structure
It's not clear from your mail whether the local_weather_config dialog in the release branch can be removed once this checkbox issues is resolved. Can you confirm? I haven't actually tried if removing it causes an error somewhere, but it's not needed any more - all functions are either shifted to the other menu or don't affect anything any more. So my recommendation is indeed to remove it. I'd suggest moving the /nasal/local_weather/enabled checkbox to the top of the tiles dialog, and disabling the rest of the dialog when this is not set. That way the dialog can be available at all times, while users will not be able to set any local weather config without enabling it. Does that sound like a good solution to you? Would work fine, except that for me a checkbox to (de-)activate a dialog that way always caused errors (I tried at some point it to block inconsistent options on the GUI level, and I always ended up with garbage) - maybe I did it wrongly though. Cheers, * Thorsten -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather menu structure
I don't know what the solution should be, but I don't think the current state of offering a configuration dialog which doesn't affect anything is very good for a release. On the other hand, it should be clearly recognizable that the Nasal module has to be loaded before the system becomes functional. If anyone of those who originally suggested that the config menu is removed could please take care of this? Just an idea: as global and local weather are mutually exclusive, what about having just one single weather menu item and add button in each, global and local weather dialog causing the current dialog disappear and open the other dialog. While we are at it, I'd like to rename global and local weather to basic and advanced weather. So, let's add a Advanced-- button to the global weather dialog which closes the global-weather dialog, enabled local weather and opens the local weather dialog. In return, the local-weather dialog gets a Basic-- button which disables local weather, closes the local-weather-dialog and opens the global-weather-dialog. Our first simple step into a unified weather ;-) Torsten -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
I've just committed to origin/next a better fix for the LoD range that adjusts based on the view distance, and also attempts to account for the possible size of the cloud itself. Thanks - working fine here! Does this contain the impostor functionality already or not? Cheers, * Thorsten -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
On Tue, Jan 3, 2012 at 4:44 PM, Thorsten Renk wrote: Does this contain the impostor functionality already or not? No - the Impostor function will be committed after the 2.6.0 release. -Stuart -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
On Wed, Dec 28, 2011 at 3:45 PM, Stuart Buchanan wrote: On Wed, Dec 28, 2011 at 3:04 PM, thorsten.i.renk wrote: 4) Clouds now appear to be loaded in discrete lumps when they come into visual range rather than gradually be faded in via transparency which looks a bit ugly from high altitude - Stuart, is this intentional and a performance-related issue? I have verified that the corresponding tile is already loaded, so it's not something my part of the system does. With GIT pulled just before Xmas, I still see a hard-coded limit of ~20 km cloud visibility range which makes impossible for me to test layers appearance from above properly. This is very annoying, I hope the underlying problem is identified and fixed soon. The LoD is currently hardcoded to 20km, so if visibility 20km, it kicks in before the transparency effect. I have a good fix that takes into account the current visibility as part of the Impostors work, but that won't be available until after the release. In the meantime, I can increase the LoD range to (say) 40km. However, there will probably be some performance penalty. I've just committed to origin/next a better fix for the LoD range that adjusts based on the view distance, and also attempts to account for the possible size of the cloud itself. The clouds will now be rendered further out than before, so there will be an apparent perf hit, and users may need to use a shorter cloud visibility range than before. However, that is because the slide now has the correct effect on the LoD nodes, so I will claim that it was merely wrong before. * Let me know if you still see issues. -Stuart * Yes, that sounds _just_ like Apple's handling of the iPhone 4 antenna issues :) -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
It's actually surprisingly intricate. For instance, Local Weather allows for boundary layer gusty winds. For some problems (the wave pattern) you'd like to have the base (mean) wind at the surface, for others (windsock) rather the actual wind that the aircraft is feeling. I am now internally storing the interpolated wind (wind at aircraft location and altitude based on all available 3d interpolation points), the current wind (interpolated wind after local boundary layer correction and gust effects), the interpolated surface wind at current location and the current surface wind at current location. May I suggest a subfolder /environment/surface (and possible subfolders /environment/location[i] in case a location other than aircraft position is needed? /environment/surface/ could then contain surface-base-wind-speed-kt surface-base-wind-direction-deg surface-actual-wind-speed-kt (for gusts) surface-actual-wind-direction-deg (for variable winds) In addition we could maybe use effective-cloud-coverage-octas (how much is covered by the sum of all relavant layers) wetness-flag (boolean - in case we want to use wetness-dependent textures) snow-level-ft I have to postpone all this for a few weeks, but I have starred this mail. Please ping me, if I don't wake up after the release ;-) I hope we find a way to integrate global weather and local weather into just weather one day which provides the full range, from simple .. I wouldn't have any problems with that. Hehe - you will! That will most likely require some restructuring of code from both, the local weather and the fg core. It's just difficult for me to imagine how it would look like, as the philosophy is rather different. Although the boundaries become more and more blurry since now both systems refer to the same set of cloud textures and to the same rendering system. If anyone has a vision how the finished product should look like, please let me know :-) FSweekend and LinuxTag are excellent places for a brainstorming ;-) By the way, Torsten, could you clarify the status of --prop:/environment/terrain/area[0]/enabled=1 to start the terrainsampler in 2.6 - will this be needed at startup (i.e. should I re-activate the check at startup if this is on), or will the sampler be available automatically, i.e. can I assume that the system will be available? The property /environment/terrain/area[0]/enables is set to a boolean value of false on startup. This ensures the sampler is instantiated but not running. You should set it to true when you enable local weather and reset it to false when you disable local weather. Also, make sure to set /environment/terrain/area[0]/input/use-aircraft-position to true if want to sample the area around the aircraft's position. So, No: the --prop switch will no longer be needed at startup, the sampler is there but disabled, you can assume the system will be available. HTH, Torsten -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
The LoD is currently hardcoded to 20km, so if visibility 20km, it kicks in before the transparency effect. I have a good fix that takes into account the current visibility as part of the Impostors work, but that won't be available until after the release. In the meantime, I can increase the LoD range to (say) 40km. However, there will probably be some performance penalty. What's the maximum visibility that the Local Weather package uses? We used to have 45 km range out to which clouds were shown. With the new more efficient system, I have made tests with 75 km (which is enough for a good impression even from airliner cruise altitude), see here: http://www.phy.duke.edu/~trenk/pics/local-weather-next05.jpg The penalty for having this is not so severe as compared with other goodies (it's cheaper than the terrain haze for instance). Technically, tile generation is tied to actual visibility. The max. visibility the system generates at high altitude is 140 km or a user-specified maximum, whichever is lower, so cloud positions are computed at most out to 80 km or so. Clouds are shown out to the same distance as normal 3d clouds since they are subject to the same distance slider. If you hard-code some lower number for the release, please let me know where to change it so that I can go back to my extended layer testing. * Thorsten -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
Hi Curt! Curtis Olson curtol...@gmail.com wrote: Hi Joe, actually the FlightGear scenery is round -- technically oblate ellipsoid based on a wgs-84 coordinate model. If you stitched enough tiles together you will see the earth curvature start to form. I must have missed the implementation of this capability totally. I assumed a comparatively small cut-out of the ellipsoid was projected on a plane/disc. But, hey, thats great news to me! Thanks for clarification! Joe -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
Hi Joe, actually the FlightGear scenery is round -- technically oblate ellipsoid based on a wgs-84 coordinate model. If you stitched enough tiles together you will see the earth curvature start to form. The FlightGear world model lets you fly accurate great circle routes, and enables all the chart intersections to be at the correct location with the correct radials from all the relevant navaids. This also allows for correct relative placement of the sun, moon, stars, planets, correct phase of the moon (by just shading the moon from the position of the sun like in real life.) This ties into correct sunrise/sunset times, correct seasonal amounts of light and position of the sun, etc. Best regards, Curt. On Thu, Dec 29, 2011 at 7:29 AM, wrote: On Thu, 29 Dec 2011 10:37:44 +0200 (EET) thorsten.i.r...@jyu.fi wrote: http://www.phy.duke.edu/~trenk/pics/local-weather-next05.jpg Impressive! Technically, tile generation is tied to actual visibility. The max. visibility the system generates at high altitude is 140 km or a user-specified maximum, whichever is lower, so cloud positions are computed at most out to 80 km or so. At view distances 100 km it becomes more and more apparent that the flightgear scenery is flat and not a sphere, doesn't it? I think a realistic horizon is impossible as long as scenery/world is a disc. This applies even to low altitudes. In reality you can see that the clouds wrap our planet. Joe -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ 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://gallinazo.flightgear.org -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
On Thu, 29 Dec 2011 10:37:44 +0200 (EET) thorsten.i.r...@jyu.fi wrote: http://www.phy.duke.edu/~trenk/pics/local-weather-next05.jpg Impressive! Technically, tile generation is tied to actual visibility. The max. visibility the system generates at high altitude is 140 km or a user-specified maximum, whichever is lower, so cloud positions are computed at most out to 80 km or so. At view distances 100 km it becomes more and more apparent that the flightgear scenery is flat and not a sphere, doesn't it? I think a realistic horizon is impossible as long as scenery/world is a disc. This applies even to low altitudes. In reality you can see that the clouds wrap our planet. Joe -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
At view distances 100 km it becomes more and more apparent that the flightgear scenery is flat and not a sphere, doesn't it? I think a realistic horizon is impossible as long as scenery/world is a disc. What's more important from high altitude is what happens beyond view distance where no terrain is loaded. What you see then is the skydome, and the skydome shader for instance knows about the Earth radius and gives you (approximately) the right behaviour. A postcard from 85.000 ft is here: http://www.flightgear.org/wp-content/uploads/2011/09/fgfs-blackbird05.jpg (this is still from some early work where I didn't have the terrain haze shader yet - by now the seam between skydome and terrain is completely gone. I would redo these pictures except... I can't draw clouds to more than 20 km, and from 85.000 ft that means clouds aren't drawn at all because you are more than 20 km above them) This applies even to low altitudes. In reality you can see that the clouds wrap our planet. They do - Stuart spent a lot of time reacting to my complaints that clouds were placed in a flat layer initially :-) It's difficult to spot the curvature though, I can't (even conceptually) draw clouds to 140 km without changing the code in a major way. * Thorsten -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
On Thu, Dec 29, 2011 at 8:44 AM,wrote: I must have missed the implementation of this capability totally. I assumed a comparatively small cut-out of the ellipsoid was projected on a plane/disc. But, hey, thats great news to me! Thanks for clarification! Each tile is a square shape, and when you push the visibility out far, it's possible to see the square edges of the tiles -- especially against the sky dome if it's not blended together properly. Then also there is a far clip plane that can also be seen in extremely high vis scenarios -- so it's really hard to see the earth curvature in flightgear, but you see the side effects of everything being in the right place relative to each other with proper headings and directions and intersections for everything. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
We should agree on a common place to publish actual surface wind (for one or many given locations?) in the property tree. /environment/config is definitely not the best place to use but due to historical reasons, many objects rely on these properties (windsock, chimneys/smoke, many more). Someday, we also might want to have winds aloft data for one to many locations and altitudes, so it might be worth to think It's actually surprisingly intricate. For instance, Local Weather allows for boundary layer gusty winds. For some problems (the wave pattern) you'd like to have the base (mean) wind at the surface, for others (windsock) rather the actual wind that the aircraft is feeling. I am now internally storing the interpolated wind (wind at aircraft location and altitude based on all available 3d interpolation points), the current wind (interpolated wind after local boundary layer correction and gust effects), the interpolated surface wind at current location and the current surface wind at current location. May I suggest a subfolder /environment/surface (and possible subfolders /environment/location[i] in case a location other than aircraft position is needed? /environment/surface/ could then contain surface-base-wind-speed-kt surface-base-wind-direction-deg surface-actual-wind-speed-kt (for gusts) surface-actual-wind-direction-deg (for variable winds) In addition we could maybe use effective-cloud-coverage-octas (how much is covered by the sum of all relavant layers) wetness-flag (boolean - in case we want to use wetness-dependent textures) snow-level-ft ...? What would shader people like to use? I hope we find a way to integrate global weather and local weather into just weather one day which provides the full range, from simple 2d-layered clouds without shaders to the full-sized weather model in just one system. Hopefully not with a plain Nasal implementation, but by using existing and new FlightGear systems and Nasal. I wouldn't have any problems with that. It's just difficult for me to imagine how it would look like, as the philosophy is rather different. Although the boundaries become more and more blurry since now both systems refer to the same set of cloud textures and to the same rendering system. If anyone has a vision how the finished product should look like, please let me know :-) By the way, Torsten, could you clarify the status of --prop:/environment/terrain/area[0]/enabled=1 to start the terrainsampler in 2.6 - will this be needed at startup (i.e. should I re-activate the check at startup if this is on), or will the sampler be available automatically, i.e. can I assume that the system will be available? * Thorsten -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
On Wed, Dec 28, 2011 at 3:04 PM, thorsten.i.renk wrote: Local Weather is now (almost) in the shape I would like to see in the release, and I've worked quite a bit through the list of issues: Great! 4) Clouds now appear to be loaded in discrete lumps when they come into visual range rather than gradually be faded in via transparency which looks a bit ugly from high altitude - Stuart, is this intentional and a performance-related issue? I have verified that the corresponding tile is already loaded, so it's not something my part of the system does. With GIT pulled just before Xmas, I still see a hard-coded limit of ~20 km cloud visibility range which makes impossible for me to test layers appearance from above properly. This is very annoying, I hope the underlying problem is identified and fixed soon. The LoD is currently hardcoded to 20km, so if visibility 20km, it kicks in before the transparency effect. I have a good fix that takes into account the current visibility as part of the Impostors work, but that won't be available until after the release. In the meantime, I can increase the LoD range to (say) 40km. However, there will probably be some performance penalty. What's the maximum visibility that the Local Weather package uses? -Stuart -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
Am 28.12.2011 16:04, schrieb thorsten.i.r...@jyu.fi: 8) Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition .. Still to be fixed. I tried a workaround using negative cloud altitudes with respect to a very high layer, but Stuart's system doesn't accept that, so I really can't fix this myself. That should be easy to do - I'll have a look after the release if nobody is faster. 9) Water shader (very impressive!!!) doesn't react to wind/overcast in .. The current implementation works by writing into the Global Weather config which does the trick. Let me know as soon as a different interface is in place and I'll change the code accordingly. We should agree on a common place to publish actual surface wind (for one or many given locations?) in the property tree. /environment/config is definitely not the best place to use but due to historical reasons, many objects rely on these properties (windsock, chimneys/smoke, many more). Someday, we also might want to have winds aloft data for one to many locations and altitudes, so it might be worth to think about a good concept for that (but also, after the release ;-) Recent version of Local Weather (still lacks updated documentation), please test: 13215 lines of Nasal code. Wow, this is probably our all-time record for a Nasal based system ;-) I hope we find a way to integrate global weather and local weather into just weather one day which provides the full range, from simple 2d-layered clouds without shaders to the full-sized weather model in just one system. Hopefully not with a plain Nasal implementation, but by using existing and new FlightGear systems and Nasal. Together with fred's shadows, this should be a good reason for a version number of 3.0.0! Voi hyvin Torsten -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather stopped working
Hi, I know that Thorsten Renk is having to deal with some hardware problems, so that he may not be around for sometime. Nevertheless, we have been promoting the local weather stuff quite exensively, so I would really like to demonstrate it at FSWeekend. The problem here is that still the 'old' gui is on GIT while the new rendering system is active, so there is a mismatch. You have dynamical weather on, and what the system is prepared to do is to create information for a quadtree structure for a new cloud which doesn't need or have that structure, so the parameter isn't defined. This doesn't have a proper fix yet because the problem will disappear on its own when the option 'dynamical weather' is gone from the gui - in the new system clouds move with the wind anyway, so there is no need for the opion any more I have just started on the new gui, and he first sketch is in my forum-posted snapshot of the terrain haze shader. But (as you observed), unfortunately my laptop seems to be gone for good - apparently the motherboard is dead and can't be fixed locally, so while I don't really have data loss, it seems I need either a new computer or send it in, both of which may take a while. Currently I'm sitting on my 8 year old spare laptop, which is good for emails, but doesn't have either performance or harddisk space for a Flightgear development environment. If there are serious problems with Local Weather till I have a new setup, I can probably comment on many issues without running the code, but I can't actually maintain or debug the code :-( Cheers, * Thorsten -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather stopped working
Hi Thorsten, I have just started on the new gui, and he first sketch is in my forum-posted snapshot of the terrain haze shader. Thanks for the explanation. Emilian had already pointed me to the corresponding forum thread. I do have the terrain haze shader in a local branch of fgdata, and did notice your new gui: I just hadn't realized that the key to getting local whether was there. Both the local weather and the terrain haze threads are the ones I follow quite closely, but I missed the part about the dynamic weather option I'll try it tonight. But (as you observed), unfortunately my laptop seems to be gone for good - apparently the motherboard is dead and can't be fixed locally, so while I don't really have data loss, it seems I need either a new computer or send it in, both of which may take a while. Currently I'm sitting on my 8 year old spare laptop, which is good for emails, but doesn't have either performance or harddisk space for a Flightgear development environment. Good luck! Cheers, Durk -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather stopped working
Hi Durk, It seems to be working for me here, although I haven't pushed it very hard. What options are you setting up? Maybe I haven't hit the same code path here? Thanks, Curt. On Sun, Oct 30, 2011 at 4:20 PM, Durk Talsma durkt...@gmail.com wrote: Hi, Okay, last bug report for the day. When I'm trying to run local weather, I am seeing an error on the console (writing off the top of my head): Nasal runtime error in Nasal/local_weather/local_weather.nas:line 1480, no such symbol 'c'. The offending line is: local_weather.cloudassembly.rel_alt = c.alt - c.mean_alt Keeping FSWeekend in mind: Does anybody have a clue what the problem is and how I could fix it. I know that Thorsten Renk is having to deal with some hardware problems, so that he may not be around for sometime. Nevertheless, we have been promoting the local weather stuff quite exensively, so I would really like to demonstrate it at FSWeekend. Cheers, Durk -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ 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://gallinazo.flightgear.org -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather stopped working
On Sun, Oct 30, 2011 at 10:20 PM, Durk Talsma durkt...@gmail.com wrote: Nasal runtime error in Nasal/local_weather/local_weather.nas:line 1480, no such symbol 'c'. The offending line is: local_weather.cloudassembly.rel_alt = c.alt - c.mean_alt The variable c is indeed not defined anywhere I can see. My *guess* is the line should read: local_weather.cloudAssembly.rel_alt = alt - cloud_mean_altitude; That should make nasal happy, but whether it does what was originally intended, I do not know. -- Csaba/Jester -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather stopped working
On Sunday 30 October 2011 23:33:22 Durk Talsma wrote: Hi Czaba, On 30 Oct 2011, at 23:18, Csaba Halász wrote: That should make nasal happy, but whether it does what was originally intended, I do not know. Yes, that brings the clouds back. Whether the cloud patterns *look* sensible is something I'll check tomorrow, and whether the fix is physically correct is something that I hope Thorsten can answer. Thanks! Durk Hi Durk This might help: http://flightgear.org/forums/viewtopic.php?p=137492#p137492 -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather, apt.dat 8.5 and scenery textures
for inspecting the upcoming Swiss airports, I obviously needed to zoom out (see my posts in the forum's hardware and scenery section) After looking through the Forum - I guess what you mean is that you want a viewpoint from high above (outer space)? As established in lengthy discussions with vitos which you can read up at your leisure, Flightgear isn't designed to show the planet from outer space. Apt.dat 8.5 will be a great move forward but local weather is ugly. You're not forced to use it... It obviously will not work for a view from outer space (there's a reason it's called 'Local Weather' rather than 'Planetary Weather System Simulation'). Only one tile seems to be rendered, everything outside is black. That sounds like using the skydome shader and badly configured visibility/bare LOD distance. And yea scenery textures...sigh...I've no idea on how to implement for ex. google textures (which I've downloaded once for x-plane' Switzerland area) Any hints? There's aerial photograph texture around Brest available where you can see how it is done. Also throughout 3D clouds would be a very nice addition. No idea what you mean. We now have most cloud types in 3d, expept those which *really* *don't* *work* in 3d (very structured Cirrus). Cheers, * Thorsten -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather, apt.dat 8.5 and scenery textures
Thanks I'll search for Brest.See some screens. Default before and after using local weather. both with high z http://www.bilder-space.de/show_img.php?img=0c3153-1315821982.jpgsize=original http://www.bilder-space.de/show_img.php?img=460878-1315821939.jpgsize=original --- On Mon, 9/12/11, thorsten.i.r...@jyu.fi thorsten.i.r...@jyu.fi wrote: From: thorsten.i.r...@jyu.fi thorsten.i.r...@jyu.fi Subject: Re: [Flightgear-devel] Local weather, apt.dat 8.5 and scenery textures To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Date: Monday, September 12, 2011, 9:22 AM for inspecting the upcoming Swiss airports, I obviously needed to zoom out (see my posts in the forum's hardware and scenery section) After looking through the Forum - I guess what you mean is that you want a viewpoint from high above (outer space)? As established in lengthy discussions with vitos which you can read up at your leisure, Flightgear isn't designed to show the planet from outer space. Apt.dat 8.5 will be a great move forward but local weather is ugly. You're not forced to use it... It obviously will not work for a view from outer space (there's a reason it's called 'Local Weather' rather than 'Planetary Weather System Simulation'). Only one tile seems to be rendered, everything outside is black. That sounds like using the skydome shader and badly configured visibility/bare LOD distance. And yea scenery textures...sigh...I've no idea on how to implement for ex. google textures (which I've downloaded once for x-plane' Switzerland area) Any hints? There's aerial photograph texture around Brest available where you can see how it is done. Also throughout 3D clouds would be a very nice addition. No idea what you mean. We now have most cloud types in 3d, expept those which *really* *don't* *work* in 3d (very structured Cirrus). Cheers, * Thorsten -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather, apt.dat 8.5 and scenery textures
See some screens. Default before and after using local weather. both with high z Yes, just shows that you haven't understood the issue. Fact 1: The Scattering Skydome shader doesn't work for low visibility (100 km) because the haze it creates (the yellow-black stuff) doesn't blend with the terrain haze. It works for large visibility because then the terrain covers the yellow-black stuff all the way to the horizon Fact 2: Local Weather has its own vertical visibility model which determines what you get to see, so you can press 'z' all day long and it won't do anything. In particular, for performance reason Local Weather usually restricts the visibility to less than 50 km. Consequence: You go from a situation at high altitude where visibility is maxed out and the scattering shader works to a situation where visibility is quite restricted and the scattering shader's problems are not hidden any more. This has *nothing* to do with Local Weather, it's only related to the value of /environment/visibility-m at your position. If you use a low value with Global Weather, you'll see the same black stuff coming up, if you instruct Local Weather to display a large aloft visibility, you get this: http://www.flightgear.org/forums/viewtopic.php?f=17t=13339start=15#p135799 Future advice: First: Understand issues involved. Then: start bitching if necessary. Not the other way round. Cheers, * Thorsten -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather, apt.dat 8.5 and scenery textures
no definitely not not even your explanations...so i have to live with such as local weather is not capable of doing such? ok no problem --- On Mon, 9/12/11, thorsten.i.r...@jyu.fi thorsten.i.r...@jyu.fi wrote: From: thorsten.i.r...@jyu.fi thorsten.i.r...@jyu.fi Subject: Re: [Flightgear-devel] Local weather, apt.dat 8.5 and scenery textures To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Date: Monday, September 12, 2011, 12:24 PM See some screens. Default before and after using local weather. both with high z Yes, just shows that you haven't understood the issue. Fact 1: The Scattering Skydome shader doesn't work for low visibility (100 km) because the haze it creates (the yellow-black stuff) doesn't blend with the terrain haze. It works for large visibility because then the terrain covers the yellow-black stuff all the way to the horizon Fact 2: Local Weather has its own vertical visibility model which determines what you get to see, so you can press 'z' all day long and it won't do anything. In particular, for performance reason Local Weather usually restricts the visibility to less than 50 km. Consequence: You go from a situation at high altitude where visibility is maxed out and the scattering shader works to a situation where visibility is quite restricted and the scattering shader's problems are not hidden any more. This has *nothing* to do with Local Weather, it's only related to the value of /environment/visibility-m at your position. If you use a low value with Global Weather, you'll see the same black stuff coming up, if you instruct Local Weather to display a large aloft visibility, you get this: http://www.flightgear.org/forums/viewtopic.php?f=17t=13339start=15#p135799 Future advice: First: Understand issues involved. Then: start bitching if necessary. Not the other way round. Cheers, * Thorsten -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather, apt.dat 8.5 and scenery textures
no definitely not not even your explanations...so i have to live with such as local weather is not capable of doing such? ok no problem Quoting myself: This has *nothing* to do with Local Weather, it's only related to the value of /environment/visibility-m at your position. What in these two lines is difficult to understand? * Thorsten -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather - backward compatibility
Thorsten wrote -Original Message- From:.i.r...@jyu.fi [mailto:thorsten.i.r...@jyu.fi] Sent: 04 August 2011 07:57 To: FlightGear developers discussions Subject: [Flightgear-devel] Local Weather - backward compatibility Please note, the check for features.can_disable_environment == 1 is gone now. It doesn't make any sense there. In a current GIT, none of the checks make any sense, because current GIT always has all the features. On the other hand, the purpose of the compat_layer.nas is to provide compatibility of the weather to the last stable release - so when 2.4 is out, I will remove all compatibility checks, but as time goes on new ones will be added - which again allow you to run later versions on 2.4, but give GIT users all the new shining features. I can't really maintain two separate versions for last stable and current GIT - but I can maintain one version which works for both with the help of the compat layer. I fear that it'd just gets a mess if you start removing feature checks in the compat layer on GIT while I don't do it in my version intended also for distribution through the Forums. May I suggest to remove all the feature checks for the intended release branch (if simply to get rid of the messages) and set all features to 1 there, but to leave the management of feature checks in the development branch to me? I think that's least likely to create chaos. We don't normally maintain 2 versions: we leave the last stable as is, and only work on the Git version. If it's too much work, or too confusing I would suggest you abandon the version intended to be distributed via Forums, since that is not how we usually conduct our business. Vivian -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather - backward compatibility
We don't normally maintain 2 versions: we leave the last stable as is, and only work on the Git version. If it's too much work, or too confusing I would suggest you abandon the version intended to be distributed via Forums, since that is not how we usually conduct our business. That's precisely my point - at the expense of a few lines Nasal, it can be one version working with both last stable and current devel - which is why the code I distribute is as it is. This setup works fine until someone else doesn't commit the code as I prepared it but alters it before committing to GIT to get rid of the 40 or so extra lines which are only needed for compatibility with last stable. Then my code and the committed code are different, and I can't reasonably maintain that. I'm not suggesting how you should conduct your business, I'm telling about what I do and warning that if someone removes the compatibility lines before committing to GIT, he'll have to do it every time I update the code, because for the reasons given above my version will not have the lines removed. If you read the forums, you quite often come across disappointed users who'd like to test a new aircraft/feature/... shown there, but it doesn't run with last stable, although often a fix is often trivial (a single property with different name,...) - I don't see why we can't make things backward compatible as long as that's just such trivial issues, I prefer a happy userbase if it costs me nothing :-) Cheers, * Thorsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather - backward compatibility
Am 04.08.2011 08:57, schrieb thorsten.i.r...@jyu.fi: Please note, the check for features.can_disable_environment == 1 is gone now. It doesn't make any sense there. In a current GIT, none of the checks make any sense, because current GIT always has all the features. On the other hand, the purpose of the compat_layer.nas is to provide compatibility of the weather to the last stable release - so when 2.4 is out, I will remove all compatibility checks, but as time goes on new ones will be added - which again allow you to run later versions on 2.4, but give GIT users all the new shining features. Sorry, I was unclear. The computation of wind-from-down-fps can not be disabled at all, it is independent of the feature can_disable_environment. In the code before September 2010, this property was computed in the C++ core and was updated at frame-rate. From September 2010 up to a few days ago, this property was set only from within the local-weather code and from nowhere else (which was a bug). Today that property gets computed by a property rule (xml-based computation) and gets updated at frame rate. It is the sum of three properties(ridge, AI and local weather lift), the local weather code computes one of those three. It can do so whenever it wants to do and this does not depend on any feature. That's why I removed the condition check. Id did not make any sense in a past version, it did not while there was a bug and it does not today. I suggest to adjust your original version and adapt this change. Torsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather - backward compatibility
Sorry, I was unclear. The computation of wind-from-down-fps can not be disabled at all, it is independent of the feature can_disable_environment. Thanks for clarifying - that makes sense. Sorry for the confusion then. * Thorsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather: Clouds culled and redrawn
Hi Cathy, Let me know if you'd like some performance tests. My system is relatively old and slow. Without local weather on, no shadows, no 3D clouds, and no material shaders, I typically get frame rates around 20. With no local weather, shadows on, 3D clouds on, material shaders on, I get 2 - 4 fps. Material shaders and 3D clouds both cause big hits to frame rate. Hm, it'd be interested if you can run light cloud configurations at all with decent framerates. I'm fairly certain that some multilayer overcast cloud configs will mean instand death for your system, but the ones with relatively low cloud count (say, higher pressure, morning flights to keep convective clouds down or island hopping, relatively low visible range ~15 - 20 km, maybe also no detailed clouds) might be easier on your system than the standard layers. 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] Local Weather: Clouds culled and redrawn
How about using plain old textured plane crosses for clouds at bigger distances? (the way trees are done, only with a (or several) horizontal plane(s) added) These might work better for bigger structures like cumulonimbus, and such, too, as you can control the shape a bit. (no fancy shader needed ;) ) I don't think that works. Issue 1: I have never been able to work out a geometry for a static, believable cloud. I have tried plane crosses, intersecting spheres and ellipsoides, stacks of curved sheets, bubble foam geometries,... no joy, all looked quite bad even from some distance. I have tried for a month, no success. However, you are one of the best 3d modellers around here - so maybe you can pull it off. Issue 2: Shading - if faraway clouds are not shaded, they look unrealistic if nearby clouds are shaded away from the sun. If they are shaded, I don't see how the shading of any static geometry will be able to mimick the shading of the rotated sheets - especially plane crosses look very different when shaded. Issue 3: Transitions approaching the cloud: Nearby clouds are created as random stacks of different cloudlets - so there's no way one could know in advance how the detailed version of the cloud will look. Therefore, the faraway proxy and the nearby realistic cloud will almost certainly look differently, and this will give you a rather ugly transition. Issue 4: Transitions leaving the cloud: Nearly as bad - once in the scenery, I make no distinction of what a cloud is, individual textures are on their own - in principle a cloud can partially decay, merge with a different one, merge with a layer, separate itself from a layer,... That goes along with nature where 'cloud' is also not a well-defined object. So in going from a multi-texture stack to a single static model, you'd somehow group clouds again and make a decision which of your textured surfaces are supposed to represented by the placeholder. Consider an undulatus pattern - what is it you'd replace - the whole layer, one strand of clouds, parts of a strand where it is disconnected? How do you group technically - you'd somehow probe the whole geometry and match it to some predefined pattern. You also can't store the info what a cloud is supposed to be at creation time, because clouds are allowed to evolve and to change. So, looking into the details, it's really far from trivial how to use placeholders, and that is why I haven't been able to work out a viable scheme. I'll have a go at retexturing, redimensioning and choping this weekend if that's ok with you. Yes, certainly. I suggest that we pack your /Models/Weather/ then into a tarball and I host that for the time being as a dds texture patch to Local Weather so that people can test what works better for them. Once we know how this affects different systems, we can decide what to do and which version should go into GIT. Based on the Electra responses in the forum, dds doesn't seem to run for everyone without problems... * 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] Local Weather: Clouds culled and redrawn
On Saturday 26 March 2011 10:16:47 thorsten.i.r...@jyu.fi wrote: Yes, certainly. I suggest that we pack your /Models/Weather/ then into a tarball and I host that for the time being as a dds texture patch to Local Weather so that people can test what works better for them. Once we know how this affects different systems, we can decide what to do and which version should go into GIT. I'll probably put them up on a project at gitorious.org, with versions of the .ac's referencing both .dds and .png (for easy switching between the two). -- 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] Local Weather: Clouds culled and redrawn
Yes, certainly. I suggest that we pack your /Models/Weather/ then into a tarball and I host that for the time being as a dds texture patch to Local Weather so that people can test what works better for them. Once we know how this affects different systems, we can decide what to do and which version should go into GIT. Is this an area where you are looking for performance tests on different systems? I have FG 2.0 and the git-master build installed, and I'm in the process of setting up to build and run git-next. I have a version of local weather installed and I've been playing with it, but I'm sure it's not the latest. Let me know if you'd like some performance tests. My system is relatively old and slow. Without local weather on, no shadows, no 3D clouds, and no material shaders, I typically get frame rates around 20. With no local weather, shadows on, 3D clouds on, material shaders on, I get 2 - 4 fps. Material shaders and 3D clouds both cause big hits to frame rate. Video card is a GEForce FX 5500. System memory (not video card memory) is 1 G. Processor is AMD Athlon(TM) XP 2500+, 1.8GHz. If this is too fossilized a system to be useful to you, just let me know. :-) --Cathy -- 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] Local Weather: Clouds culled and redrawn
On Friday 25 March 2011 10:01:33 thorsten.i.r...@jyu.fi wrote: The main thing that bugs me with the system is that the view frustum culling around the edges of the screen is visible, so you continuously see the clouds being created and disappearing at the edges of the screen as you turn or change views. If it was once in a while I could live with it, but it's continuous and perpetual and distracts from the overall experience. :-( Hm, from the description this could be one of two things: 2) A while ago a video was posted here http://www.easy-share.com/1912919971/Clouds03.mpg which showed a view from the front window with many clouds. When the view changed to the side window, for a second empty sky was visible, which then rapidly filled with reloading cloud models. What you describe here sound pretty much like that, and that is very annoying. It's not something I have ever seen on my computer, for me clouds behave just as the default clouds, i.e. they are already there when I turn my view, there is no culling and redrawing happening. For the case in the video, I have verified that the effect doesn't come from within Local Weather (I asked to switch off all Nasal loops which load and unload clouds, and the effect remained unchanged). My suspicion is that it is generic at least for Nasal-spawned models, i.e. if you would place 1000 objects with the ufo around you and turn the view rapidly, you would see the same thing. I have never been to observe it in either 2.0.0 or any of my GIT pulls and with no version of OSG I've ever compiled against. In short I have no clue what it is, but I know that the problem lies outside the Local Weather package. * Thorsten This happens here as well (nVidia 8600GT (256MB VRAM) on linux). Now that I think of it it looks and behaves like graphics card memory bandwidth issue, maybe it is cured with the image cache set with CACHE_ALL? as by adding some more sistem RAM things haven't improved here. At one point I thought it was because of your code, as I remember something about a custom culling thing in there (maybe I remember wrong, or understood something wrong). -- 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] Local Weather: Clouds culled and redrawn
This happens here as well (nVidia 8600GT (256MB VRAM) on linux). Now that I think of it it looks and behaves like graphics card memory bandwidth issue, maybe it is cured with the image cache set with CACHE_ALL? as by adding some more sistem RAM things haven't improved here. Hm, I'm running an nVidia GeForce 8600M GT from linux - unless the mobile version makes all the difference, that would argue against a graphics card issue (or maybe I'm missing something, I'm not a hardware specialist either...). At one point I thought it was because of your code, as I remember something about a custom culling thing in there (maybe I remember wrong, or understood something wrong). The code has an option 'asymmetric buffering' which does remove clouds from the scenery to improve performance. However, there are several reasons to think that this has nothing to do with what is observed: 1) 'asymmetric buffering' removes clouds in the backward hemisphere of the airplane, not of the view axis, i.e. you can turn the view to look into the rear of the plane and see the gap in the clouds. If the effect depends on the view axis, it must be something else. 2) 'asymmetric buffering' is off by default, it doesn't (ot at least it shouldn't) do anything unless you activate it 3) the effect of clouds (dis-)appearing when the view changes persists if all running Nasal code of Local Weather is terminated 4) the effect is somehow system dependent - I have never ever seen it, others never got rid of it. So unless there is a fairly developed conspiracy of bugs which somehow mixes plane orientation and view axis, improperly reads out options and keeps loops running despite a termination signal, it can't be related. * 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] Local weather: menu structure
On Fri, Mar 25, 2011 at 7:44 AM, Thorsten Renk wrote: The local weather menu option is first before the other local weather options. This does open up a dialog box where you do have to create clouds 1-by-1. Looking at this, it appears that the intent of this is more for debugging. Maybe it would make sense to move this option over to the debugging menu if that is the case? That's actually a good point and I was about to ask a similar thing for the release version. The main use of the 'Local Weather' menu item is development. I use it when I introduce a new texture to test which cloud spacing, which degree of randomness and such things a layer composed of these clouds needs to look natural - once I have the parameters, I code a Nasal call to the same effect. It's also useful for benchmark tests because it allows to create a well-defined configuration of clouds. Finally, at some point Patrice Poly used it when he did some experiments with hires textures as an easy way to test how the extracted textures look in the scenery. It doesn't really have user applications or debug value. So my original suggestion would have been to rename 'Local Weather Tiles' to 'Local Weather' and to comment out the current 'Local Weather' in the menubar.xml. The small number of people who may actually need it for development can then simply edit menubar.xml and have it again, the rest doesn't need to see it, because it is confusing. However, if someone sees value in having it in the debug section or somewhere else, then I suggest to move it. I prefer the idea of renaming and moving, rather than commenting out in the menubar.xml file. I think there is value in retaining the dialog for those interested in creating new cloud layers in the future, so having it in the Debug menu makes sense (though perhaps Debug should be renamed Development). The Debug menu is not used by most users, and is not documented in the manual, so I don't see any problem in adding it there, even if it won't be used regularly. -Stuart -- 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] Local Weather: Clouds culled and redrawn
On Friday 25 March 2011 11:31:57 thorsten.i.r...@jyu.fi wrote: Hm, I'm running an nVidia GeForce 8600M GT from linux - unless the mobile version makes all the difference, that would argue against a graphics card issue (or maybe I'm missing something, I'm not a hardware specialist either...). * Thorsten If the card is sharing system RAM, it might not run out of bandwidth, but would certainly draw things slower afterwards. Since in the default config each cloud drawn requests a new copy of the texture, and that happens for a lot of them at once (since if an object is culled, I understand that it's texture might get flushed from the VRAM), it might be reaching the hardware limits. If your card is sharing system ram, if this happens it will throttle the card's output, as the whole frame draw is slower. On cards that don't share system ram, I'm guessing the card just draws what's available, and loads the other object later... I'm not a hardware specialist either, just guessing and throwing ideas into the mix. -- 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] Local Weather: Clouds culled and redrawn
Or maybe the mobile card's design is a bit different, or a bit newer and might have better memory specs.(bandwidth, timings, size etc...) -- 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] Local Weather: Clouds culled and redrawn
Hmm, I'm gonna do a compile with the changed CACHE_OFF to CACHE_ALL, and see if that makes a difference. -- 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] Local Weather: Clouds culled and redrawn
On Friday 25 March 2011 11:57:38 Emilian Huminiuc wrote: Hmm, I'm gonna do a compile with the changed CACHE_OFF to CACHE_ALL, and see if that makes a difference. Yep things improve, noticeably. And I'm more convinced it's a lack of gpu memory issue (as in it gets filled up pretty quick with the clouds), as I caught a glimpse of scenery getting redrawn too. (this with a warmfront over tncm, before I couldn't change the view direction at all, as that would cause massive redraws in the clouds, and fps woud drop dramaticaly) So cache-ing helps somewhat. I guess it's hitting the limit of my gpu memory, at least here... -- 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] Local Weather: Clouds culled and redrawn
Yep things improve, noticeably. And I'm more convinced it's a lack of gpu memory issue (as in it gets filled up pretty quick with the clouds), as I caught a glimpse of scenery getting redrawn too. You may be right - I looked up the specs of my computer, and it seems I have 512 MB VRAM, so that's a difference. What would then reduce memory consumption to see if the problem goes away? Using lowres textures? Using fewer clouds? Can you play with the Local Weather cloud generation menu to see if there's a number beyond which problems start? Or simply reduce the view range in the config menu to see if the problem goes away? * 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] Local Weather: Clouds culled and redrawn
On Friday 25 March 2011 12:52:58 thorsten.i.r...@jyu.fi wrote: Yep things improve, noticeably. And I'm more convinced it's a lack of gpu memory issue (as in it gets filled up pretty quick with the clouds), as I caught a glimpse of scenery getting redrawn too. You may be right - I looked up the specs of my computer, and it seems I have 512 MB VRAM, so that's a difference. What would then reduce memory consumption to see if the problem goes away? Using lowres textures? Using fewer clouds? Can you play with the Local Weather cloud generation menu to see if there's a number beyond which problems start? Or simply reduce the view range in the config menu to see if the problem goes away? * Thorsten Quick and easy way out, compressed textures for the clouds as in .dds textures :D (sorry about that, couldn't help myself :P) I've played around a bit with the config settings, the greatest effect was noticed with the visible range slider, and max clouds in loop. The most efficient way seems to have everything else maxed out, and selected. Visible range hits really hard 25 km here. (this is the biggest hitter, I guess it's to be expected since this increases the area drawn) Max clouds in loop 0.3-0.4 of the slider (I'd guess about 200 km ?) (too bad the sliders don't display the actual value somewhere :( ) (with the visible range to the minimum: max clouds in loop has very mild adverse effects when increased) Also massive effects where noticed when disabling any of the buffering options, or lowering their value. (I guess system ram helps here) Back to the efficiency thingy, clouds further out (20 km ?) should really be big boxes, as it's not worth it do draw them one by one, don't know how to solve this but I guess we could come up with an idea that's both visually pleasing and efficient to draw. One thing i'm thinking, is that the range animation drawback can be overcome by doing it in your code, like selecting the big box version for clouds that are a certain range out from the POV? (iterations in the nasal code seem to work pretty fast, it's just the gpu cannot keep up with them) 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] Local Weather: Clouds culled and redrawn
On Friday 25 March 2011 13:38:38 Emilian Huminiuc wrote: On Friday 25 March 2011 12:52:58 thorsten.i.r...@jyu.fi wrote: Yep things improve, noticeably. And I'm more convinced it's a lack of gpu memory issue (as in it gets filled up pretty quick with the clouds), as I caught a glimpse of scenery getting redrawn too. You may be right - I looked up the specs of my computer, and it seems I have 512 MB VRAM, so that's a difference. What would then reduce memory consumption to see if the problem goes away? Using lowres textures? Using fewer clouds? Can you play with the Local Weather cloud generation menu to see if there's a number beyond which problems start? Or simply reduce the view range in the config menu to see if the problem goes away? * Thorsten Quick and easy way out, compressed textures for the clouds as in .dds textures that is, small textures, 1/cloud model. -- 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] Local Weather: Clouds culled and redrawn
On Friday 25 March 2011 14:00:20 thorsten.i.r...@jyu.fi wrote: The most efficient way seems to have everything else maxed out, and selected. Not always. Asymmetric buffering is good if you fly straight, but very bad if you circle - for soaring it's completely unsuitable as you'd constantly shuffle things in and out of the buffer. With CACHE_ALL it's probably more efficient than it used to be... Well I was up at 50k ft, with the ufo, looking around, max fov, and it isn't as bad (sure there's some redrawing visible at the edges) but it certainly was worse with any decrease in any of the buffering options. Visible range hits really hard 25 km here. (this is the biggest hitter, I guess it's to be expected since this increases the area drawn) Max clouds in loop 0.3-0.4 of the slider (I'd guess about 200 km ?) (too bad the sliders don't display the actual value somewhere :( ) The slider really represents an number (from 100-400) - the range is derived from that number dependent on the density of clouds. mdap, typo on my part (was thinking about the range at wich clouds shoud become boxes, hence the km ;) ) I've been thinking about the problem for a year now (my rational was that layered clouds from 30.000 ft should be visible for much more than 55 km, and the only way to do that is using sheets. I haven't been able to come up with a viable solution :-( So if you have one, let me know... it's a much harder problem than one would assume naively. Cheers, * Thorsten How about using plain old textured plane crosses for clouds at bigger distances? (the way trees are done, only with a (or several) horizontal plane(s) added) These might work better for bigger structures like cumulonimbus, and such, too, as you can control the shape a bit. (no fancy shader needed ;) ) BTW: A question for our more knowledgeable graphics coders: I don't know if and how this is affecting the VRAM usage, or gpu performance, shouldn't we have the default wrapping mode for textures on models (not terrain) set to clamp, not repeat (as most usualy use parts of one bigger texture, or it's extents), and use repeat only where that's needed? (that is if that's what the wrap-s/ wrap-t/ tags control in the texture definiton inside the effect files) 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] Local Weather: Clouds culled and redrawn
On Friday 25 March 2011 14:00:20 thorsten.i.r...@jyu.fi wrote: Quick and easy way out, compressed textures for the clouds as in .dds textures :D (sorry about that, couldn't help myself :P) I doubt it's a general solution since I get 30% framerate reduction for dds textures. But you can do it for yourself and see if it helps your case - all models and texture sheets are in Models/Weather/. Cheers, * Thorsten Well, sorry to dissapoint ;) you, but with everything converted to .dds (with pregenerated mipmaps), there's a HUGE improvement in performance. Now I can have everything maxed out, sure you see some redraw, but there's a very small performance hit when that happens. With conservative settings, once evrything is loaded there's almost no noticeable impact when rotating the view anymore. Almost same conditions as before. Almost, because I've done the tests with the lowpressure tile, and not with creating a custom setting in the Local weather dialogue. conversion done with : nvcompress -alpha -bc3 -repeat file.png file.dds (I'm thinking you have to specify -alpha if the source has an alpha channel, maybe there's some optimisation at work there, also pregenerated mipmaps help) size of all rgb textures is 43.5 MB size of all dds textures is 38.8 MB , so size on disk is a nonissue.. sure in some cases it might increase dramatically, but here it isn't the case. Off to fly the electra in some tropical thunderstorm :P. 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] Local Weather: Clouds culled and redrawn
Nice white-out or rather gray-out when entering the rainy bit :) . (Not recommended with a plane that has no interior :P ) As for texture sizes, I think that those that are 6-9/sheet can be converted to 6-9 textures of 256x256, for the rest I think it depends on their shape, and of course actual cloud model dimensions. This way I think we save some memory from all those unused transparent areas in each of those sheets. Also elongated shapes should be stretched, to minimize the amount of complete transparent areas in the textures (if the models are textured corectly, then the correct shape of the cloud should be restored at runtime). I'll have a go at retexturing, redimensioning and choping this weekend if that's ok with you. Greetings, 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] Local weather ??????
however just try to modify the wind kt within the local weather tile gui, iget nasal error After some reflection and a similar problem discussed in the forum, I think I start to see a potential misunderstanding here. In an integrated weather system, there's no way to 'just modify the wind' because everything is tied with everything else. Take the case of a weather front: That's an airmass moving against another airmass with different properties, since air movement is the wind, the front is roughly perpendicular to the wind, i.e. you can see by looking at a cloud photograph how the large-scale air movement is even without observing movement of individual clouds. Thus, if you see a weather front and want to change the wind by 60 degrees, you're not asking for the windfield to be changed only, you are asking for the whole visible cloud configuration to be rotated by 60 degrees. You could think of using a rotation matrix, recompute all coordinates in local Cartesian approximation and be done. Unfortunately, weather feels terrain. So you might rotate clouds from a low region into a high region and vice versa, thus creating implausible layer altitudes above ground - which you don't want. Therefore you need to recompute the terrain elevation and correct the altitude of every cloud you rotate. Unfortunately you're still not done, because for convective clouds you may change the whole distribution pattern - you may rotate clouds from a city (where many convective clouds are expected) to open water (where only few can occur) - thus you have to recompute the whole interaction of the system of thermals and convective clouds with the terrain. So now we have to recompute essentially all cloud positions in potentially 120x120 km area just because we changed the wind. If you have dynamical weather on, in addition you need to rotate a lot of plane, wind and view co-moving coordinate systems, internal weather and windfield interpolation points and a lot of other important technical, though invisible stuff. Basically, you need to recompute almost everything. Which is why Local Weather Tiles is a launcher gui, not a runtime configurable thing. I guess it's the same reason that Flightgear doesn't allow to change the plane at runtime. If you want different weather, you need to end the running system and start a new one. The gui is actually supposed to tell you that, but that may not happen in every instance. I suspect that you have tried to use the gui as if it would allow runtime changes, have discovered a way that doesn't trigger the warning, and that then leads to errors. 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] Local weather ??????
That's was my conclusion a potential misunderstanding here. Your system is more a simulator dedicated to meteorologist engineer. To fly within Flightgear we have a lot of ready made aircraft model , we are not obliged to make the aircraft. With your local weather system we must build the weather., we don't have any ready weather, but to go to the Global weather with the real Metar. Why don't you offer some very good scenari. ? thanks. 2011/3/24 thorsten.i.r...@jyu.fi however just try to modify the wind kt within the local weather tile gui, iget nasal error After some reflection and a similar problem discussed in the forum, I think I start to see a potential misunderstanding here. In an integrated weather system, there's no way to 'just modify the wind' because everything is tied with everything else. Take the case of a weather front: That's an airmass moving against another airmass with different properties, since air movement is the wind, the front is roughly perpendicular to the wind, i.e. you can see by looking at a cloud photograph how the large-scale air movement is even without observing movement of individual clouds. Thus, if you see a weather front and want to change the wind by 60 degrees, you're not asking for the windfield to be changed only, you are asking for the whole visible cloud configuration to be rotated by 60 degrees. You could think of using a rotation matrix, recompute all coordinates in local Cartesian approximation and be done. Unfortunately, weather feels terrain. So you might rotate clouds from a low region into a high region and vice versa, thus creating implausible layer altitudes above ground - which you don't want. Therefore you need to recompute the terrain elevation and correct the altitude of every cloud you rotate. Unfortunately you're still not done, because for convective clouds you may change the whole distribution pattern - you may rotate clouds from a city (where many convective clouds are expected) to open water (where only few can occur) - thus you have to recompute the whole interaction of the system of thermals and convective clouds with the terrain. So now we have to recompute essentially all cloud positions in potentially 120x120 km area just because we changed the wind. If you have dynamical weather on, in addition you need to rotate a lot of plane, wind and view co-moving coordinate systems, internal weather and windfield interpolation points and a lot of other important technical, though invisible stuff. Basically, you need to recompute almost everything. Which is why Local Weather Tiles is a launcher gui, not a runtime configurable thing. I guess it's the same reason that Flightgear doesn't allow to change the plane at runtime. If you want different weather, you need to end the running system and start a new one. The gui is actually supposed to tell you that, but that may not happen in every instance. I suspect that you have tried to use the gui as if it would allow runtime changes, have discovered a way that doesn't trigger the warning, and that then leads to errors. 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 -- Best regards, Henri, aka Alva Official grtux hangar maintainer -- 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] Local weather ??????
To fly within Flightgear we have a lot of ready made aircraft model , we are not obliged to make the aircraft. With your local weather system we must build the weather., No, you certainly don't have to build the weather. Your problem appears to be in fact the exact opposite - you were trying to build (or micro-manage) the weather where you could not actually do so. I gave you an explanation what the system internally does and what it doesn't to make you understand a few things - not what the user has to do. If you want to build a weather pattern, you have to code it in Nasal. But no one is asking you to do that. we don't have any ready weather, but to go to the Global weather with the real Metar. Why don't you offer some very good scenari. ? Local weather tiles offers both the option to use live METAR data as well as a complete offline weather system. What exactly is it you are missing? I think this is the moment where perhaps you should really read the documentation http://www.phy.duke.edu/~trenk/files/README.local_weather.html 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] Local weather ??????
Here is a suggestion: The local weather menu option is first before the other local weather options. This does open up a dialog box where you do have to create clouds 1-by-1. Looking at this, it appears that the intent of this is more for debugging. Maybe it would make sense to move this option over to the debugging menu if that is the case? This being the first local weather option ... it threw me for a long time ... I wasn't about to sit around and create individual clouds ... That leaves two other local weather menu options that I believe are the ones that most people would use regularly? I need to go read the documentation at some point ... probably even should have done that before making comments on the mailing list. :-) The main thing that bugs me with the system is that the view frustum culling around the edges of the screen is visible, so you continuously see the clouds being created and disappearing at the edges of the screen as you turn or change views. If it was once in a while I could live with it, but it's continuous and perpetual and distracts from the overall experience. :-( But I do think the system shows a lot of promise and is really interesting. Clouds are hard, some of the global weather cloud layers look aweful, and I think it's critically important that we have people working to make cloud rendering better. So I'm *very* glad to see Thorsten continually improving his system. Best regards, Curt. On Thu, Mar 24, 2011 at 8:28 AM, thorsten.i.r...@jyu.fi wrote: To fly within Flightgear we have a lot of ready made aircraft model , we are not obliged to make the aircraft. With your local weather system we must build the weather., No, you certainly don't have to build the weather. Your problem appears to be in fact the exact opposite - you were trying to build (or micro-manage) the weather where you could not actually do so. I gave you an explanation what the system internally does and what it doesn't to make you understand a few things - not what the user has to do. If you want to build a weather pattern, you have to code it in Nasal. But no one is asking you to do that. we don't have any ready weather, but to go to the Global weather with the real Metar. Why don't you offer some very good scenari. ? Local weather tiles offers both the option to use live METAR data as well as a complete offline weather system. What exactly is it you are missing? I think this is the moment where perhaps you should really read the documentation http://www.phy.duke.edu/~trenk/files/README.local_weather.html 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 -- 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/ -- 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] Local weather ??????
Sorry what do you mean with (= tick the option box). ? however just try to modify the wind kt within the local weather tile gui, iget nasal error Cheers 2011/3/21 thorsten.i.r...@jyu.fi 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 -- Best regards, Henri, aka Alva Official grtux hangar maintainer -- 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] Local weather ??????
Sorry what do you mean with (= tick the option box). ? The menu 'local weather tiles' has an option called 'debug output', if that is ticked, a log is written to the console. however just try to modify the wind kt within the local weather tile gui, iget nasal error I don't. So in order to understand why you get one, I would need the sequence of buttons you press in order to get the error, in addition to the log output. The gui is at this point not hardened against meaningless user input, it sort of assumes you have read the documentation. So I want to know if you create an error by using the system in a way it's not meant to be used (i.e. if I need to harden the gui) or if you have a bug. I doubt you get the error when you change the number before you press a button for instance. If the number is parsed also depends on what wind model you have selected. Thus, I need this kind of info to understand what is happening. * 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] 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] Local weather: Clouds redrawn
On Thu, 11 Nov 2010 07:58:08 +0100, fiers...@zonnet.nl wrote in message 4cdb9400.1090...@zonnet.nl: I limited the frame rate to 30, used a smaller window. No difference. ..any change when you play with X Window frame rates and X desktop size? _They_ are still drawn at your full X Window xorg.conf Modeline controlled speeds, even when you play with FG frame rates and FG window sizes, and both X and FG are drawn by the same iron. Also check that you use the same color space for these 2. However, I noticed that with fewer clouds the effect disappeared. There seems to be a relation with cloud density. ..very possible, and at least a symptom. Another thing I noticed: While I am changing the viewing angle, the log window show errors. First a lot of Warning: TangentSpaceGenerator: unknown primitive mode 9 followed by several lines of Unknown Chunk: ***UNKNOWN*** (0xA08A) I assume this has something to do with the scenery. ..guess so, dunno the details, obivously when you zoom out, FG sees more scenery, zooming in, less, and with more detail, if you have _and_ load high detail models. Could it be related? ..dunno really, in my case I saw random texture holes flicker white, and I was at the card's 250MHz bandwidth limit trying to push 2048x1536x32|24@59Hz into the screen wire, it went beyond the FG window and all over the X desktop, I believe it was when I put my first Radeon 9250 into my Athlon XP 3000+ box, it's been a coupla years since it got my Radeon 9800Pro. (Or was that when FG messed up X diagonally on it?) m Op 10-11-10 19:01, Arnt Karlsen schreef: ..test ideas; cap your FG at 40fps, or back off a wee bit on your X framerate. X and FG window sizes? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather: Clouds redrawn
On Thu, Nov 11, 2010 at 6:16 PM, Arnt Karlsen a...@c2i.net wrote: On Thu, 11 Nov 2010 07:58:08 +0100, fiers...@zonnet.nl wrote in message 4cdb9400.1090...@zonnet.nl: I limited the frame rate to 30, used a smaller window. No difference. ..any change when you play with X Window frame rates and X desktop size? _They_ are still drawn at your full X Window xorg.conf Modeline controlled speeds, even when you play with FG frame rates and FG window sizes, and both X and FG are drawn by the same iron. Also check that you use the same color space for these 2. Uh, what? Tim -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather: Clouds redrawn
On Thu, 11 Nov 2010 19:26:04 +0100, Tim wrote in message aanlktikrympzsrjy8ontu7vq8lv-o2tjr+rqqax4o...@mail.gmail.com: On Thu, Nov 11, 2010 at 6:16 PM, Arnt Karlsen a...@c2i.net wrote: On Thu, 11 Nov 2010 07:58:08 +0100, fiers...@zonnet.nl wrote in message 4cdb9400.1090...@zonnet.nl: I limited the frame rate to 30, used a smaller window. No difference. ..any change when you play with X Window frame rates and X desktop size? _They_ are still drawn at your full X Window xorg.conf Modeline controlled speeds, even when you play with FG frame rates and FG window sizes, and both X and FG are drawn by the same iron. Also check that you use the same color space for these 2. Uh, what? ..last time I ran FG, I found ut it ran 16 bit colors on my 24|32 bit X, I didn't add the --bpp=depth Specify the bits per pixel, and on ATI cards it used to matter. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather: Clouds redrawn
Thorsten asked me to switch off xxx-loop-flags in /local-weather/ to rule out Nasal. Set to zero: buffer-loop-flag = '0' (double) convective-loop-flag = '0' (double) dynamics-loop-flag = '0' (double) effect-loop-flag = '0' (double) housekeeping-loop-flag = '0' (double) interpolation-loop-flag = '0' (double) lift-loop-flag = '0' (double) tile-loop-flag = '0' (double) timing-loop-flag = '0' (double) wave-loop-flag = '0' (double) To make that point very clearly: These loop flags determine if particular Nasal code of local weather runs and does administrative tasks. There is within local weather a subsystem which does similar things to what is seen in the video, asymmetric buffering, i.e. it removes clouds not currently in the visual field and some distance away from the scenery and re-inserts them if the view angle changes. My initial suspicion was that this subsystem is running wild - but setting the flags to zero and thus ending the Nasal loops (in particular buffer and housekeeping) would have 'frozen' the cloud configuration, i.e. it should have left clouds in an angular wedge visible and clouds everywhere else invisible with no loading/removing going on (I have checked that on my system that is indeed what happens). So since the effect persists even in the absence of any running weather-related Nasal code, I deduced it must be something else. Also, I am unable to reproduce the problem on either today's GIT or my old 2.0.0 binary. Maybe someone else has a bright idea... * Thorsten -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather: Clouds redrawn
On Wed, 10 Nov 2010 14:00:02 +0100, fiers...@zonnet.nl wrote in message 4cda9752.3020...@zonnet.nl: Hi All, I have been in an exchange of messages with Thorsten (http://www.flightgear.org/forums/viewtopic.php?f=5t=7358p=101746#p101746 http://www.flightgear.org/forums/viewtopic.php?f=5t=7358p=101746#p101746) about a problem that I have with the local weather in GIT versions (all GIT versions lately in fact). Clouds are drawn and I can wait for that initially. But when I change the angle of view, clouds are drawn for the new angle of view. When I 'turn my head'back to the previous angle, the clouds that were already drawn are gone and get redrawn. The same clouds in the same place. In this video, you can see for yourself what I mean: http://www.easy-share.com/1912919971/Clouds03.mpg Needless to say this is bad for realism. My FPS is not a problem. The effect occurs when the frame rate is above 40 fps. ..test ideas; cap your FG at 40fps, or back off a wee bit on your X framerate. X and FG window sizes? My machine is a 4 core (8 threads) 12GB ram machine running 64b Linux and an nVidea9800 graphics card. FGFS is run in mulithreading mode. I am flying as I type this. No processor is 100% busy and memory consumption is only 2.2GB (of which 1GB for fgfs) in total. I have 59 fps at this moment. ..it _could_ be your video card is the bottleneck here, I had a similar problem (angular white texture holes) that I cured easing my X framerate down from 59Hz to 58.8Hz. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather: Clouds redrawn
Thorsten asked me to switch off xxx-loop-flags in /local-weather/ to rule out Nasal. Set to zero: buffer-loop-flag = '0' (double) convective-loop-flag = '0' (double) dynamics-loop-flag = '0' (double) effect-loop-flag = '0' (double) housekeeping-loop-flag = '0' (double) interpolation-loop-flag = '0' (double) lift-loop-flag = '0' (double) tile-loop-flag = '0' (double) timing-loop-flag = '0' (double) wave-loop-flag = '0' (double) To make that point very clearly: These loop flags determine if particular Nasal code of local weather runs and does administrative tasks. There is within local weather a subsystem which does similar things to what is seen in the video, asymmetric buffering, i.e. it removes clouds not currently in the visual field and some distance away from the scenery and re-inserts them if the view angle changes. My initial suspicion was that this subsystem is running wild - but setting the flags to zero and thus ending the Nasal loops (in particular buffer and housekeeping) would have 'frozen' the cloud configuration, i.e. it should have left clouds in an angular wedge visible and clouds everywhere else invisible with no loading/removing going on (I have checked that on my system that is indeed what happens). So since the effect persists even in the absence of any running weather-related Nasal code, I deduced it must be something else. Also, I am unable to reproduce the problem on either today's GIT or my old 2.0.0 binary. Maybe someone else has a bright idea... * Thorsten -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather: Clouds redrawn
I limited the frame rate to 30, used a smaller window. No difference. However, I noticed that with fewer clouds the effect disappeared. There seems to be a relation with cloud density. Another thing I noticed: While I am changing the viewing angle, the log window show errors. First a lot of Warning: TangentSpaceGenerator: unknown primitive mode 9 followed by several lines of Unknown Chunk: ***UNKNOWN*** (0xA08A) I assume this has something to do with the scenery. Could it be related? m Op 10-11-10 19:01, Arnt Karlsen schreef: ..test ideas; cap your FG at 40fps, or back off a wee bit on your X framerate. X and FG window sizes? -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather: Clouds redrawn
Ah. The warnings and errors in the log window are related to local weather. They do not appear until I use local weather. Op 11-11-10 07:58, fiers...@zonnet.nl schreef: Another thing I noticed: While I am changing the viewing angle, the log window show errors. First a lot of Warning: TangentSpaceGenerator: unknown primitive mode 9 followed by several lines of Unknown Chunk: ***UNKNOWN*** (0xA08A) -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
