Art controls are internal tuning constants in X-Plane that we put in so that our art team can modify the behavior of X-Plane while they work without having to recompile the sim from source code. We leave them in the final product because they are sometimes useful to third parties, useful for in-field debugging, and because we are generally okay with people hacking the sim if they understand the limitations. X-Plane has always been a relatively open sim to play with and lots of X-Plane authors got their start just poking around. Our first instinct isn’t to encrypt everything.
We don’t go out of our way to break art controls. We don’t go in and change their names in every beta just to mess with third parties. But we also spend absolutely zero time trying to maintain art control compatibility with previous versions of the sim. Backward compatibility takes a lot of planning and effort and there’s just no way we can keep a bunch of internal tweaks the same while modifying the sim.
In X-Plane 11.30, a number of art controls have stopped behaving the way they used to. They aren’t going to go back to the way they were, because we don’t spend time trying to support hacks based on art controls. Here’s what happened and why:
As part of our work to port X-Plane to Vulkan, I rewrote the code that renders a frame in two ways:
- All off-screen rendering needed to draw the frame is now done before the frame is rendered; up to X-Plane 11.25 some of this work was done as a diversion, mid-frame.
- The graphic resources (mostly off-screen rendering buffers in VRAM) are allocated once when the configuration of the sim changes, rather than being allocated “just in time” when we get into a frame and realize something has changed.
Change 1 was needed to match how Vulkan and Metal handle off-screen rendering*; change 2 helps avoid stutters by allocating expensive resources early when we are not flying.
The side effect of this is that art control edits take effect only when the sim is reconsidering its graphic setup anyway (e.g. due to a window size change or rendering setting change); if the art controls change mid-frame, any code that does resource allocation ignores them because it is no longer “sniffing” for configuration changes per-frame. Other code that uses the art controls notices the change, and the result is often haywire drawing due to a half-used art control.
* This was an example of the OpenGL driver doing a lot of work for us, and hurting performance, to support an abstraction that doesn’t make sense. The real graphics card has to do real work when a rendering pass begins and ends; the OpenGL driver automatically synthesizes these rendering passes on the fly for the GPU as the app runs. Because Vulkan/Metal requires that we spell out the passes explicitly, we (the app) know exactly when we are doing something expensive (starting a new rendering pass) and we can minimize the cost.
Many thanks for explaining in detail, Ben!
I definitely appreciate every improvement of the sim, even if it breaks some art control hacks I’ve used to keep performance up (like adopting super sampling in real time). With every optimisation those hacks get less important, anyway… : )
That’s pretty interesting stuff, Ben. Is there any way to programmatically stimulate X-Plane to “reconsider it’s graphic setup?” Going forward, if a developer or user wants to adjust an art control for hacking purposes, it sounds as though one would want to stimulate a sort of reload, much as we can now re-load aircraft, plugins and scenery.
Not by API. You can resize the window and right now that does at least _some_ of it. It wouldn’t shock me if a few random things (e.g. popping out a Garmin) cause that code to run by accident. The idea is to only do the slow reconsider of setup and allocation when the user has done a rare, specific thing for which the sim glitching wouldn’t be considered a bug. E.g. we don’t guarantee 60 fps flight _while_ you play with your windows, but once you put them down we want things to be real smooth.
Wow, it’s been a long time not commenting.
PS.. Chrome blocks your site due to missing SSL certificates causing a https “not a safe site” error message FYI..
I see the use of art controls. Have been using them myself in different project, but I also seen how it can be misused. I hope use of art controls will down the line be optional. Developers could i.e. Be able to download a DEVELOPER Version of XP for testing and developing. I am native pro “hacking”, I love the hacking community and think most healthy developments and progress derives from such camps and tinker communities. To quote Sir Ken Robinson – “Curiosity is the engine of achievement.” However I am in more fan of performance than eye-candy, so to have a healthy core is to protect the foundation of what the simulator is built on. If manipulating art control and shaders are not healthy, remove the users option or as I suggested, move it into a controlled environment.
You should get your SSL certificate renewed.
We’re working on it!
With favours thrown in by Mr. Murphy, the cert expired on a weekend. Of course it did… I mean – when else could it possibly expire on? 😉
There’s this thing called a calendar. You may have heard of it, and you can even get them on your phone these days. Here’s the trick… when you renew your cert, put an entry in the calendar 1 year from now minus a couple of weeks, saying something like “Don’t forget to renew the web certs AGAIN!”. Works a treat. Ask me how I know…
A calendar? You mean the thing I use to separate my spaghetti from the boiling water when it’s done? I’m not sure how that helps me with my SSL certs, but I do have three of ’em. I’ll try waving one at my computer next year. 🙂
I am always very impressed in the sheer volume of autogen that is generated now to the context of the quality of the art, the last urban autogen is indeed very, very impressive.. this is of course at the max object setting. by your notes above Ben then how much more efficient will be the autogen with the API changes, and is it possible to extend the autogen’s range, I have with the latest sceneries noted that (certainly at night) that you are now seeing the limitations of the autogen’s range, this obviously affects the traffic and lighting as well. So you are now getting blocks of autogen that is highly noticeable?
While on autogen, I think that certainly the European autogen was a major game changer for X-Plane, so why is the changes in that area so slow, yes I understand that only one (very good artist) is doing all the work, but if it is so important than why not concentrate more on that aspect? Any autogen for say the middle east and Greek areas would have a major impact as well as Asian autogen, it would also extend the simulator far more outwards than the US – Euro centric it is now (Asia is a huge monster untapped market for X-Plane), and finally, why is there still no churches in X-Plane? For VFR flying they are the most notable, certainly in Europe to visual flying… But great work Ben
Xplane autogen is indeed fantastic but I agree there are some areas that seem to get overlooked or at least put to the bottom of the to do list when in actual fact they ahve quite a strong visual impact.
Certainly water/sea could do with a face lift and surely better and more specific autogen roads for UK and Europe and other areas would not be masses of work yet provide a real shot in the arm for European scenery.
On top of that we could really do with some more vehicles and some specific to regions would be nice, double-decker buses, black cabs (Yellow cabs for NY area) , that is an easy way to make regions more familiar when flying VFR.
All that said, no doubt performance and Vulkan and the most important improvements on the horizon for Xplane and the new additions of particles and first iteration of more believable ATC are wonderful.
PS I don’t think it is placebo but my performance seems a bit better with 11.3b2
Hi Ben – Would it be possible to make a reference guide that lists working art controls and their intended purpose? It seems to me that many of them do absolutely nothing but I never know if if that’s true or Im just not seeing it yet.
And also: the default value for the private art control “sun_gain_2_hdr” should be increased from 1.6 to 1.8 imo because an alpha of 255 and a pure white foreground texture will not produce a pure white sun and it seems to me it should. It shouldn’t be possible to make a texture (sky_color png) that appears brighter than the sun. Even the Cessna’s landing lights appear brighter. The “sun_gain_1_hdr” could also be increased from .8 to 1.0.
I’m sorry, but we aren’t going to do a dev guide to art controls. The whole point of art controls is that they don’t “Cost” us (in terms of development time from coders, artists, doc, testing) the way a real SDK does because we don’t do the entire document/sample/compatibility process. So writing a guide is both in the same bucket as providing compatibility (spending on dev time on a non-SDK) and it also sends a very wrong message to people – “hey, come use this thing, we want you to base your add-ons on it.”
Quote;
All off-screen rendering needed to draw the frame is now done before the frame is rendered;
unquote;
I hope above-mentioned off-screen rendering is already capitalizing on a pool multi-cores (or at least multi-threads)
It is not yet multi-core. There is almost no change in the pattern of multi-core dispatch in 11.30 compared to 11.26.
“The graphic resources (mostly off-screen rendering buffers in VRAM) are allocated once when the configuration of the sim changes, rather than being allocated “just in time” when we get into a frame and realize something has changed.”
Is this why frame pacing improved so drastically in 11.30b1? When the beta released, everyone was arguing over framerate but what I noticed immediately was that the sim was playable down to 15-20fps. Assuming it’s not placebo, great work.
I can’t say for sure – I’ve heard multiple people say frame pacing is better, and I’m happy to hear that, because that’s a big goal for us, but we’ve done a number of things to try to make our within frame work more predictable and efficient, and we can’t say what has made a different. My thinking was that we’d fix _all_ of this kind of stuff that was mandatory to port to Vulkan, switch to the Vulkan driver, and then re-profile.
Right now, even if we do things right (and us doing things wrong _is_ a real source of problems, especially in 11.26), the GL driver can still hose us, and we sometimes see that in traces. It didn’t seem worth it to spend a lot of time going in with Instruments and Vtune just to discover that the GL driver still defers work and then does it “just in time”.