As some of you may be aware, Blender 2.49 is old unsupported software that is becoming increasingly less usable on modern computers. To make matters worse, authors have large projects that are currently stuck on this platform, jeopardizing their work!
We are creating a 2.49 XPlane2Blender converter inside of XPlane2Blender 2.7x, so that opening a 2.49 Blend file in 2.7x will automatically convert meshes, animations, materials, lights, textures, and XPlane2Blender properties into a modern format. This isn’t just an idea, we currently have a strong proof of concept that animations can be converted from old to new!
The 2.49 Converter Needs Your Help
The goal is
That if it exports in 2.49, it exports in 2.7x as similarly as possible. That the conversion process is hassle free and also transparent. That your work is safe and won’t be lost if there is a problem.
To accomplish this we’re going to need a lot of test .blend files and projects – to make it work for artists in the wild we need projects in the wild! We’ll take anything working and not working.
All source files will be kept secure and confidential within Laminar Research, and only used for this feature of XPlane2Blender, unless you make it open source.
Given that we’re trying to convert EVERYTHING, including materials and textures, it would also be extremely nice to have all files referenced as well.
Any description you’d like to include (preferably in a text block) would be nice too.
Again, just as with any other time someone sends me a sample to debug, it is kept secure and private, kept only for as long as needed, you can ask me to delete it at any time, and is only used for the development of that specific bug or feature of XPlane2Blender. They would never be used to develop any Laminar Research asset.
If you’re willing to submit a project to me, please get in contact via e-mail, DM, comment, or especially Github bug #397.
This beta brings in many new bug fixes and heavily requested new features! As with any beta, be aware that this could break your project SO MAKE BACKUPS! We don’t think there are any drastic changes to the data model, but, better safe than sorry.
#355 – A small UI fix relating to too many manipulator fields being shown
#360 – A bug fix for Drag Rotate manipulators giving false negatives
#353, #363, and #260 – All relate to warning people and correct what was allowed with NORMAL_METALNESS and BLEND_GLASS. Previously Blend Glass was in the same drop down menu as Alpha Blend, Alpha Cutoff, and Alpha Shadow. Now it is a checkbox allowing you to correctly specify a Blend Mode and apply Blend Glass to it. Existing materials with Blend Glass will see this new checkbox automatically checked. Blend Mode will be set to Alpha Blend or, if your plane is old enough to have been worked on during X-Plane 10, it will be set to whatever it was back then.
See the internal text block “Updater Log” for a list of what got updated, including this. You may see, for example: INFO: Set material "Material_SHADOW_BLEND_GLASS"'s Blend Glass property to true and its Blend Mode to Shadow
#366 – An Optimization! Useless transitions in the OBJ were being written, now they’re not. Custom Properties still work, there won’t be any visual changes to your OBJ. We haven’t done any profiling but it might have decreased OBJ loading time by a small amount too.
Command Search Window
Thanks to #361, just like the Datarefs.txt Search Window, we now have the same capabilities for searching Commands.txt (for manipulators). We are shipping with X-Plane’s latest Commands.txt file, but of course you can replace it with your own (as long as you keep the name the same). One day we hope to make it much more flexible.
Particle Emitters (not very useful to most yet, I know)
Thanks to #358, some people who have access to X-Plane’s cutting edge particle code can use XPlane2Blender to specify particle emitters. Don’t worry, we’re all working as hard as we can to get these into the hands of others. Fortunately, XPlane2Blender users can hit the ground running the minute it drops!
Build Scripts And Test Runners
#302 and #307 – Are you a professional XPlane2Blender maintainer and developer (if so we should probably talk!) Then you need a better build script, and a test script to match! Introducing mkbuild.py, the build script for the modern developer! It creates, it tests, it renames without messy mistake prone human intervention! To top that off, how about a testing script that doesn’t give false positives!
I hate finding out about these kinds of bugs late in the beta. But this one was pretty big.
X-Plane uses a “metalness” material model. Metalness is a fairly standard material model that recycles the albedo of your material to implement both dialectrics (non-metals) and metals. It works like this:
Non-metal: diffuse light is tinted by the albedo texture. Specular light is not tinted.
Metal: there is never diffuse light. Specular light is tinted by the albedo texture.
In other words, since metals don’t have a diffuse component, we recycle the albedo to save texture space.
The bug in 11.05 is that for a pure metal, the albedo was tinting ambient light but not the sun itself. A third party developer sent me a test model that showed the problem – here’s the before and after.
That weird set of colors on the top of the helicopter body is due to the white sunlight being added to the red body. The red aircraft body is lit by ambient light reflected directly off of the environment. The runway stripes are not visible because the metal is about 30% rough, diffusing the reflection.
(One of the confusing things about PBR models if you are not used to them is that the environment itself can cast both diffuse light and specular reflections off of a material, and if the material is rough, it can be hard to tell them apart. Diffuse light is always widely diffused, no matter how glossy the surface.)
Alex and I took a look at some of our legacy aircraft and found that fixing the lighting didn’t make too much of a difference for metals that are not tinted.
Since our aircraft don’t have any “tinted” metal there isn’t much change. Note that in real life heavily tinted metals aren’t common. The cases you might have are:
Approximations of metals with complex spectrum-dependent fresnel like gold.
Composite paint, e.g. like for your car, with fleks of metal and translucent dielectric polymer mixed together – that’s the case where this really helps.
As I wrote this up I realized that the spot lights are still wrong in beta 8 – they’ll be fixed for RC1 unless people really need the old model, in which case we’ll have to put some versioning in. My guess though is that anyone doing composite paint realized it was impossible in 11.05 and hasn’t shipped anything like that yet.
In these comparisons we are under an airport light viewing various materials. In the multi-color case the bottom row of materials are various “metals” with light tinting to simulate copper, iron, gold, etc.
In the second set of cases (all red) we have a 2-d grid: metal on the bottom, dialectric on top and rough on the left and glossy on the irght. Note that the reflection of the overhead light is reddish for the metals and white for the plastics in 11.10 (correct) but all white in 11.05 (incorrect).
One big massive bug fix! (and some optimizations!)
#264 caused some people’s lights to be put in the wrong place. The fix involved Ben coming up with awesome math to put things back in their place by a certain offset, and then us creating a way to parse the light.txt file that controls much of the lighting in X-Plane.
This Changes Nothing in Your Blend files!
Seriously! No Blender data should change!
However, It Could Change Your OBJs
XPlane2Blender is now more consistently WYSIWYG! Meaning that if you point a spotlight at a wall, it should show up pointing in that direction, regardless of what a named spill light thinks or the parameters of a param light think.
This is good news for new authors and authors suffering from the bug, but depending on how you’ve been making your lights appear rotated, it could result in needing to change the rotation or parentage of existing lights.
What Lights Are Affected?
All of the following conditions must be true for a light to be affected by this change
Be a Blender non-point light, for instance a spot light
The light’s XPlane Type must be Named or Param
The light’s XPlane Name must be found in the lights.txt file inside the addon’s new resource folder
In rare edge cases, special and less used lights will be excluded from auto correction.
So, as you can see its either somewhat common or very specific which lights are affected. So, if your eyes haven’t glazed over yet,
Please Send Reports Of How This Affects You – Good, Neutral, Or Bad!
We try our best for backwards compatibility and a bug free existence, but we don’t know everyone and their situation until they say hi! If you are faced with large hurdles to continued productivity, please file a bug! Preferably with before and after pictures and .blend files. Automated fixes may be developed for people affected.
This is just one step to a more WYSIWYG XPlane2Blender.
The next version of XPlane2Blender is right around the corner, come test it! Highlights of this release are Optimized Animations, Increased Usability, and X-Plane 11 OBJ8 features (mainly Blend Glass mode and Normal Metalness). Read more about what has been changed on the release page and download it!
(Link to beta removed until major breaking bug has been fixed. Make backups of files before using any beta product.)
As with any beta, make backups before using a partially tested product. We don’t predict there should be anything breaking in it, but its never a bad idea to be safe.
Bugs and feed back on Github is preferred over this comment section, but most of all I want to hear your feedback. To stay focused, only comments related to XPlane2Blender, the beta, and Blender will be responded to for this section. The status of other 3D Modeling Plugins/VR/Weather Systems/etc is off topic.
Please tell me what confuses you about XPlane2Blender on this bug, or here!
We are going to be releasing the XPlane2Blender 3.4 beta soon, and with it, a refresh of the UI and documentation. Thanks to a great e-mail about a lack of documentation, it was put as an important part of 3.4 release roadmap. It goes to show… we can’t fix it if we don’t know what’s wrong, even if its not a code problem. And we do want to fix it, I swear!
In addition, I want to remind everyone a core part of the Laminar Research philosophy, identity, and business plan is a thriving modding and third-party plugin ecosystem. Aside from build scripts and the like, Laminar Research employees use the same scenery development tools that are available to all. This is was a deliberate choice that elevates everyone to the same level – except when there is a gap of knowledge. This is never intentional, and never benefits anyone in the long run, especially third-party-devs. If your work is suffering because we forgot that not everyone knows what every little checkbox means, tell us! We’ll put it in the bug queue like everything else, and try to get back to you, personally, quickly.
We’ve been working on a single comprehensive document for aircraft authors – everything that changed in X-Plane 11. Jennifer has posted a draft here. This is still a draft, and we still have work to do, but there’s a lot already there, so we figured better to post it and let people comment and get started.
For entirely new features, we are creating separate articles on how to use them – it would be a little weird to have to look up “v11 aircraft checklist” to learn to use FMOD. This means that this document refers to some unfinished (and unpublished) documents that will be coming soon.
One of the changes listed in the document is that we changed the blending in X-Plane from blending in sRGB space to blending in linear color space. This is a universal change. It affects: all 3-d drawing, including everything drawn with an OBJ and the 3-d drawing of the panel texture. It does not affect:
Plugin-based drawing in any 2-d drawing callback, including plugin UI drawing.
Drawing into the panel (either via Plane-Maker instruments or plugin code).
In other words, your panel is composited in 2-d as it was before, but the usage of the alpha channel of that final panel texture is different.
How Am I Different?
The notes say blending is now linear and not in sRGB space. What does that actually mean, and how does it affect you?
Take a look at the color gradients in this blog post. (The whole post is really good, but the gradients show this issue). When you have a surface with intermediate alpha, you’re getting the intermediate gradient of the thing behind your surface and your surface’s albedo, with some fraction determined by the alpha.
As you can see from the chart, the intermediate colors are all brighter with the new linear blending. This intermediate brightness is more like what you would really see when working with translucent materials; the old model was losing light energy.
(X-Plane 10 was linear in the entire rendering engine except blending – we kept blending in sRGB space – it was very complicated and messy to do and hurt performance. So it was a priority to make things both faster, more correct and less insane on the code side for X-Plane 11.*)
What Do I Have To Do To Tweak My Textures?
Let’s get practical: textures with alpha will not look the same as in X-Plane 10, and while sometimes the new result is just better (light colored alpha-based lettering on panels almost always looks better in v11 out of the box), sometimes you’ll need to retune your alpha channel.
In pretty much every case, the new blending is brighter in intermediate values than the old one, which was losing light. (When we stop losing light, the net result is an increase in light.) So these cases will all involve ways to back off the brightness; you probably made things overly bright in X-Plane 10 to compensate for non-linear blending.
Here are a few typical examples we saw when exploring this feature with our art team.
Tinted Glass: tinted glass typically suffers from two problems:
It’s just not dark enough.
The tint color itself is too bright and now “shows” a bit, e.g. non-colored tinted glass looks light gray.
First: make the RGB of your texture darker if possible. Dark tinted glass should almost certainly have a black RGB (and use alpha for “how much” tinting).
Then: adjust the alpha as needed – if darkening the RGB didn’t do it, increase the opacity.
Painted Reflections: if you’ve painted reflections onto your glass, they may look too bright.
First: consider letting the engine be the reflection source – you may want to use BLEND_GLASS for cockpit glass and/or use metalness to increase reflectivity. Do these things first before editing albedo and alpha textures; they have a much bigger impact on your scene than the new blending mode.
Then: when done (or if you will not make these changes) decrease the opacity to turn down the reflections.
Dirt and Grunge: we found that our black markings on the ground looked too light – they were using alpha to anti-alias the edge of the marks and simulate pixels that contained a mix of dirt and the underlying surface in a single point. (This particularly matters when you zoom away from the marking and it becomes small on screen).
First: make sure your RGB channel contains correctly dark colors around the edges of the decal. (In what I’ve seen, artists pretty much always get it right in this case.)
Then: increase the opacity of the effect to make it darker (by emphasizing the dark decal more than the lighter pavement.
As a general rule of all of these, the RGB of a blended surface should be very dark (decals, tinting) or very light (fake reflections) and not be mid-range. Then the alpha can be made more opaque to darken darks or more transparent to darken lights.
* Nerd’s Nook: If you known enough OpenGL to be dangerous, you might be asking “Ben you idiot, why don’t you just turn sRGB blending off and on based on whether the content you are drawing is new to X-Plane 11 or old from X-Plane 10? You can just use glEnable!”
Sadly we cannot. In the forward renderer we might be able to toggle the blending mode per object or something, but in the deferred renderer (HDR mode), we blend all albedos together, all lit textures together (during G-buffer setup) and then we add the total lit to the total albedo during the single lighting pass where we apply the sun.
Basically we’re taking the math of the blending equation and rearranging the algebra. This rearrangement only works if the color space for adding the lit and albedo together is the same color space as every blending operation.
So for HDR to work, we have to pick a single blending equation sim-wide because we have to pick a single way to add lit and albedo together. For X-Plane 10 we picked sRGB color space and for X-Plane 11 we picked linear. Linear is a total win here – besides looking better in a lot of cases, adding lit textures to albedos looks better when done in linear space too. After all, we are adding light.
I just found a bug in beta 15 (and 14, and 13, and 12..etc.): if you use ATTR_shiny_rat or GLOBAL_specular with an intermediate value, e.g. between 0 and 1, you get an oily effect when HDR is off.
This is a bug in one of the shaders. We didn’t see it early because I have encouraged our art team to set the specular ratio to 1.0 and leave it there and use the normal map to modulate specularity. You should take that advice too! The GPU is really good at reading textures, and the CPU is not particularly good at interrupting the GPU to change what it’s doing, which is what ATTR_shiny_rat does.
Beta 16 will fix this; in the mean time, what you see in HDR mode (the top two FX settings) is correct, for the purpose of figuring out if your art looks good.