bsupnik

A fix for this bug (Nimitz deck is not solid _if_ a scenery pack with the Nimitz is loaded first) will be released in 10.45.

Hi, I have to jump in here to correct this before it goes too far. "I have always felt that when you dummy down/ restrict scenery visuals...the sim actually has to 'think' about NOT bringing up rendering objects and the like...and THAT costs CPU cycles." This is absolutely 100% completely factually wrong. There are two ways that you can lower visual detail in X-Plane and both save CPU time. 1. Some settings load less data into X-Plane. The OBJ, forest and road settings work this way. Because the objects are never loaded, the CPU spends no time deciding on whether to draw them or not. The cost of not drawing is zero and the time that would have been spent drawing them is saved. 2. Some settings change the search criteria for drawing. World LOD is like this. X-Plane uses a data structure (a quad tree) that lets us efficiently skip parts of the world that will not be drawn. The world is divided into larger chunks that contain smaller chunks, and if an _entire_ large chunk is not going to be drawn, we skip it once and _save_ the CPU time of evaluating the smaller ones. So lowering the world LOD distance lowers the search area over which we will draw. This in turn lowers the number of small chunks we -ever- evaluate because more of the big chunks are discovered to be "totally not drawn" (allowing us to stop CPU processing early). By comparison, at high LOD, every drawn small chunk is inside a big chunk that was also evaluated. So less is less work, more is more work. I do not know why a particular setup and scenery pack runs faster at higher settings than lower ones. But I can say that X-Plane categorically does -less- work with lower settings. There is no -cost- to not drawing -- we made very, very sure that this would be the case! Cheers Ben

Hi Robert, A 64-bit version of XSquawkBox is currently held back by a lack of a 64-bit Mac audio interface for VATSIM's audio library. This code is not under NDA, but it is necessary to ship a beta. I have no idea whether any other clients are being developed, but if they are it might be a bit silly ... we just need audio code, not a whole new client! cheers Ben

Hi Robert, I am the original developer of XSquawkBox. "Having gone from NO development after being abandoned by the original developers, it now looks as if this much-needed VATSIM interface will happen in the not-distant future, though it's anyone's guess as to 'when, exactly." XSquawkBox has not been abandoned by the original developers. Who did you talk to, exactly? Are you actually talking about XSquawkBox? We're not on version 4.0 or even 3.0; the last shipping version was 1.0.6. Perhaps you mean a different add-on? cheers Ben

I probably shouldn't wade into this, since it's turned into several pages of flight model fighting, but... There are a few things that I think X-Plane 9 does do better than FS X out of the box. I would compare our performance and visual quality in a natural setting with autogen forests to FS X. Go to the Alps without add-ons for either and take some screenshots, and compare fps. :-) (There may be some natural terrain where FSX clocks us - if so, please send me screenshots.) Similarly, there are details already in X-Plane 9 that an FS X user might not even know about. I say this because I sometimes hear reviews of add-ons for FS X and people talk about certain details and I go "but...but...but...we've had that for years!" Since I'm not an FS X user, I don't know what I can tell you might be present in X-Plane 9 and missing in FS X. (Ah - I remember one - on FSBreak they were talking about the HUD aligning with runways in 3-d...we had that in X-Plane 6. Same with add-ons that add cloud shadows to FS X.) There are some things that FS X definitely does better than X-Plane 9...- Urban autogen.- ATC.- Default airport buildings (we don't have any). These are all being worked on for X-Plane 10 in a major way! Finally, frequent updates - do they deter third party development? I don't think so. When we have talked to MSFS third party developers about moving to X-Plane, one and only one issue comes up: market share. The number of installed X-Plane copies vs. MSFS copies is the issue, and it's the one that we (X-Plane) must overcome. If you do make an add-on and we release a patch and it breaks us, please tell us (preferably while the patch is in beta) - we'll fix the bug!! cheersBen

What alpilotx said. :-)If you know of a 9.62 airport that is unusable, please list it by ICAO code here.http://xplanescenery.blogspot.com/2010/10/global-scenery-squawk-list.htmlSome may have been added post-terrain-creation, which means no preprocessing was done. I can spot check the ICAO airports on that comments list and try to improve the terrain processing in the scenery creation tools where they fail.cheersBen

The first half is a talk I gave a long time ago, discussing X-Plane 9 & 10. This was at a French user conference maybe 18 months ago. The second half appears to be footage of airplanes-in-progress that Sergio Santagada was showing off. We didn't make the video though, maybe someone had the slides?

That is not at all what I am saying. I will comment on 20 airplanes tomorrow in a blog post, I don't have time to write it up right now.My point was only that:- we don't need to invent a second flight model.- using the real flight model doesn't mean we can't optimize./ben

Hi Guys,I will have to write a blog post to go into this in more detail later, but I think a lot of what has been written here is wrong. Y'all started under the assumptions that:1. The flight model is going to be too expensive to run on AI planes and2. A table based flight model would be faster.Those are both questionable assumptions at best...pretty much everything you can conclude from that is, IMO, dubious.(I should mention at this point that I am unaware of _any_ "dumbing down" features in the FM right now. My understanding is that we will pre-process control inputs in a number of ways, and the frequency of the FM can be set to multiples of the framerate, but even at the lowest setting, we do a full physics integration and the plane is the sum of the physics that are applied to it. I mention this now because I am about to speculate on some optimizations that _could_ dumb down the physics model, and I want to make clear that shipping X-Plane 9 does not do this!!)Here's the short version:The most expensive part of the flight model is ground interaction - that is, the flight model doing collision checking with the ground and various parts of the airplane. When an airplane is "clearly in the air" (e.g. an initial test shows it has high altitude) the FM isn't very expensive; when it is near the ground, CPU time cranks up as we make sure to get the touch-down characteristics just right; same with taxiing.So if we want to make the FM faster, there's really only one place to attack: ground interactions - it's the lions share of CPU time. There are a number of simple things we could do to improve ground interaction. For example, we could stop checking for body scrapes - since X-Plane has to handle physics correctly even if the user lands gear up and scrapes an engine, the sim normally tests the full geometry of the plane against the ground (which is not flat, even at an airport) - that adds up. If we are willing to trust that the AI planes don't screw up a landing* we could cut down ground check to only real landing gear, which would improve performance.Now what if we did some kind of 'lo-fi' AI, whether it's table based or it simply says "move the plane forward by this much" (E.g. a sort of track-based system)? If we want the airplanes to 'sit' properly on the non-flat airport surfaces, we _still_ need to do the most expensive part of the FM - the wheel-ground collision checks. So the total savings of a 'lo-fi' AI flight model would be very small, because at best we might partly improve the performance of code that doesn't have much impact on the sim.(To understand why you can only boost performance by attacking the biggest pigs, see here: http://hacksoflife.blogspot.com/2010/11/is-1-lot.html for gory details.)However, there would be a pretty huge cost to a lo-fi flight model: we would have to code a SECOND implementation of pretty much everything we already do in the real flight model! We would have to have new flight model files to support this new alternate flight model. The opportunity cost here is in developer time...the time spent building a separate flight model could have been spent performance-tuning the real flight model...even if we had a second flight model, performance tuning time would now be divided between the two flight models, and neither would reach its optimal performance.Besides my explanation above of why a lo-fi flight model wouldn't really be a win, two more comments:In software development, it often pays to try the simplest thing first, see how it works, and go from there, rather than _speculate_ how a system may perform and write a ton of code up front before you have real data. This is what we are doing...the simplest thing we can do is to run the real FM on the AI planes, and so far it looks like it's going to work reasonably. IF we hit data that says "no we have to do something radical", then we will...when the data says so, and no sooner. So far indications are that the real FM is going to be fine, and this makes sense from what we know about its performance characteristics. We also know that we have a lot of tricks we could pull to make the real FM faster for AI planes (e.g. removing engine scrape-checks, per above) before we have to go and write a whole new FM.And finally, dude, the real FM _looks good_. With the real FM, the AI planes move the way big heavy airplanes should move. They track the ground perfectly. If the ground has a bump and the airplane's suspension is loose, it sways like it should. The control surfaces deploy with their real time. When you're at an airport performing ground ops, you can get really close to the AI planes, and at that point these things matter! I speculate: once you take follow an AI plane running the real FM on the ground, it'll be hard to go back to a 'synthetic' FM.cheersBen* This may not be a safe assumption...what if a microburst hits an AI plane?

Hi Guys,X-Plane is not dropping orthophoto support for third party packages. We have supported third party orthophoto packs in v9 and will continue to do so in v10; the formats that make this posssible in v9 will work in v10.X-Plane's default global scenery has never been based on an orthophoto approach...not in v8, not in v9, and it won't be in v10. There was never any chance that we would adopt orthophotos for global scenery. The global scenery has to cover the whole world and fit on a relatively small number of disks. Orthophotos are not compatible with these two goals. (At least, not at resolutions that users would want to fly over.) The global scenery will continue to use a series of techniques that are often referred to as "autogen", "land-class", etc. I will defer an in-depth discussion of how what X-Plane 8, 9 and 10 do with DSFs is similar or different to a traditional land-class/autogen system (e.g. FS X or X-Plane 7) until later...back to the mills for me.cheersben

Hi Guys,X-Plane 9 is a 32-bit application.X-Plane 10 will be a 32-bit application for a while.Both will run on a 32 or 64-bit OS.This is the last thing I posted about going 64-bit:http://xplanescenery.blogspot.com/2010/07/64-bit-its-on-radar.htmlI have no idea how much physical RAM X-Plane can actually use in real life for this reason: we share our address space with an OpenGL driver. That driver may consume physical RAM, and it may consume address space. Those things aren't always 1:1. Furthermore our address space is partitioned in different ways on different operating systems (with some held for the OS) and the driver may do its allocations on our side or the OSes side. These days, OpenGL will be using enough memory for graphic resources that it matters in the equation.cheersBen

945 final is available for test (click "Get beta" in the installer) - try it..please let me know if the MU is still busted - Nils reported that 945 fixes his BK117.

The mu throttle is probably the same bug - it affects a wide chunk of airplanes. If it's still busted after the next beta shoot me an email or file a new bug report.

I am pretty sure they will NOT wreck said planes - we are aware of a bug with the BK-117 - this will be fixed by LR fixing a bug. No mod to the plane will be necessary.If there is any breakage of the RXP GNS, no one has reported it.If you find an add-on that worked with 940 is now broken, please file a bug ASAP. We will fix it!

Hi Guys,From the review:"When it is all said and done, 5760x1200 made FSX more GPU dependent, just not in the way we expected. It is also very clear that it, like Crysis, demands a faster video card than exists today at these multi-display resolutions."This is probably true, but not particularly remarkable. Virtually _any_ 3-d application that does non-trivial rendering is going to become "more" GPU dependent when you increase the number of pixels on screen by a factor of 5. That's like saying that X-Plane becomes "more CPU dependent" when you increase the number of AI airplanes or 3-d objects. A true statement, but a function of the design of the sim, not the video card.The Radeon 5xxx series, by allowing you to run at huge resolutions _is_ shifting the relative GPU-CPU balance, but it's doing it by INCREASING gpu use, not by DECREASING cpu use.Okay that above statement is not fully true. I think there is almost certainly a relative workload shift due to increased GPU load in a huge-res setup. It is _possible_ that the CPU is being offloaded due to decreased driver time. We do not know if this is true or false. We do not have any data on this. To know if the CPU is used more efficiently, we'd have to have comparison numbers with older GPUs in CPU bound settings, or we could run Vtune on FS X and see where the CPU time is spent. (Only time in driver is a candidate for ATI making it faster. I don't know what FS X looks like, but I can tell you in X-plane that X-Plane does spend CPU time in driver, so if ATI/NV make things faster, we win.)My point is that there is no guarantee here that your fps will go up - there is a guarantee that you can have more pixels.

This does look to me like extra-X-Plane issues, e.g. something in the NV control panel. But also, there is one place to cheat: turn water reflections down to something less than "complete". The highest water settings burn a lot of CPU for only the tiniest improvement visually. Geof, If you set water to "none" what fps do you get? If still very low, the other thing to look at might be 16x aniso, then give it a reboot. If that is STILL slow, it's almost certainly a control panel/card/driver issue.

What, the internet could be used for something OTHER than flaming each other? Ridiculous!If anyone decides to try to help anyone else:- Preference folders ARE compatible as long as the CPU is the same (x86 to x86 or ppc to ppc) and the version of X-Plane is EXACTLY the same, e.g. 941 to 941.- Log.txt contains most system info and is a good comparison of two theoretically equal machines.- GPU control panel settings can hose everything and must be examined.- When in doubt, run the fps test for "hard" numbers.

Hi Jan,

Hi Jan,Duly noted on training - I believe that X-Plane's instructor mode gives the instructor 100% control over what happens, e.g. no surprises, and this mode of use can be extended to one-user operation. The case of "anything could happen" is more meant to present a _general_ impression of _real_ flying, e.g. blue skies doesn't mean it's hard landing time. :-)The new features are sometimes cranked a bit too high...getting in on the beta can make this worse. For example, the MTBF in X-Plane was set way too low for most of the betas. We increased it in a late RC, but for users in the beta, they may have already ended up with the default setting.cheersBen

Jan - thanks for posting such a detailed response - I really appreciate it. I am NOT saying to any users or third party developers are not important, or that wrong performance is a good thing.But read what Jan is writing - real world aviation involves coping with the unexpected, with the varying, with the continuous! This is something that Austin, who has been flying for approximately forever, really takes to heart, which is why unexpected things do happen in X-Plane, and he usually reacts negatively when users ask him to tone things down. In the real world you can't turn off the birds, the turbulence, or the unexpected equipment failure, and if you are an ATP, your plane might be "bent" a little bit. :-)cheersBen

Hi Y'all,Geofa: I think the interesting take-away on fps is the difference in standards...the X-plane community is clearly used to high fps. I think their reaction to your fps is "I can't believe fps are that low for the hw being used." So the question is: will anyone with that reaction help you to tune your X-Plane setup? (I would offer, but at this point I have become too busy to do systems tuning - it's very labor intensive. :-( Sorry.)Jan: Your quote: Remind me of a conversation I had with an A320 pilot at one of the VATSIM receptions...he was commenting on the immense variation in real airplane performance within his fleet. (I think he was a United pilot.) In particular, one plane had a rather crude side panel replacement and apparently the plane required rather severe rudder trim to keep it straight for the entire flight.Could you comment on how much variation relative to the published numbers you see within a real fleet of aircraft? The sim community is absolutely obsessed with hitting the numbers, but from the very few conversations I've had with real airline pilots, the procedure is to dial the necessary command to hit targets, and expect the inputs to vary based on the specifics of the plane, the day, the alignment of the stars, etc.cheersben

How does the scenery react to:- Changes of time of day?- Changes of season?- Changes of time of year?- Changes of visibility?- Changes of wetness/snow?I imagine they were able to cover some but not all of these issues within the limits of the authoring SDK and within the limits of reasonable effort.Re: 7 cm...good for the pavement, questionable for some other areas, although from a practical standpoint it might be easier to cover a large area at acquired and processed 7 cm imagery, rather than carefully make a multi-res package to save some VRAM based on expected camera location. At some point if we want scenery to look better, authors have to use faster authoring techniques if they are going to have time to utilize all aspects of modern computers. More rant here:http://xplanescenery.blogspot.com/2009/12/...ter-humans.htmlIn other words, as an engineer, I see 7 cm as wasteful in most cases...but as a developer, I appreciate the need to do what is expeditious when the results will be adequate (if not optimal) performance wise.(And of course, I have no idea exactly WHAT they did...is the whole ground area 7 cm or only the highest density areas? That's my other rant..the attempt to quantify the quality of a scenery pack with metrics. I like that movie because it _looks good_. But I expect the question of how they got that good look to be much more complex than just "they went to 7 cm res", and I would expect that another author could use 7 cm res imagery and still make an ugly pack.)cheersBen

A minor detail: Judith wrote 7 cm, and Geof wrote 7 meters. Those things are really different.7 m scenery would be considered "low res" by today's commercial scenery packs. 7 cm would be overkill for most phenomena - see my rant below.The difference in units here is ... a factor of 10,000 in storage! Now the rant:Would 7 cm scenery be...useful? Seriously, I think there has to be a real end to the increased usefulness of high-res orthophoto scenery.At 7 cm: consider...- A mailbox - 8 pixels wide, but with a vertical aspect ratio of...perhaps 3:1.- A parked car. 25 pixels wide, with a vertical aspect ratio of maybe 4:5.- etc.My point here is that when viewed from a slanted angle, the positional error of the image (caused by its not being a real 3-d extrusion) is going to be significantly larger than the resolution we've gone down to. Is a 7 cm pixel useful when the image of the top of the entity is wrong by 70 cm or more?At some point increased hardware capabilities would better be spent on real 3-d. If we are close enough to appreciate a 7 cm image* we are probably close enough to appreciate that...it's just an image.(The exception of course is truly flat high-detailed phenomena like pavement.)cheersBen* From my back-of-the-envelope calculations, you would have to be within 100m of an object to actually _see_ the object at its full 7 cm res for normal user viewing settings. At that distance, again I say: the lack of 3-d will be pretty apparent. This is made worse by the natural viewing angles in a flight simulator - that is, we virtually never look _straight_ down at what is directly below us from close range, so there is going to be a fair amount of "slant" to viewing, making the need for 3-d more apparent.

No. I can't make any statements about what future X-Plane will or will not do.I am simply saying that the problem of visibility in the REAL world is a lot more complex than "how far you can see" - it is "how far you can see throguh a very specific miass of air". There is a downer here, but it's not quiiite what you think it is.The visibility in air is more than 25 miles.The maximum DSF visibility before volumetric fog is _not_ large enough to simulate those pics, not by a long shot.If the sim's visibility and scattering worked the way we wanted (which it does not right now), you could set the visibility to 10 miles and STILL get some of those pictures, because X-Plane's visibility slider controls the ground->ground reported visibility, not air to air.To see this, set vis to 3 miles, clouds to overcast at, say, 500 AGL.Look around...you can't see squat. Fly up through the clouds - once you're over the top, it'll be really quite clear out.cheersben

Hi Geofa,That second pic is pretty illustrative: the mountains in the distance ARE visible - and yet closer to them there is a band of "no man's land" where atmospheric scattering makes it hard to tell what's going on.Also a minor detail: these are all pics from the air. Yeah of course you can see forever in the air! X-Plane's slider is for visibility _on the ground_. If it applied in air you wouldn't see the earth from orbit!/ben