RH.... FLY2 vs MSFS2002

[Guest tonyc]

Hi, Richard. This is not what the title implies.Rather,it's an attempt to discuss in more detail fly2 scenery and its interaction with HD access and video card and msfs' way of handling scenery. There's no question that fs2002 appears to have a more "elegant" way with which to handle scenery access, which explains its ability to keep fps more stable, that is, to prevent these sudden,(not the 4fps)but minor,drops in fps. I am sure you've had an opportunity to study in great detail msfs, and, while this subject has been discussed in great detail( the render.ini), I still think there's room for input as we try to move this sim forward. HOw Fly handles scenery, I believe, is its achille's heel.There's no question that the folks at ms have a different approach to this, given that the frequency of fps erratic behavior is considerably less, even when static scenery complexity as well as dynamic traffic is at full blast.tony

[Guest]

Tony,I believe the biggest downfall is scenery designers not taking advantage of built-in safeguards in Fly! to guarantee smoother scenery. At the highest level, Fly! loads scenery (both ground scenery and models) in what are called half-globe tiles (which is a misnomer; it's actually a quarter globe tile at a time, which equates to about 32nm square). The problem is, 32x32nm is a very large area, and once an area is loaded then any scenery within this square may be eligible for rendering, which could be a HUGE set of polygons/vertices. And, since each model can have it's own texture, this could require a very large texture set.But, there are systems built-in to Fly! to manage this further. The biggest one, and one that is rarely used, is model level of detail (LOD). What LOD does is very simple -- each model can be represented in multiple levels of detail, and you draw a different "version" of the model from different distances. For example, let's say the Golden Gate Bridge needs 8,000 polygons in all it's glory. You certainly don't need that many when you are 20nm away from the bridge. You can still see the bridge, but it is so small that 8K worth of polygons is gross overkill. So, instead you create maybe 2-3 versions of the same bridge. One may have 2,000 polygons for intermediate distances, and the lowest detail might have 200 polygons from a great distance. In the Fly! model system, you can assign all three of these visual models to the same physical scenery model, and give Fly! parameters of when it should draw one over the other. We even offer variations on how to define this -- either by simple distance, or by screen space. Here is a definition of the differences:By Distance: quite simple. You can tell fly that at 5nm or closer, draw model X. From 5nm to 15nm, draw model Y. And anything greater than 15nm draw model Z.By Screen Space: This method works well for very large models, like terminals and bridges. Instead of using a distance (which may cause the model swap to occur at angles that make it too obvious that the model swapped), you can instead tell Fly! that when the model occupies a certain number of Y pixels tall (height), to draw it using a particular model. So, you could tell it that if the model would occupy 50 pixels tall or more, use high detail model X, between 20-50 pixels use intermediate model Y, and anything below 20 use low detail model Z.These options are all specified in the model manager 'tags' within the scenery file. If you are willing to go further, you can then take a step to greatly reduce texture usage. Here's my thinking:Let's say you generate 3 levels of detail for each of your models, and you assign them distance/height swapping that's appropriate. This will greatly reduce polygon counts, and you'll be well on the road to better frame rates. But, what about textures? Just because you've reduce the model polygons, doesn't reduce the texture requirements. Well, one thing we did with our downtown sceneries in Fly! (which would work well for intermediate and low detail models) is to join textures together and "share" textures across models. So, instead of each building getting it's own 128x128 texture, we might join 4-8 models together and have them share a 128x128 texture. You might think this will make for ugly models (which it certainly would up close), but at intermediate and low details that model is going to be no closer than 15nm away, and you won't see any detail anyway! All you are really going for is color accuracy, not intricate details like windows or A/C units on the roofs. So, from a distance, you could reduce your texture usage by a factor of 4x, 8x, or even higher!All of this stuff is built-in to Fly! and ready to use, but I've yet to see any scenery take advantage of it. You'll notice in MSFS that in many areas you can see them "swap" their models to lower or higher LOD. They are doing exactly what Fly! is capable of, if people would just use the facilities. This may be why they have somewhat smoother scenery handling, though they also use a layered scenery system (which Fly! does not use), so in many cases they won't even load a scenery area until you are right on top of it. We always load no less than 32nm out from a target area, in 32nm blocks (roughly; these blocks shrink in size as you approach the poles).This system is also available for aircraft, and I believe the TRI aircraft are the only ones that use LOD. This is major, because when a designer builds an aircraft with 10K+ polygons but doesn't offer LOD models, if that plane is being used for dynamic scenery and is 50nm away, we still have to submit all 10K+ polygons to the video card when it's in line of sight. If you are unlucky enough that Fly! spawned multiple versions of this same plane model for other computer AI aircraft, you could have 10-50K of polygons being thrown at your video card each frame just for aircraft that occupy 4 pixels on your monitor!!! Since aircraft a typically very high poly, and have curved and smooth surfaces, it's even more imperative that at least two LOD models be offered; one for high detail when the model is close, and one for low detail when the model is >10nm away. Anything less is video card suicide.Rich

[Pascal_LSGC 298]

Thanks Rich for the fundamental info!Nice to see you here often these days, offering your invaluable help!Amiti

[lefteris 70]

Rich-this makes sense. However, I have one quick remark - isn't it possible for you, in a next beta (not to say that one is actually forthcoming ;-)), make the decision for us dumb developers? I mean, actually program a cutoff point that people can use, in an .INI setting, so that anything that's less than X pixels large, will be using the low detail model... or even, possibly, when those low detail models aren't even available, create them by extrapolating the high-detail ones... too complex?Does that make any sense?Cheers,

[Guest]

Well, I could easily enforce a cutoff, but as you point out the bigger problem is that in 99% of the cases there is no "low detail" model to even switch to. Writing a vertex reducer, that is actually reasonably accurate, is non-trivial. There are some companies that have devoted their entire dev teams to this task: MultiGen is a perfect example of the amount of effort it takes to write a solid, real-time model reducer. I'd definitely say that is well outside my talents from a time and effort perspective.We have a poor mans reducer built-in to the model editor in Fly!, though it certainly is not suitable for real-time. When you import a model, you can run it through the reducer by setting various tolerances. A model builder could do this by importing multiple times and reducing different levels each time to try to produce some auto-LOD, without having to manually recreate the models themselves. This would probably be suitable for most ground models (buildings, towers, etc), but may not be as suitable for complex models such as aircraft.Rich

[michal 44]

I have not seen the FLY code (nor the FS2002 one) but just experimenting with both products and slewing aircraft over the scenery it becomes very obvious where the main difference lies. It is the way aircraft movement is "tied" to scenery. In FS2002 it is decoupled allowing scenery update to progress at its own pace (and even fall behind), in FLY it is "hard" coupled - stopping aircraft simulation unless scenery is in place. Well, after seeing some professional simulators (I used to work for Singer-Link) I have to say the FS approach is the correct one. This is IN MY OPINION the single most important problem with FLY scenery software responsible for stutters. Even from the architectural point of view (performance aside) it is not a good design (design that scales better is always superior). All other aspects are secondary.I never owned FS2000 but from what I heard that and prior versions had model similar to FLY's. So credit must go to the FS team for identifying this shortcoming and having done something about it. I have no doubt TRI would have done the same thing in FLY!3.Happy Thanksgiving everyone in the US.Michael J.[link:jdtllc.com]http://jdtllc.com/images/RCsupporter.jpg

[Guest]

Michael,We may have made tweaks, but honestly it was a concious decision NOT to do what MSFS did when we designed Fly!. I absolutely hated the fact back in FS6/FS98 that I could get almost on top of downtown Chicago and the buildings were STILL not loaded, and were simply "telephone pole" sticks. They would then start "popping" into place, and once in view if you slightly tilted your viewing angle the engine would "pop" them back to sticks. It was absolutely horrid. We purposefully decided we would force scenery to be online and ready before it could come into view over the horizon, so that you would never see this.Now, this isn't to say that threading the scenery system itself would not be a good idea. "Decoupling" as you say into a separate thread would help, and probably should have been done when we transitioned to the Fly! II code base. But, this can be done with our without my participation; Padraic's latest invention shows our strengths, because he essentially is able to create his own scenery spawning system on top of our scenery engine, because of the flexibility in our SDK. In his case, he had a "better" solution for large poly models being loaded and inserted into the scene, and had the capability to override our systems instead. We've seen this with Quickgen, and various ATC tools that override other areas of Fly!. There is alot that can still be done with this engine, given the proper knowledge and motivation.Also consider that none of our I/O would be an issue on other operating systems that handle their secondary storage better. Just because Windows decides to stall the entire CPU core on an IDE disk access is a limitation we simply have to live with. It would be nicer if I didn't have to hack a more limited solution just to solve inherent weakness in the OS file system.Rich

[Guest tonyc]

Great start on this subject. Now we can perhaps start a scenery project and see how it all comes out. tony

[Guest tonyc]

from here the need to develop a GUI program ala FSI that checks all FLY scenery and converts to LOD, given that FLY already offers the converter.;-)tony