Releases: X-Plane/XPlane2Blender
XPlane2Blender v3.5.1-beta.1
Release Notes
XPlane2Blender v3.5.1-beta.1
It has been some time! I have been working as hard as I can on the converter (to great applause so far!), but, there have still been some features and fixes developed along the way. By now it was time to collect and release them!
As always This is a beta. It makes data model changes which may still have bugs. Make backups!
Features
"Cast Shadow (Local)"
Previously, you could only set "Cast Shadow" to be on or off for "Scenery" and "Instanced Scenery" export types. This would, for the whole object, turn on and off shadows. Now, "Cast Shadow" has been removed from the OBJ settings and "Cast Shadow (Local)" has been placed in the material settings. With this, individual meshes can have shadows or not and it works for Aircraft and Cockpit objects too!
Compare the cones and cubes on the left with the ones on the right. You'll see the power of being able to selectively turn off shadows.
- If all materials used in an OBJ have "Cast Shadow (Local)" set to on (the default), everything will have a shadow.
- If all materials used in an OBJ have "Cast Shadow (Local)" set to off, all objects will not have a shadow. If the export type is "Scenery" or "Instanced Scenery", a performance boost will be applied.
- If some materials have it on and some don't, X-Plane will draw shadows only for the meshes you want. This is useful for performance around small complex meshes
"Cast Shadow" Updater
The updater does its best to recreate what XPlane2Blender 3.5.0 exported:
- If "Cast Shadows" was On, all materials will have "Cast Shadows (Local" on
- If "Cast Shadows" was Off, all materials will have "Cast Shadows (Local)" off
- If you have a material datablock that was shared between OBJs with different "Cast Shadow" values, the updater will give you a report of which OBJs may no longer look the same without intervention. You may need to change "Cast Shadow (Local)" or duplicate materials so each OBJ gets its own copy that is uniform.
An Example of Number 3
In this example, I have 4 OBJs ("Planes", "Cubes", "Cones", "Rings"), Yellow means "Cast Shadows" was off in the OBJ, grey means "Cast Shadows" was on. The material Material_shared_1_should_be_on
shared across the some of the cones and rings.
In this picture, the four selected objects, share the same material Material_shared_1_should_be_on
.
The updater knows I'm about to get weird shadows turning off and on unlike before, so in the Updater Log it says
ERROR: Material 'Material_shared_1_should_be_on' is used across OBJs with different 'Cast Shadow (Global)' values:
Ambiguous OBJs | Cast Shadow (Global)
------|---------------------
Cones | Off
Rings | On
INFO: 'Cast shadows' has been replaced by the Material's 'Cast Shadows (Local)'. The above OBJs may have incorrect shadows unless 'Cast Shadows (Local)' is manually made uniform again, which could involve making duplicate materials for each OBJ
To correct this, I made a duplicate of the material and used it for the cones. I unchecked "Cast Shadow (Local)" for it, and now Cones.obj has no shadows again!
If you are in this situation, please let me know how many materials across how many OBJs needed fixing and what you would have to do to get your old OBJs back. Although I asked and asked for an idea of how often people have .blend files with multiple "Cast Shadow" values and how often materials would be shared across them, I still want to hear feedback. If this was a terrible decision, tell me. If this is a rare edge case as I was told, tell me. If you are a rare edge case and need help clicking through a lot of stuff, tell me! I can help!
MAGNET VR Tablet Mounting Point
The Empty datablock a new special type - "Magnet". This defines where on a yoke the VR tablet can be attached. Simply make an Empty, set it's Type via Empty Properties > Data > XPlane > Type to Magnet. Position and pick the magnet type (at least one checkbox) and export. Easy!
Major Bug Fixes
- Smart manipulators can use Show/Hide animations again! This was an unwritten requirement, and a bad one so we got rid of it!
Minor Bug Fixes
- #422 Flash, Strobe, Pulse, Traffic light types no longer crash exporter. It was very surprising that this didn't get reported sooner - I guess the feature isn't used at all anymore
- #421 Several
sim/graphics/animation/lights/
lights were getting autocorrected when they shouldn't have been. Specificallyairplane_landing_light
,airplane_landing_light_flash
,airplane_strobe_light_dir
, andairplane_generic_light_spill
.
Also discovered but not fixed in X-Plane airplane_strobe_dir
should really really only be used with RGB as 0 0 0 and XYZ aiming the light. Just in case anyone is searching desperately for how to use this light.
- #411 Blender Objects must now be in the same scene that you started exporting in. For instance if
MyEmptyRoot
is inMain Scene
andMyCube
(whose parent isMyEmptyRoot
) is inSecond Scene
,MyCube
is simply ignored while exportingMyEmptyRoot
. - #395 No more clicking the "Add LODs" button! It just happens for you. Yay!
- #393 Changed some UI text from "Draw Linked Objects" to "Draw Objects With Material"
- Fixed bug stop pit bug where pit at start would compare it's height to the last in the list, causing errors.
XPlane2Blender v3.5.0-rc.1
XPlane2Blender v3.5.0-rc.1
XPlane2Blender is now X-Plane 11.30 ready! Not much has changed since beta.3, just some fixes to the particle stuff.
Bug Fixes
#373 - Test Script's --filter flags now needs less escaping for its regexes
#377 - Show/Hide animations on empties is now being exported again
#384 - Particle follow non-colocated animations
Sound Emitter has been removed from the Empty Special types menu. One day it will be back in!
XPlane2Blender v3.5.0-beta.3
XPlane2Blender v3.5.0-beta.3
This small update has fixes related to particle emitters.
UI Changes
Special Empty Types has been moved from the over bloated Objects tab to the Data tab. In addition, a checkbox enables and disables the use of the Array Index.
Sound Emitter is still in the menu even though we don't have sound emitters because I'd rather not mess with enums when it is just going back in there anyway.
Bug Fixes
XPlane2Blender v3.5.0-beta.2
XPlane2Blender v3.5.0-beta.2
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.
Bug Fixes
- #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 asAlpha Blend
,Alpha Cutoff
, andAlpha 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.
Features
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!
XPlane2Blender v3.5.0-beta.1
XPlane2Blender v3.5.0-beta.1
This beta has new features and changes to the data model! We don't predict they're particularly dangerous changes, but as always, make backups of your work!
Dataref Search Window
Next to any Dataref Path text field will be a Zoom In magnifying glass. Clicking on this will open the new Dataref Search Window!
You can scroll through the list or search for datarefs using X-Plane's Dataref Editor syntax.
In this picture, we're searching for anything that matches (sim/cockpit
AND N1
) OR (sim/cockpit
AND N2
). Only the dataref path is searched, the units field is not.
When you click a dataref, it will be inserted automatically in the associated Dataref Path text field.
You can also click the Zoom Out symbol to close the Search Window without selecting any dataref. The datarefs it searches through come from the included Datarefs.txt file. The search window lists, in order, the path, type (and array size), if it is writeable, and its unit. Description is not included.
Virtual Reality Manipulators!
Virtual Reality manipulators for simulating throttles, rotating objects on a hinge, dragging flap levelers, trim wheels, and other such devices can now be specified in XPlane2Blender! Set your X-Plane Target Version to v11.1x in the scene settings to gain access to these. Backwards compatibility note: these manipulator types are not available in previous versions of XPlane2Blender!
Manipulator Property Autodetection
Previous manipulator types required much data entry to put in things like DX,Y,Z, values, and used datarefs. New smart manipulators autodetect these for you!
- Drag Rotate (useful for Trim Wheels)
- Drag Rotate With Detents (useful for throttle quadrants)
- Drag Axis With Detents (useful for flap levels)
- Drag Axis (the old manip type now enhanced. Opt into new autodetection by using the checkbox
Autodetect Settings
)
All of these can inspect their animation and parent's animation to find these properties, but datarefs can always be overridden and set manually, similar to how textures can always be overwritten and specified manually. This should be very very rare
The requirements for what chains of animations are needed to use seem complex but have a constant pattern to them. See the Animation Requirements For Smart Manipulators for more details.
Custom Light RGB Overrides
If you're a person who uses Custom Lights (which are not deprecated but also not recommended!), and need a way to put in custom values for RGB (since new Blender color pickers don't allow negative and custom color values), you now have a new checkbox and properties to help you.
As far as I know there are an extremely small number of authors who use Custom Lights, so if you're saying "What? Custom Lights? Color Picker?", don't worry about it.
XPlane2Blender v3.4.0-rc.2
XPlane2Blender v3.4.0-rc.2
This RC has two simple fixes that are non-breaking and totally awesome.
- #347: Optimization that brings export time down by a third to a half. The file size remains the side and nothing is needed to activate it. Using the "Optimize" checkbox was not optimized this time around.
- #350, #351: Two animation bugs that would cause strange offsets when using bones. You may or may not have experienced this. Again, there is nothing to do to activate this, it is part of every export.
If you run into problems, please file a bug. If you do not notice a decreased export time with large models, also please tell us. We'd love to benchmark this on more data.
XPlane2Blender v3.4.0-rc.1
XPlane2Blender v3.4.0-rc.1
We made it people!
Change log
This release encompasses all of the beta. You can read through the beta notes for more details, but, here are the highlights:
New Features
- Single button to "Export OBJs", skipping the file selection box
- Autocorrecting spot lights - the light points where you point it, not where the parameters tell it to go!
- X-Plane 11 support for Blend Glass, Normal Metalness
- New clean UI, better laid out, more consistent look, and some properties smartly hide when they're invalid or not relevant
- Support of 1 LOD box
- Enhanced build number and plugin history to help debug files and track update problems. After installing this rc.1 version, your scene settings should look like this. The green check mark means "most safe" to use.
- No more reading the lights.txt file. The list of lights and their parameters can now be found online
- Though unsupported and largely irrelevant to most authors, a "Plugin Development" section has been added with some neat tools that you probably shouldn't use.
- EXPORT directive (really only useful for LR toolchains. Documented here for posterity's sake)
Important bugs
- Animations have been optimized
- Bones, nested bones, and complex parent-child relationships with armatures now work better,
- Animation types have been synthesized to just Transform, Show, and Hide instead of Loc, Rot, LocRot, Show, Hide
We could not have gotten this far without the incredible support of our beta testers, new authors, bug reporters, and all the wonderful artists who give us the inspiration and energy to make this product better! It has been an incredible journey diving into this facet of the community and I look forward to even more releases, including VR manipulators, full WYSIWYG lights, and more!
Thank you!
XPlane2Blender v3.4.0-beta.7
XPlane2Blender v3.4.0-beta.6
XPlane2Blender v3.4.0-beta.6
Change Log
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.
XPlane2Blender v3.4.0-beta.5
XPlane2Blender v3.4.0-beta.5
Change Log
New Features
Build Version Numbers
XPlane2Blender's new version number system is will allow us to debug .blend and .obj file even faster. It should also make making updates to the data model easier to implement.
- Every exported .obj file's footer contains information about the addon version, when it was compiled, and why. For example:
3.4.0-beta.5+1.20170922151901
A break down of the components
3.4.0
: The traditional Blend addon numberbeta
: The type of build cycle we're in. Other choices you may see aredev
(a developer build),alpha
,rc
(for full release)5
: the build type version we're on. Since this is beta 5, the build type version is 5.
The elements after the + are generally less meaningful to the average user
1
: The version of the data model (the properties and settings for XPlane2Blender, used for comparing changes20170922151901
: The "build number" date this source code was packaged and released in the form of YYYYMMDDHHMMSS in UTC.
Communication
The build version number is partially shown (elements after the + are hidden) in the scene settings under Compile Normal-Textures
, potentially along with warnings about the stability of the build you are using.
Examples
When starting this version of the beta, you will see this:
A future stable version of 3.4.0 for the general public will show this:
Notice the green check mark and lack of any warnings.
In a future pre-alpha cycle for 3.4.1, two types of people will see the follow:
- A developer writing and testing unreleased code
- Someone who didn't head the warning against using such code, or get scared off by the nuclear symbol and extra warning about a lack of a build number
It is the worst case scenario for stability and traceability, hence the nuclear symbol.
Why the extra warning about a lack of a build number?
A lack of a build number indicates that you do not have a good dialog (e-mail, chat, this release page, or other channels) with a knowledgeable and attentive developer. This means your work is more likely to be run through a bad version of the code and damaged, or your bugs will be harder to diagnose and repair.
In this case, despite the code appearing to come from a stable era of the code near a release, there is potential for something to be wrong and have very poor ways of tracing what it could be - hence the lack of green check mark and big red warning symbol.
If you see some new pre-alpha feature you'd like to try, just ask us about it first. Going forward, we want to start with a dialog about potential dangers, testing, and intentions of an incomplete feature rather than an autopsy later on. Don't be scared, we always love hearing from users before there is a problem, not after!
Build Version History
Also, all .blend files will be keeping a log of every different version of XPlane2Blender that they are opened and saved with. This is automatic and needs no involvement from the user. Those who are curious can look in the Plugin Development Tools section at the bottom of the scene settings and see the history of their file.
Note: This does not record any history data about Blender versions, other addon versions used, timestamps opened or saved, or changes made to it (including XPlane2Blender settings changes). It is purely useful as a debugging tool, and is not fool proof.
This .blend file started as a legacy 3.4.0 pre-beta.5 file, and was then with a copy of 3.4.0-beta.5, with no build number. Then it was used with 3.3.12, then finally, used with a build of 3.4.0-beta.5 created on 09/18/2017 at 01:27:30am.
One could use this information to guess what transformations the data could possibly have gone through along each step of its journey.