This is a beta so make backups of your work before using!
Custom Spill Lights
Custom Spill Lights are now implemented (#312)! To use, make a light datablock with the XPlane2Blender light type as Custom Spill. Relevant properties are:
RGB color for the light
Spot light direction
Light Spot Size
The width of spot light
Size parameter (in meters)?
Dataref that controls the light
Custom Spill lights can make dataref driven custom omni-directional billboards and directional spot lights. As with Automatic Lights, the goal is What You See Is What You Get.
In this photo the green light is a Custom Spill, where sim/graphics/animation/lights/traffic_light changes the color between green, yellow, and red! The white lights have different widths, all made without doing any math by hand.
X-Plane has pre-made high quality GPS devices that are easily accessible to the artist. Thanks to (#481) using one is as simple as making a mesh, and giving it a material with a Cockpit Device set. Pick the device, at least 1 electrical bus (matching Plane Maker), the lighting channel, and if the screen’s brightness should auto-adjust. You’ll get a fully functional GPS device just like that! You can have multiple devices in the same OBJ, as well as use of the panel texture.
The Cessna’s cockpit provides 2 great examples of using cockpit devices.
Cockpit Features UI
Given the changes and additions to our Cockpit Features, the UI has been changed slightly. On the material Properties tab use the “Cockpit Features” to find “Cockpit Regions” and “Cockpit Device”. The updater should adjust the setting for you if you were using regions.
(#426) Shadow Blend’s Blend Ratio can finally be set. Thanks @kbrandwijk! (#548) Non-Exporting Lights are back in. They’re intended as “work lights” and will never ever show up in the OBJ! Simply set the X-Plane Light Type to “Non-Exporting” and use freely.
Light Level can now be used multiple times in the same .obj without tricks or getting lucky!
Thanks to everyone who downloaded alpha.1! I’m glad that this series has been so successful and I can wait to see what you make with the new light features! As always make backups!
This alpha contains changes to the updater. Make backups before using!
Global Material Settings -> OBJ Settings
This new version contains one of the most requested fixes (#357, #599) for XPlane2Blender: Normal Metalness, Blend Glass, and Global Tint have been moved out of the Material Properties Tab and into OBJ Settings! The annoying “All Materials in an obj must have the same Normal Metalness/Blend Glass Value” error is gone!
The updater tries its best to guess if you wanted Normal Metalness, Blend Glass, or Global Tint, however it isn’t perfect. If you have to manually correct more than 3 of your OBJ settings, please tell me.
These new settings can be found under the Textures section of the OBJ Settings.
Emissive Panel Texture Only and Panel Mode Selector
#595 Also known as ATTR_cockpit_lit_only, this directive has actually been in X-Plane since 11.10, but now is accessible in XPlane2Blender! It makes a panel only use the emissive “Lit” texture – a great speed boost if that is all you need. This is the perfect feature for computer displays.
For Aircraft or Cockpit export types, look in the Cockpit section for “Panel Mode”. This changes the meaning of “Part of Cockpit Panel” for the whole OBJ. Setting it to “Emissive Panel Texture Only” mode activates the feature. You cannot mix panel modes.
People who use Cockpit Regions will have to manually change “Panel Mode” from Default to Regions to see the UI and have regions export again. A one time fix. A future updater will do it for you. Until then I hope it isn’t too many OBJs to change.
Updater Version History Synchronization
#471 The updater now synchronizes its last version across every scene and new updater functions will not use data cleaning to protect against accidental or purposeful updater re-runs. Simply put this means a safer to use XPlane2Blender (but still make backups). Since this is new updater code, however, it had to be put in an alpha. People with multiple scenes should be especially on the look out for problems. I feel very confident about it however.
With testers and users like the ones XPlane2Blender has we’ll be getting to v4.1.0-rc.1 much much much much faster this time! For the users who requested moving Normal Metalness and Blend Glass, thank you for your patience. I know now just how annoying that error message was! I’ll certainly keep this experience in mind for future decisions and don’t worry, “make it the same across every material” is not going to be chosen again without an extremely important reason!
As always, make backups! This includes making backups before saving a 2.79 file in 2.80. There is no going back from that!
Override LODs feature and backwards compatibility
A quick LODs recap
This release includes the last must-have feature for 2.80 – LODs. For those who haven’t used LODs before, it stands for (Levels of Detail).
It is a way of defining what to draw when the camera is a certain
distance away from an OBJ. In XPlane2Blender we call those ranges
“buckets” and put Blender Objects (meshes, lights, armatures, empties)
“inside them”. For instance, suppose an OBJ of a hanger with 2 defined
ranges (buckets) 0 to 200 and 200 to 400. It has two meshes
“HangerDetailed” (bucket 1) and “HangerLowPoly” (bucket 2).
When the camera is close (0 to 199 meters), only the “HangerDetailed”
mesh will be drawn. When it is far (200 to 399), only “HangerLowPoly”
will be drawn. At 400 meters and above, nothing will be drawn. This is
very useful for increasing the performance by not drawing what is too
far away for the pilot to see.
There are two styles of Level Of Detail: Additive (where every bucket
starts at 0) and Selective (where the end of one bucket and start of
the next are equal (see example above)). Use one or the other depending
on what you need to draw when; don’t mix between them.
LODs Mode in XPlane2Blender
Using LODs in XPlane2Blender is very easy: Define the ranges
(buckets) in the OBJ settings, and tell Blender Objects which buckets
they should go in.
“LODs Mode” is considered On when you have specified a number of LOD buckets in the OBJ settings.
This means that:
LOD validations are on (see later section)
Objects must be placed into defined buckets or they will not be
drawn. This is where the new “Override LODs” checkbox on Blender Objects
comes into play.
The LODs feature works just like 2.79’s Layers Mode LODs, with a new
time saving feature and some very small backwards compatibility notes.
In the Object Properties Tab of the Properties Editor, you’ll see a new “Override LODs” checkbox.
When checked, the familiar 4 LOD bucket choice checkboxes will appear.
Specify which buckets an Object will go into. All children below it
will also go into the same buckets. Children who also override LODs will
pass their new choices on instead.
In this picture HangerDetailed has its “Override LODs” checkbox checked,
and has been placed into bucket 1. Its child, WindowDetails, will
automatically be placed into bucket 1 too.
An Object’s LOD choices will only be used if “Override LODs” is checked.
The idea is that just a few objects in the Blender Hierarchy will
need to override the LOD choices, and old projects can be quickly
reorganized to take advantage of this new feature. Inheritance will
greatly reduce data entry.
There are only a few differences from 2.79 to be aware of
Backwards Compatibility Concern
In 2.79 “No buckets chosen = Write to every LOD“. In 2.80 “No buckets chosen = Object not written“
Use the new feature to quickly specify which objects should be in all buckets
2.79 Layers Mode projects did not have an “Override LODs” checkbox, LOD choices hidden
Your old choices are remembered. Use the new Override LODs feature to quickly get the OBJ correct again
2.79 Root Objects Mode used layers 1-4 to put Objects into buckets
Quickly restore your project like this: Make an Empty for each layer
used, override the Empty’s LOD buckets, and re-parent the objects so
that all Objects are in their former buckets. If an object was used on
more layers, make more empties to organize these cases
For mistakes like not starting the first bucket at 0, having gaps or
overlaps between ranges, and etc, an error will be emitted in the log.
Other Bug Fixes
#518 – When Export Type is “Cockpit” LOD buckets is now shown.
#512 – “Deck” (a rarely used Material property which controls how planes
collide with this surface and the area beneath it) is now renamed to
“Only Slightly Thick” implying that this collide-able surface is “Only
Slightly Thick” as opposed so something that “extends the earth up to
that surface”. Imagine a bridge that could not be flown under because
under it is “an invisible mound of rock and world surface” vs a bridge
that can be flown under because “its deck is only
slightly thick”. Get it? Well, maybe the new name will make more sense
to everyone without needing to know this example.
#511 – People will now be able to use a Particle System File again
#276, #525 – Some UI cleanup. “Scenery Properties” will no longer be shown when
Export Type is Aircraft or Cockpit, “Autodetect Textures” is no longer
drawn because it doesn’t do anything and confuses people on how to use
an essential feature: specifying texture paths. The value isn’t removed
and one day we’ll have that feature back in some form.
Many thanks to all the people who e-mailed me and helped me design
the new LOD feature. This is an alpha feature so if the overall response
is “this isn’t doing what we need” it can be ripped out, but, I think
it will meet expectations. Also, especially tell me if it difficult to
take a 2.79 project with LODs and make it work again. The goal is that
it an artist should be able to do it in about 5 minutes without the use
of an updater for most projects.
I’m so glad to be working on a project with users who are very
willing to send in good bug reports and great constructive feedback and
criticism! Very refreshing! As always, if something goes wrong write a
bug report (preferable) or e-mail me!
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.