EDIT: when this article was originally written, the 2.1.2 plugin SDK was not available, which caused a lot of confusion. The new SDK is now posted, and the building instructions are completely updated.
Beta 11 is out and this hopefully has the final set of SDK changes for 64-bit plugins. Besides a bunch of other fixes (see the release notes), here’s the rough state of plugins:
- 32-bit plugins should just work. If you have a plugin that worked in X-Plane 10.11 but is broken in 10.20, please report a bug – even if it’s not your own plugin! I really want to hear about any of these cases.
- 64-bit plugins should just work; if they don’t, it may be due to programmer error, so please only report a 64-bit plugin problem if you wrote the plugin.
- A new SDK (2.1.2) is cut with real frameworks for the Mac; Sandy and I spent a pile of time working on this, but I need to update the wiki instructions. Docs coming in the next 48 hours I hope.
- Name and shame is gone for linking, so the logs should be clean. If your plugin crashes, you still get named and shamed.
I had a chance to work this week on the Blender 2.49 scripts; here’s a quick update on the status of the scripts and what the next steps are.
Blender 2.49 for Internal Scenery Development
Relatively early in X-Plane 10 development, we picked Blender 2.49 for our scenery development environment. We did this for a few reasons:
- The two artists doing scenery (Alex for cities, Tom for airports) both used Blender 2.49 as their primary 3-d tool.
- There was already a completely functional OBJ exporter (Jonathan’s XPlane2Blender scripts, version 3.09) that produced highly optimized OBJ output.
At the time, some developers were already migrating to Blender 2.5, but Ondrej’s exporter was only partly written. Since we didn’t need any Blender 2.5 features and schedule time was of primary importance, we decided to stick with 2.49 (to avoid the delay of our artists learning a new environment and the delay of having to wait for or develop for ourselves a complete and fully optimized exporter).
The result is that I augmented Jonathan’s scripts to:
- Fully support X-Plane 10 OBJ extensions like instancing, the new GLOBAL attributes and draped geometry.
- Export some of the other v10 data types (autogen, facades, roads). Exporting non-OBJ stuff is really complicated, and the rules to use Blender to make the right meta data are not trivial.
Other Scripts
There are other variants of the scripts floating around: both Ondrej and Ben Russell added partial manipulator export to the 3.09 scripts to help aircraft authors. Ondrej has also created a new branch (the “3.20” scripts) that target Blender 2.50 and newer.
There’s one technical point tot note about Blender that might not be obvious: for all practical purposes. Blender 2.4x and Blender 2.5x might as well be completely different programs! They have totally different scripting interfaces and they don’t even use compatible versions of the Python language. Supporting Blender 2.5x is a from-scratch effort and the scripts are totally unrelated to anything you can use on Blender 2.49.
There is no way to use my Blender 2.49 scripts on Blender 2.5; this is just a decision that the Blender developers made – they created a major fork in the Blender world. So when you read about Blender 2.49 vs Blender 2.50, consider that difference to be as major as Blender vs AC3D or Blender vs 3DS.
Recent Work
This week I had time to integrate both Ben and Ondrej’s manipulator export code into my 2.49 scripts, and I also added the remaining missing OBJ8 commands that are useful for aircraft developers. This means that my scripts are now more or less ready for aircraft use as well as scenery use, and they provide a forward path for Blender 2.49 users who use either Jonathan, Ondrej, or Ben’s scripts. This brings me closer to my goal: making a complete set of 2.49 scripts, current to X-Plane 10.
I have a few more loose ends to tie up, but I am hoping to get the scripts pushed to github for Jonathan (and anyone else who wants them) in the next week. There is still a lot of documentation to add.
I’ve been quiet on the blog both because I was out sick for a few days but also because Sandy and I have been bashing pretty heavily on plugins, trying to determine the best way to prevent plugins from conflicting with each other. The way 32-bit plugins link on OS X/Linux allows one plugin to interfere with another one’s code, which causes support problems in-field. We are looking for any way we can to minimize this for 64-bit plugins.
The short of it is this:
- Name & shame is probably not going to work for DLL linkage. (It will work if you crash!)
- Beta 11 should ship with a new XPLM implementation.
- You should not be shipping 64-bit plugins now. You should expect to retest your plugins against the next beta, and possibly even recompile your 64-bit Mac plugin
I cannot emphasize this enough: it’s not over until it’s over. Just because 64-bit plugins appear to be working does not mean that we have worked out all of the bugs and won’t be making radical changes. Once we are out of beta, things should be very stable, but during beta, this is our only time to get things right.
The last plugin ABI lasted over a decade, so it’s important that we get 64-bit right.
X-Plane 10.20 beta 10 is out, and it features a new XPLM with two new features that help plugin authors detect problems with their plugins; I am jokingly calling it “name and shame” because the new code lists the particular name of the plugin that failed. This will help plugin authors figure out which plugin failed in a multi-plugin environment and help users report bugs to the right third party developer.
- If a Linux or Mac 64-bit plugin incorrectly links against a number of common libraries, the plugin manager will log this on plugin load. This will help authors detect linker setting errors and prevent a recurrence of the plugin conflicts that are quite common for 32-bit plugins. (We do not log these problems with 32-bit plugins because they are very common; in fact, the sample templates for the SDK had the linker set up incorrectly until recently, so fixing these problems is “new” for most authors.)
- If a crash is cause by a plugin (and thus not auto-reported to LR) we log the name of the plugin that crashed.
To this second point, your plugin is charged with the crash if ones of its callbacks was running during the crash. This includes calls in X-Plane code due to your plugin. For example if you call XPLMDrawObject with a bad object pointer and the sim crashes, your plugin gets dinged.
This beta (10.20 beta 10) is the beta to test! If you have a 64-bit plugin, go test it against this new beta to see how well it really works!
I have blogged before about the importance of not shipping products that target beta builds of X-Plane, and the importance of waiting to the end of beta for file formats to settle down.
This also applies to the library! While we are in beta, objects in the library may be renamed or disappear in ways that could break your scenery.
So if you are making custom scenery that uses our library, you have two options:
- Ignore the beta; develop against the last stable release (10.11) and use that library, which we will continue to support.
- Use the beta, but don’t release yet, and be prepared for objects to come and go.
In other words, if your custom scenery works in 10.11 but fails in 10.20, please file a bug – we screwed up.
But if your custom scenery works in one 10.20 beta but not another 10.20 beta, don’t use 10.20 beta objects yet – they’re not fully cooked!
X-Plane 10.20 beta 9 is out and (hopefully) fixes missing library paths. Alex and I spent a good chunk of yesterday trying to clean up the tools that generate the autogen library, but it is a very complicated problem, as indicated by the 4786 distinct entries in the library.
Beta 8 and 9 introduce a change in how the rendering settings work; my suspicion is that users seeing a framerate drop in the new betas are seeing the effects of the intermediate rendering settings acting differently; the minimum and maximum for the settings should produce nearly identical results.
I’m not going to try to explain how the settings used to work – the actual results were extremely convoluted due to quirks in the engine. This change is one of several we want to make to both improve how the settings work (from a usability standpoint) and improve the look of the autogen at lower settings.
- The “objects” popup controls the amount of autogen and 3-d stuff in general. Besides adding more autogen, it adds more detail to the autogen as it appears and can even add more detail to custom scenery. (This behavior isn’t new.) In particular, if you use an a complex library element like an “AGP” scene (e.g. the control tower or FAA building) the amount of detail of that mini-scene will increase with the objects setting. The goal here is to have the objects slider control the amount of 3-d.
- The “forests” popup now strictly controls the density of all vegetation in the sim. This includes both the natural forests (.for files for DSF nerds) and the vegetation that is part of the autogen (e.g. the trees that Alex puts down on the lawns of houses). Lower forest settings tend to prioritize the rural forests over autogen trees to save framerate.
- The distance to which 3-d is drawn is controlled by “world detail distance” – this is how far anything 3-d is drawn out to. Finally with this change, this affects the forests as well as the autogen and the roads – everything runs to the same distance.
A few tuning tips:
- If you are running 32-bits, turn “world detail distance” down by at least one notch; having a shorter distance for 3-d will allow the sim to save some memory.
- If you run with full autogen, moderate forests, and highest world detail distance, you may now need to turn forests up and world detail distance down to create the equivalent of what you used to see. In older betas, the forest setting modified world detail distance in some very strange ways.
Our eventual goal is to keep the autogen base footprints even when the object count is very low; the footprints of the autogen contain views of the building tops, allowing for the equivalent of ‘orthophotos only’ for users with very low rendering capabilities. This will help avoid the ‘sea of green’ effect on lower settings. (The behavior now, where whole city blocks disappear) will eventually go away, to be replaced by the “footprint” with roofs of the city block when 3-d is turned down.
These pictures illustrate the effect of world detail distance. Note that the ground images attached to the buildings are still present even as the buildings begin to disappear with lower settings. The last picture shows the autogen with most 3-d buildings stripped away to reveal the ground tiles underneath.
As we keep working on the autogen system we’ll get more and better ground textures in place, more and better ground tiles on the autogen, and yet more buildings; the result should be a reasonably seamless urban experience at a range of rendering settings.
Some cities are “over-green” in their underlying data in the DSF – this happens when the source land class is difficult to ‘fit’ into the grid system efficiently. (Typically a little bit of vegetation or water area affects zoning and ‘greenifies’ a large area.) We will have to address this problem in DSF tile recuts. (In other words, zoning errors are a failure of accuracy compared to the source data, to be recut; adding more autogen improves plausibility by providing a wider variety of “stuff”.)
Edit: Beta 8 isn’t particularly live; the autogen library is screwed up again (by me). I’m fixing it now and will then recut the beta. I’m looking at what I can do to improve the library generation process – it’s a series of scripts, and as you might guess from the number of times it’s gone sideways in 10.20, it’s held together by shoe strings.
X-Plane 10.20 Beta 8 is now live. This beta does not contain all of the bug fixes I wanted to get into the next beta. But we had to change the networking protocol between X-Plane and Xavion, so this beta is timed to app-store approval.
With that in mind, there are some key bug fixes: hopefully the facade engine is back to sanity (if not, please re-report facade bugs) and I finally found the cause of incorrect fog on the horizon in 2x SSAA mode.
Here’s the main point though: there are still plugin system changes coming for 64-bit that are not yet in this beta. Please be prepared to test your 64-bit plugins against a future beta; do not assume that your plugin is ready to go just because it works now!
Please read the requirements below twice – this is a very particular setup I need. To run this test you must have either:
- A functioning hackintosh running the latest Mountain Lion release (OS X 10.8.x) or a functioning Mac Pro running the latest Mountain Lion release (OS X 10.8.x) and
- An NVidia 560,57,580 or 660,670, or 680 desktop GPU in that machine and
- The computer must also be set up to run of Windows Vista or Windows 7 in Bootcamp and
- You have or are willing to run the 10.20 beta (at least as a demo and)
- You can run command-line fps tests if given instructions.
Please do not reply to this if you do not meet all three hardware requirements; I am looking for someone who can do a clean apples-to-apples comparison of NVidia driver performance between Mac and Windows.
Please do not comment on the post if you do not meet these requirements; I am going to clip the comments pretty tightly on this one.
EDIT: thanks, but a user already sent me the test data I needed!
I hate to put time estimates on anything. The reason: timing is subject to change and always has a ton of uncertainty. What we internally is not a schedule. A railway has a schedule; we have a plan, a roadmap, or some goals. Betas are full of uncertainty. We don’t know what bugs are in the sim – if we did, beta would be over a lot faster.
So: this is my current thinking on the timing of the rest of the 10.20 beta, as of now. It will be obsolete within five minutes. Since most of the time schedules get screwed up by things being late (if we were ahead of schedule we could just choose to not release to be on schedule 🙂 this is post may be useful for third party developers trying to plan releases.
If things go well, I believe we will be able to build a 10.20 release candidate this year. (That’s a tighter goal than it sounds – there are only two weeks left.) I think we will not finalize that release candidate this year; more likely we’ll sit on the release candidate into a little bit of January. The release candidate will hopefully be settled enough that there are not any engineering surprises for third parties if we have to recut the release candidate.
If things go badly, we won’t be RC this year – there’s always the chance that someone could have a sick kid, a power outage, new bugs could be found, you name it. Life is full of uncertainty!
I do not know what autogen will get dropped into the beta or when. If we have autogen that is almost ready for 10.20 but misses the release deadline, we’ll drop new art assets into a 10.21 or 10.22 – it’s very easy for us to do a bug fix patch with more “stuff” in it.
If I was gambling, I’d bet that there will be a 10.21 anyway – what we found with 10.10 is that a lot of users didn’t participate in the beta, and thus we got a flood of bug reports right after 10.10 went final. This can be frustrating for us (in that it means that our beta coverage isn’t as good as we’d like in terms of hardware configurations) but it’s also good in that it means that the entire community isn’t in on the beta (something we don’t want – we don’t want to expose every X-Plane user to beta bugs!).
Edit: Normally I label the overly technical posts as being for a target audience, but I did not this time. My bad — this post is really only of interest (and will only make sense) to serious 3-d modelers – the advanced airplane and scenery nerds!
The brightness of specular hilights is out of sync between HDR and non-HDR mode in X-Plane 10.11. This wasn’t intentional – it’s a bug. 10.20 will fix this; specualr hilights will have the brightness you see in non-HDR mode (which we think is more like they were supposed to work*) but the tinting of HDR mode (non-HDR mode was overly red in 10.11).
I get a lot of requests for ‘hardness’ control – that is, the exponent that controls how wide a specular hilight is. We’ll get this feature eventually – it’s too important to ignore. The main delay in having this feature is that X-Plane uses a deferred renderer, so the specular exponent has to be stored in the G-Buffer somewhere, and storage is tight.
For similar reasons, it is very very unlikely that we’ll ever have RGB tinting of specular hilights. Doing so is 3x as expensive in G-Buffer storage, and we need that storage for other features.
* That is, unless we discover that non-HDR mode looks spectacularly bad in some cases, in which case we may have to push things a little more toward how HDR was.
