On Friday, December 14, 2012 13:09:54 Stuart Buchanan wrote: > Hi Adrian, > > I haven't looked at your code, and I'm sure you've already taken care > of this, but: > > The use of the SG_NODEMASK_TERRAIN_BIT by the random trees and buildings > is probably due to my ignorance when writing the code, and I certainly > agree that the trees shouldn't have this bit set.
Hi Stuart, I am much more ignorant than you are when it comes to the way trees are created :) I have modified the code in simgear now, so that they don't have the bit set. Also, I noticed they have the SG_NODEMASK_CASTSHADOW_BIT | SG_NODEMASK_RECEIVESHADOW_BIT bits set (for Rembrandt), but they don't cast shadows, probably due to their geometry, you probably know better. Should I remove them? > > The v2.8.0 random buildings were a simply geometry built at runtime, > and IIRC people > were enjoying landing helicopters on the top of them. However, the current > git random buildings use a shader instantiation approach very similar to > the trees. I > think that means that the shouldn't be considered with the > FG_NODEMASK_TERRAIN_BIT > either, as the geometry itself isn't placed correctly in the scenegraph. > > Therefore, I think they shouldn't be considered in the > get_elevation_m/groundcache/bounding > box code. Same goes for "random" buildings, which thanks to texture mapping are now not so random :) To my surprise, they also didn't cast shadows. Now I understand why. Should those bits go too? Can Fred give his input too on this issue? About bounding boxes, perhaps there's a way to have that too, but again, I'm very ignorant on your method which relies on shaders. > > I think the random objects _do_ need to be included so they can be included > in collision calculations. Agreed. As it is now, I have added a new bit only for terrain surface, SG_NODEMASK_SURFACE_BIT , and the rest of terrain objects which do have bounding boxes will keep the SG_NODEMASK_TERRAIN_BIT. When performing scenery elevation calls, I believe the best way is to add another parameter which can toggle SG_NODEMASK_TERRAIN_BIT on and off. The speedup in this case is pretty important, there are fewer nodes to be traversed. I think Thorsten's weather would benefit from this as well, since it needs to sample only the surface (elevation, type of terrain). > > On the more general subject, I have two comments, both as a layman so > take with a suitable pinch of salt! > > 1) I think the most important attribute of the radio code is that one > can complete a published > approach. I assume that approaches are specifically designed and > built such that > there in sufficient signal strength within some volume around the > "perfect approach". Normally yes, I am not a pilot, but I assume that there would be no approach charts that would tell you there is localizer/gs signal behind the local mountain. Same goes for VOR etc. The published volume is one thing, but if terrain features come into play, the signal may or may not go, and that's the most interesting part of it, it adds a little uncertainty when you are at low altitude, in mountainous areas, at the limit, etc. I just had a very satisfying flight yesterday using the code, and it made me understand why there are so many VOR's in some areas, and how you need to tune from one to the other as you go through terrain at lower altitudes. I should add that I fly in SRTM terrain mostly, and I have very accurate radio signal predictions. > > My concern with any advanced model is that invalid/inaccurate > terrain/elevation input into the > model might mean that we get too low a signal, and some approaches > might no-longer be > possible to fly due to (incorrectly) low signal strength. The reverse is likely. The values will be most unforgiving with SRTM/high definition DEM, and most forgiving in low res terrain. Fortunately, I have a property which can be set by the user, depending on the type of terrain which is flying. This is the elevation resolution the code should expect. In low res terrain, this property can be set to 200-300 meters between profile points, and then you won't even notice the CPU footprint. > > Adrian: Is that a reasonable concern, or are approaches designed such > that there is always > line-of-site between the station and the aircraft on the approach (and > therefore any terrain > interaction is irrelevant within the approach volume)? I believe all approach charts respect terrain, and judging from nav.dat, there is a good reason some VOR's use greater power, or some ILS stations pump greater power in their antennas etc. To do otherwise and not keep the terrain in mind would be foolish, and I don't think the guys publishing the charts are fools. > > 2) Assuming we're only interested in terrain effects, then it would > seem that the signal strength > at a given point (lat/lon/alt) for a given station is invariant. > > Would it be possible to avoid the runtime hit by calculating it > offline for all points within reasonable > range of the station? > > One might be able to create a bitmap storing the minimum signal > altitude (i.e. the altitude below which > there is no signal due to terrain), the maximum signal strength, the > altitude that occurs, etc. and then > use these as parameters into a straightforward function to determine > the signal strength at the current > altitude. That "could be possible", but there are an infinity of points where the aircraft can be wrt the radio station. Plus, if you had an instructor messing with your flight, how could he subtly fail the transmistter, by reducing power, or changing the signal etc... Also, some meteorological conditions can influence real time propagation on some bands, this has yet to be simulated. Nedd to take into account that frequencies used are different too, from low VHF for VOR and ATC, to low UHF for glideslope, to high UHF (1 GHz + ) for DME, Tacan, nevermind radar and other stuff. Someone might decide to use this for simulating finding low-power search and rescue beacons in rough terrain too... what do you do about those? There's a reason this needs to be performed real-time... All other applications which do propagation prediction using this method, do it in 2D. That is, they project the reading on a 2D map, on ground level. They couldn't do it for an aircraft. This is where this system is unique, compared to any others out there. There is so much potential to be exploited here, you wouldn't even guess :) Anyway, there are plenty of options to tweak via exposed properties to take care of performance for the casual user, including disabling it completely. There is as well the possibility to go totally out of control and perform very detailed readings with some CPU cost, if that's your thing. I have utmost respect for the freedom of the user to use the system anyway he desires. The things I'm not happy about now, are antenna pattern radiation profiles for localizer/glideslopes. I need to start using an antenna design utility to get more realistic patterns, but the current code counts only the signal values, the false courses and other stuff I have kept from the standard code, you still get them, as they were hardcoded before. Fortunately, getting a pattern is easier than writing the whole system :) It's very hard to model an ILS station according to reality, and I will do so only upon specific request. Otherwise, I will only give signal values, not modulated sidebands, false courses based on sidelobes and such stuff. If some from ARINC wants to get involved with this and use such kind of simulation, I would require some specific data which I can obtain now from aviation radio engineers, but see no reason to go so far with the level of details unless requested. Which might happen in the future, we never know who might find a use for this ;) Cheers, Adrian ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
