MSFS display system, the scenery arcs and panel design...

[Guest _FSAviator_]

MSFS display system - the scenery arcs - and panel design. You might reasonably expect this information to be anchored at the top of every MSFS panel design forum, but unfortunately it seems that few have understood why it matters. Although this post answers a nearby question I have taken the liberty of starting a new thread so that this post is easy to find using a search engine; whether for consultation or disputation.Angles in MSFS are coded in radians not degrees. Provided the display is full screen and an 8:6 resolution is invoked;1) The horizontal displayed scenery arc is 0.8 radians2) The vertical displayed scenery arc is 0.6 radians3) Zoom = 1 is the only zoom factor at which objects in the scenery subtend Pythagorean compliant angles to the viewer, and to one another, either in elevation, or in azimuth. 4) Zoom = 1 is therefore also the only zoom in which time (to go) and (viewed) distance (to go) are correctly associated. Example:With zoom = 0.5 a runway threshold one mile away will be displayed two miles away and has a consequentially huge Pythagorean angular display error when flying the visual glideslope. At 120 knots ground speed you see that you are two miles final, you expect to arrive in one minute, but the threshold rushes towards you at 240 knots and arrives in 30 seconds. Consumers addicted to video games enjoy this 'video game rush' effect obtained by invoking unrealistic zoom < 1, but it has no place in flight simulation. All lesser manifestations of unrealistic zoom < 1 degrade the simulation pro rata in accordance with Pythagoras' theorem. However the whole point of what is often called 2D panel display mode, but is really called cockpit view, is that whenever the user invokes that display mode the scenery display arcs above are maxima. Consequently a major complication arises. Within 2D viewing mode (cockpit view) the displayed aspect ratio of the scenery, (*not the window or screen*), is a variable which must be very carefully coded by the panel author in the panel.cfg. In 2D display mode panel designers use the SIZE_X and SIZE_Y variables to control the aspect ratio of the scenery display. To understand what follows readers should create a 2D panel with SIZE_X = 8191 and SIZE_Y = 6143. Using full screen mode pull the panel so far down that it is off the bottom of the screen. Note that the outside view of the scenery fills the window. You see 0.6 radians of vertical arc of scenery. Notice the object at mid screen.Now set SIZE_Y = 9000. Any excess over 0.6 radians is ignored. The display will be unaltered. Now switch to windowed mode. Drag the window to half width. The scenery display is now wider than the window, but you cannot see beyond the edge of the window.The panel author codes the projected scenery arc. In full screen you see what he coded, but in cockpit view and windowed mode you don

[Guest JeanLuc_]

Thank you for taking the time to write all this! I've digested it all I guess now. While sometimes the style may offend the reader, reading the "meaning" is alright to me!A couple remarks:1) what you describe for the outside world in 3D window has changed from FS2002 to FS2004. The ratio is maintained differently, and indeed, in FS2002, when vertically resizing the outside view, the projection was displaying more to the left/right edges. In turn, the vertical angle of view was fixed in FS2002, and in FS2004 is is the lateral angle of view that is fixed instead.2) I can assure you that MANY vendors do care about the 2D panel view and "apparent" field of view as compared to real aircraft and it usually shows in their products.Hope this helps!

[Guest jprintz]

FANTASTIC!!! Thank you for taking the time to write that. That's just the kind of info I was looking for with my view zoom thread down below. A question though - how precise is the 0.8 x 0.6 radian figure you gave? Is it .8, .80, .800....?? (This is not trivial, given that 1/100th of a radian is over 1/2 a degree....)I ask because I'm back on my HUD kick, had the vector and ladder working *beautifully* (screenshot attached ;-), but then it hit me... with a fullscreen scenery window, at zoom 1.0, 3 degrees up from the runway just didn't SEEM right as far as altitude and angle goes, compared to my admittedly limited real world piloting time. So I reworked all the angles/pixels for zoom 1.05. This would have been MUCH easier if there had just been an easy way to cull from the sim exactly how many pixels PI radians are at that zoom. (I think I ultimately settled on just a hair over 2000....) Instead it was all trial and error. VERY tedious. But it works great again. The margin of error of the velocity vector is certainly within the vector itself, as it should be....A question: Is there any manipulation that you know of that would give a better sense of altitude, without resorting to zooming in slightly, and the resulting slight distortion of speed and distance that entails?? I can appreciate the science as much as anyone else, but at the end of the day this whole thing is really about creating the most accurate PERCEPTIONS.Thaks again.

[Varmint007 2]

Now there's a HUD with a familliar face:)http://forums.avsim.net/user_files/128581.jpg--Jon

[Guest jprintz]

Hey Jon. Nice work! I remember you from a HUD discussion a few months back. I finished my first HUD back then (a warm up!), played almost nothing but Call of Duty for a couple of months (heheh), and then started over with a new HUD when I "returned" to my first love, FS2004, a few weeks ago. My second one is much better, since I increased the resolution and started with jpg's of the real thing, and of course I had learned a lot from my dry run (vector/waterline/horizon issues, stitching ladder bitmaps together, etc...) Can I ask you a few questions about yours? 1)Is that a power carat to the right of your vector? I'd heard of these, but I don't know how they work, so didn't put one in. (That same level of ignorance didn't stop me from coding in an ACLS tadpole though. ;-) I made it basically the intersection point of some very sensitive ILS needles.... ) So how does your power carat work? Looks at speed trend... something else?2) Did you keep your HUD bitmaps at 16 colors, or jump them up to 256 or even higher? I'm not sure how the program handles these images, since no one runs the game in less than 16 bits per pixel anyway, and I cannot notice a performance difference using standard Windows (16-color) GREEN textures, versus using 256 color textures. The FILE sizes are obviously bigger with higher bit per pixel images, but I was thinking that FS2004 had to allocate 16 bits (at least) per pixel anyway, so the file sizes would be the only difference. This obviously gets into areas about which I have little knowledge. ;-)3) Have you run into performace issues with your ladder? I stitched 2 ladder images together for my first HUD, and it ran well, but this one may take 4 or even 5. (I'm running it right now with just the horizon plus and minus 20 degrees.) I'm scared. ;-) These are BIG images, and even though there's only 2 colors in them, I didn't know if you had ever noticed a major performace hit when adding several ~2000 pixel long bitmaps to one gauge. Thanks for any input. Take care!

[Varmint007 2]

>Hey Jon. Nice work! I remember you from a HUD discussion a>few months back. I finished my first HUD back then (a warm>up!), played almost nothing but Call of Duty for a couple of>months (heheh), and then started over with a new HUD when I>"returned" to my first love, FS2004, a few weeks ago. My>second one is much better, since I increased the resolution>and started with jpg's of the real thing, and of course I had>learned a lot from my dry run (vector/waterline/horizon>issues, stitching ladder bitmaps together, etc...) Can I ask>you a few questions about yours? >>1)Is that a power carat to the right of your vector? I'd heard>of these, but I don't know how they work, so didn't put one>in. (That same level of ignorance didn't stop me from coding>in an ACLS tadpole though. ;-) I made it basically the>intersection point of some very sensitive ILS needles....>) So how does your power carat work? Looks at speed>trend... something else?It's called an "energy caret" and does show speed trend information. It uses filtered trend information over a measured time constant.Sounds like your tadpole is doing what it should.>2) Did you keep your HUD bitmaps at 16 colors, or jump them up>to 256 or even higher? I'm not sure how the program handles>these images, since no one runs the game in less than 16 bits>per pixel anyway, and I cannot notice a performance difference>using standard Windows (16-color) GREEN textures, versus using>256 color textures. The FILE sizes are obviously bigger with>higher bit per pixel images, but I was thinking that FS2004>had to allocate 16 bits (at least) per pixel anyway, so the>file sizes would be the only difference. This obviously gets>into areas about which I have little knowledge. ;-)I don't use bitmaps for the HUD. It's all vectors. If I were to use bitmaps, I'd certainly use 4-bit images. Some of the advantages are that I can change colors(brightness), maintain high resolution, and not have to worry too much about memory or performance issues.>>3) Have you run into performace issues with your ladder? I>stitched 2 ladder images together for my first HUD, and it ran>well, but this one may take 4 or even 5. (I'm running it right>now with just the horizon plus and minus 20 degrees.) I'm>scared. ;-) These are BIG images, and even though there's only>2 colors in them, I didn't know if you had ever noticed a>major performace hit when adding several ~2000 pixel long>bitmaps to one gauge. Again, no bitmaps. I use formatted text to create the rungs (there is another discussion about that here someplace). But I do use 4 separate elements of text stitched together.Feel free to email me if you want to talk more about it. I hate to hijack too much of this thread:)--Jon

[Guest _FSAviator_]

Jean Luc has carefully explained some scenery display differences between FS8 and FS9. His post also clarifies that VC mode is not quite fool proof. For instance attempts to run a VC within FS9 using a window whose height is less than about 1/3 screen height may lead to noticeable loss of Pythagorean compliance. Thank you. As I explained the answer is greatly complicated by the fact that recent versions of MSFS have two viewing modes and then again by the fact that, as Jean Luc has pointed out, the different versions are not identical in the way they deliver height cues. I will therefore confine this post to the situation within FS9 since FS8 has ever diminishing relevance. In what follows I will try to further illustrate the nature and scope of the problem by further explaining the things that may still be misunderstood.<>I will deal with human perception in detail below. Absolutely no aircrew experience is required to design a fully functional cockpit view. The requirements, together with an appropriate beta testing methodology, requiring only familiarity with usage of a default autopilot, are in the tutorial and demonstrations I published earlier and elsewhere (see post 1).I explained in my first post why the issue you address above is a problem that does not exist in MSFS unless the scenery projectionist or end user cheat modes create it. Your gauge can probably be programmed to display a false pitch ladder to match any scenery projection arc they jointly create, but the real question may be whether it should, and not whether it could. When you have tested your gauge relative to the scenery arc you have been using your gauge to test and evaluate the scenery projection error, not your gauge. You have potentially tested and evaluated two such errors. 1) Inadequate and/or excess displayed radians of vertical scenery arc2) Inappropriate centring of the vertical scenery arc.I have explained that both errors exist, who causes them, why your gauge does not cause them, and cannot fix them, whoever created them. It can only display the cumulative errors and although you currently perceive that to be a problem you should solve; it is not your problem. It is created elsewhere and it will have to be solved by those who create it. For the end user of your gauge the key issue will be whether the flight path vector points at ground or sky. The code in question is written by the scenery projectionist, not you as the gauge author, or me as the potential flight dynamics author. The flight path vector just displays the projection error. I don't think you have yet come to terms with the fact that you are only encoding how accurately the pre existing errors in all the other components are displayed to the consumer. Which slice of scenery radians the flight path vector points at is coded by the projectionist, whether or not the aircraft has a HUD. Consequently the

[n4gix 4,947]

On a practical note, the "solution" is rather simple, really...Assuming that the modeler has carefully constructed the VC to precise scale, and that accurate contact points are determined, and that the eyepoint is correctly set...Now all that remains is to adjust the 2d panel's size/shape, and viewpoints to match what is seen in the VC... ;)In fact, my practice is to use the "VC view" as a reference for designing the 2d panel, so that there's a "seamless transition" when switching from 2d to VC and vice-versa.Thanks for taking the time to explore the topic so throughly!

[Guest Ron Freimuth]

Incidently, the Horizon shifts with altitude. Down by about 2 deg near the runway. Probably so one can see the runway better. ;) I think it is even shifted down a bit at 5000 ft. When I have the 'V' indicator set to the proper view angle at high altitudes it shifts down (with the horizon) as I approach for a landing. This doesn't help when one wants to have constant geometry. Ron

[Guest jprintz]

Another great post. I'm enjoying all the info and insight you're providing here.Originally, I said:<<"With a fullscreen scenery window, at zoom 1.0, 3 degrees up from the runway just didn't SEEM right as far as altitude and angle goes, compared to my admittedly limited real world piloting time."You replied: "I will deal with human perception in detail below. Absolutely no aircrew experience is required to design a fully functional cockpit view.... I explained in my first post why the issue you address above is a problem that does not exist in MSFS unless the scenery projectionist or end user cheat modes create it.">>>>This is where we disagree. I respect the trigonometry behind it, certainly. However, as you say, "this is all about human perception." So true. I also agree with your repeated statement that the panel designer is the flightsim "projectionist." And I think you would agree that the ultimate goal is to project the view from the cockpit onto the monitor as accurately as possible, no? So... what to do? I'm sitting here right now, with FS in another (ALT-TAB'd) window, with no visual panel loaded, all scenery, zoom set at 1.0, in 1280 x 960 (4:3) resolution, and the panel.cfg dictating .8191 x .6143 arcs of scenery displayed, as everyone agrees is proper and most "pure." I'm lined up with the runway's centerline, with both my ILS and VASI showing 3 degrees, (confirmed by DME and alitude) on a runway I've had the good fortune to view from a real cockpit many times, a runway whose length and width are pretty standard and are matched precisely within the sim. And whether I shift the eyepoint or view direction up or down, it doesn't matter; IT DOES NOT LOOK LIKE 3 DEGREES. Many, many, real pilots on this forum, the flightsim.com forum, etc., have echoed this same thing, even after removing the complicating factors of poorly scaled/angled cockpits, zooming, etc. This is an **impression**. You cannot argue with it. ;-) (heheh) And these same people use their vision "according to Pythagoras," as you'd say, every day, often in real airplanes. The *impression* of altitude is lacking, even if the angles are internally consistent. The sim world SEEMS flatter. (I wish the National Science Foundation would fund a study or something, to see by how much the sim world seems flatter than the real world to the average person who has spent time in a real cockpit.) Now, does that mean I think Microsoft screwed up and their lead programmers forgot things like the definition of arctangent?? NO!!! I'm not blasting Microsoft. (I was originally surprised when it seemed 1 degree pitch did not equal 1 degree azimuth, but that was related to monitor resolution.) Anyway, I'm sure the sim world is entirely internally consistent as to angles, distance, speed, and time, but the problem I speak of is one of perception. What this "flattened world" perception is related to, perhaps, is... who knows... but I could venture a guess that lack of field of view plays a part... perhaps imprecisely scaled scenery objects or autogen trees and buildings... the limitation of detail (and thus angular and distance cues) that "only" about a million pixels can display?? Who knows. Nonetheless, the problem is a real one. The perception of so many people with so much real cockpit time cannot simply be ignored. Where you and I differ, then, is that I have no problem nudging up the zoom a bit (I don't think I'd venture much higher than 1.05) to account for this, a "deficiency," if you will, that's caused by God knows who, or even no one at all, and may just be an inherent shortcoming in the whole "19 inch monitor displaying 45 x 35 degrees of world" problem... And I nudge the zoom up a bit EVEN while I realize that doing so introduces other internal inconsistencies. It is a tradeoff. I value the more accurate perception of altitude/GS angle over those things that will be slightly distorted by introducing the setting. Simple as that....Also, I understand: zoom 1.0 is the zoom where all angles, speeds, distances, and times agree. Zoom 1 was set by someone, on purpose, to project .8 by .6 radians fullscreen, or about 45 by 35 degrees. If my 19" monitor, 2 to 3 feet away, were an actual window to the world, my actual FOV would be much smaller - I'm guessing about 20 degrees wide. Microsoft made a decision (probably a valid one, so as to avoid the "looking through a soda straw" feeling) to make everything "agree" at .8 by .6 radians, and thus to project much too much of the world into way too little of a space. I don't say it is a bad decision. However, my "common sense" tells me that this alone accounts for the altered perception of slope and persistent feeling of flatness. All I am saying is: it's OKAY for panel designers to nudge other variables a bit to account for this. TO A POINT. ;-) And as long as the user knows what he's getting.One more thing. >>>You said:"For the end user of your gauge the key issue will be whether the flight path vector points at ground or sky. The code in question is written by the scenery projectionist, not you as the gauge author, or me as the potential flight dynamics author. The flight path vector just displays the projection error. I don't think you have yet come to terms with the fact that you are only encoding how accurately the pre existing errors in all the other components are displayed to the consumer.">>>Oh yes I have. ;-) I know, all I can do is make the gauge internally consistent, with one degree equaling one degree in all directions, between all HUD componenets, and all of those equaling one degree of the outside sim world, correctly overlayed onto it... and of course I realize that all of these user-adjustable options mean that my HUD can only be accurate with certain panel.cfg settings. This is why, if I do release it, I will be providing a full panel. (Though the HUD, as the primary flight instrument, will be the focus.) What worries me, and this is something you hint at, is that the gauge will be downloaded, passed around, etc., incorporated into panels at wrong dimensions, with all kinds of zoom settings, resolutions, and eyepoints, and with no regard to whether horizon precisely matches horizon or waterline matches waterline. And then people will say "Geeze, didn't that guy know what the #### he was doing?!?!" Heheh. Still, the goal is to provide enjoyment to people. I've certainly enjoyed making it and flying it. I'll just have to document, precisely, the conditions under which the ladder and vector are both accurate and precise.Here's a final thought: imagine if we could make such gauges (which have to match the outside scenerey display) self-scaling and self-positioning, by reading gauge dimensions, window placement, size X and Y, zoom, etc., from the sim and from the panel.cfg, and then pass those values into our XML scaling and positioning statements. Yummy. ;-) Maybe some day. I suppose the variables or means of access are not there just because there are few (if any) other types of gauges that have to so precisely lay their info over the outside scenery....Good discussion. Interesting topic. Thanks again for taking the time.

[Guest Mathias]

>On a practical note, the "solution" is rather simple,>really...>>Assuming that the modeler has carefully constructed the VC to>precise scale, and that accurate contact points are>determined, and that the eyepoint is correctly set...>>Now all that remains is to adjust the 2d panel's size/shape,>and viewpoints to match what is seen in the VC... ;)>>In fact, my practice is to use the "VC view" as a reference>for designing the 2d panel, so that there's a "seamless>transition" when switching from 2d to VC and vice-versa.I use the same approach, and I think both VC and 2D match up quite well in my project, but a LOT of tweaking was necessary to get that far, that's for sure!

[n4gix 4,947]

>>In fact, my practice is to use the "VC view" as a reference>>for designing the 2d panel, so that there's a "seamless>>transition" when switching from 2d to VC and vice-versa.>>I use the same approach, and I think both VC and 2D match up>quite well in my project, but a LOT of tweaking was necessary>to get that far, that's for sure!LOL! I know that I've succeeded beyond even my own expectations when I can't tell whether I'm in the VC or the 2d, which has actually happened more than once! ;)I'll try to click on a "hotspot" and wonder, "Now why won't the XXX panel open?" Then I notice that I'm in the VC where the "hotspot" isn't!

[Guest _FSAviator_]

I am anxious that this thread should not become a series of one to one discussions leading to loss of sight of the seriousness of the problem or the 'fully joined up solution' required. In this third post I will respond to new matters arising whilst keeping them tied together. I am therefore going to avoid the quote and reply format in this post and conjoin replies whilst also covering new ground.I used to think that the concepts I have raised in this thread were simple to understand, apply and test. However after trying to explain all this over many years to cockpit environment makers one at a time, and carefully considering their responses, I have come to understand that it is not simple. The reason that it is not simple to understand or apply has been illustrated nicely by the recent crop of posts.There is a divergence between 'common sense' solutions and the mathematical problems to be solved. This has to be resolved in a practical way that encompasses the mathematics. It cannot simply ignore them. Below I will try to explain why the methodology that I published earlier and elsewhere is the simplest that actually resolves that divergence and solves the problem.I too used to believe that the design goal was simply to make the 2D cockpit environment match the 3D cockpit environment, but after debating this at length with a variety of expert cockpit environment makers I am now convinced that the solution is not that simple. They have convinced me that it only works if the

[n4gix 4,947]

I'll add one final note to this thread, then gracefully exit, stage left.While I have found absolutely nothing in your writing with which to disagree, the dry, academic and pedantic method of exposition is - well - offsetting... ;)To put it more bluntly, you are writing on a graduate level, when it is most likely that your prospective audience has reading and comprehension abilities closer to freshman level, if not lower.Here is how this latest message scores on the Flesch-Kincaid test:Flesch-Kincaid Reading Ease: 37Ideally, text should be around the 60 to 80 mark on this scale. The higher the score, the more readable the text. Flesch-Kincaid Grade Level: 13Ideally, text should be around the 6 to 7 mark on this scale. The lower the score, the more readable the text. Gunning-Fog Index: 21Ideally, text should be between 11 and 15 on this scale. The lower the score, the more readable the text. (Anything over 22 should be considered the equivalent of post-graduate level text).A prospective reader's perception plays a significant role in their comprehension and retention of content, but most crucially, it determines to a large extent whether the prospective reader will even persist through to the end of one's article.I'm confident that, although wholly unintended, the perception of most readers is that you are speaking from the stygian heights of an ivory tower. Or, more prosaically, "you're shooting way over their heads!" ;)In the future, you might give some consideration to the value of being a bit more pedestrian.Once again, thank you for these expositions of your views, even though they are quite difficult to exegete... ;)BTW, as a professional designer of panels, models and gauges, I do find your treatises helpful, although I'd long ago independently made the determination to never use anything other than a zoom-factor of 1.0 in any project...

[Guest jprintz]

My goodness.... Are you trying to hush people just be the sheer LENGTH of your posts? ;-) Even so, you did NOT address the issue I raised, and I'm now suspecting you may be intentionally avoiding it. You know a lot, obviously, but are overlooking some pretty fundamental things. All of your verbal meanderings have to do with whether the angles, etc., are consistent WITHIN the MSFS display system. You keep touting Pythagoras, Pythagoras, Pythagoras.... angles, angles, angles... You cannot at one time be a slave to such concepts while at the same time ignoring the fact that the display system is "compressing" .82 x .61 radians of scenery (~47 x 35 degrees) into what is, for probably 95% plus of the sim community, a display that occupies considerably less of their field of view. THIS FACT LEADS TO A FEELING OF FLATNESS/LACK OF HEIGHT IN THE SIM. (How could it not?) What would Pythagoras have to say about that? It is not the silly Eyepoint setting, and it is disingenuous of you to suggest that it could be something so trivial. There is NO Eyepoint setting that corrects for this, and, ironically, according to the very premises of your own posts (the sim's internal consistency), there could not be.To be precise, below are my assumptions and beliefs. If you do reply, I'd ask that the very first thing you do (if not the only) is tell me exactly which of the below you disagree with, and why.1) Of all fixed views, the forward cockpit view has primacy. Most simmers spend most of their time in it.2) The average user has a monitor which occupies ~ 30 degrees of his horizontal field of view. 3) Displaying 47 sim degrees within 30 real world degrees leads to significant compression, in all directions. (This is for the vast majority of users.) 4) This compression invariably leads to a lack of feeling of height, among other things, especially when looking down onto a runway on final. 5) Flying, especially when on final and looking down on the runway, is primarily a visual activity. 6) It is reasonable, to a point, for a panel designer to give greater value to the perception of real world angles/height and lesser value to time/distance, which we agree will be proportionately distorted as the zoom is manipulated. So, in other words, SOMETHING HAS TO BE DISTORTED. (At least for anyone who doesn't happen to sit 2 feet from a 28" monitor.) We get to choose which. Is it wrong to make it something other than the angles/height in the view that most simmers spend most of their time in? That is a valid choice, and that is why your continued assertion that upping the zoom is a "cheat" is simply erroneous. It would be equally valid for me to say that Microsoft imposes a "cheat" on us when they force us to view about twice as much of the world on our monitors as we would if it were simply a window.... But I'm not saying that. (I do think we could agree that, certainly, zooms of .75 and 1.25 are extreme; beyond that, perhaps we just value different things in the sim.) Anyway, it is completely justified if a panel designer wants to give a better perception of real world angles and height even if to the slight detriment of distance and speed. One more thing: your ADF needle analogy is so silly, given my above points, that I don't even need to go into why. And... I have been polite so far, but I won't hold my tongue any longer: you need to do something about the condescending, "I'm the only one who's right and everyone else knows nothing" attitude that pervades your posts, especially given the pretty fundamental things you've either overlooked or ignored. That may not be the way you think, but, respectfully, it does come across that way in your writing.