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
