Hi, On Thursday, July 14, 2011 11:04:50 thorsten.i.r...@jyu.fi wrote: > I can maybe tell you what I need. Currently, Local Weather uses terrain > info in three ways: > 1) a presampling routine gets gross features in the vicinity of the > aircraft, i.e. mean altitude, median altitude, max. altitude,... That's > now implemented by Torsten as C++ routine running in the background - I > don't know details and don't know if it would benefit > > > 2) convective clouds are placed based on both terrain type and elevation. > For convective (not any other) clouds, there is extra work running for > 2-30 seconds (dependent on number, terrain detail,...) in the background > at the rate of ~12 geodinfo() calls per frame (geodinfo is a rather > expensive operation - more than 25 per frame are simply out of the > question). > > 3) for the 3rd generation cloud-terrain model currently under development, > there's an additional need to probe elevation (but not terrain type) for > many cloud types - curently using geodinfo() as well > > 2) and 3) are among the most computationally intensive processes Local > Weather runs, simply because geodinfo() is expensive (though perhaps not > the most garbage-collection triggering ones). If that could be made much > faster, tile setup could be accelerated dramatically. > > I wouldn't actually need the exact altitude/terrain type at a given > location for weather - an approximation which gets me some elevation and > terrain type within, say, 100 m of the specified coordinates would be just > as good, especially if it comes faster. If it really accelerates by a > large margin, then it allows the setup of tiles to be essentially in a > single frame, so one can really restart the system without the user > noticing.
Thanks for explaining. I will tell you what the ground cache is and how this relates to the scene graph: We have currently all our environment in the scene graph. For fast rendering it is required to have huge leaf nodes containing the actual geometry in the scene graph. Then there are these intersection tests with that special case ground elevation lookup. For this purpose you would like to have also a graph/tree like structure but with leaf nodes containing exactly one geometry primitive. One of these fast intersection structures is a bounding volume tree. Such a tree has usually leaf nodes containing just one geometry primitive. Which is just the opposite of what the gpu needs for rendering. So I decoupled these two structures somehow. I have put bv-trees of geometry into the userdata field of the scenegraph. So for the high level operations like tile loading, the scenery paging is used to load and get rid of the bv- trees. The whole intersectable scenery should be there in this form. Using this, you could already speed up ground queries by using these bv-tree leafs for intersection test leaf traversal. But for the actual aircraft I wanted to be able to do up to the order of 100-1000 intersection tests per timestep. To get that sufficiently fast, I built that ground cache: That is just a bv-tree of the near environment of the aircraft. This is computed by traversing the scenegraph, and collecting hose subparts of the leaf bv-trees that are within a few 10 to 100 meters away from the aircraft. Just as much to cover the whole possible travel distance given the current speed and position. Queries into this structure are extremely fast (~1e-6s - 1e-5s) on my development notebook. Building this substructure is usually about 1e-3s depending on its size. If there is no geometry in the groundcache, since we are flying too high, there is one single elevation query into the whole scenegraph that give the agl to give reasonable values. Special care must be taken for moving geometries like the Aircraft carrier. Ground type information is stored in the scenegraph and referenced by the bv- tree. So, no matter how you query, if you do not have the ground type information, there is an implementation just not fetching it. This means using the ground cache is only valid near the actual aircraft, where near means a few 10 meters. And no, please do not increase this ground cache radius of the aircraft for the weather. What you can do for the weather is to traverse the bv-tree nodes instead of the GPU optimized scenery nodes for ground queries. I guess this is the fastest (implementation wise fastest) approach to get something you need. I still like the idea - only for the weather module - to have a cartesian grid as a 'weather ground cache'. To me this sounds like something which provides a litte more croase, but sufficieltly good approximations to scenery altitude. You could also average ground type information for your needs at the grid nodes - whereas you would just get singular ground types for traditional scene queries. Sure, this is much more work to set this up. In the future, I hope to have a completely independent weather module using the HLA stuff that runs in an own process/thread. So, at that time you might be able to do more sophisticated stuff. May be it will then be possible to do a full cfd for subparts of the scene. That might be a good thing for a glider scene where you might want to have a more detailed fluid behaviour ... Greetings Mathias ------------------------------------------------------------------------------ BlackBerry® 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
