(This post was edited to reflect a discussion Ben and I had)
A constant request for XPlane2Blender and other exporters maintained by Laminar Research is an import OBJ feature. So, one last time, here is the news: by now an importer is basically never going to be a part of XPlane2Blender, but it could be its own project! It could take years of development to make it very well polished, however.
There are a few projects started on the forums you can checkout if you’d like!
Why Is This Such A Hard Problem?
It is simple to read the vertex table, attributes, animation keyframe table, and turn that into Blender data, some projects can already do this, in fact. The trouble is getting the exact or nearly the exact .blend file back.
OBJs Don’t Save Everything You Want And Need As An Artist
Some of the things things you could never import from an OBJ
- Window Settings
- Text Blocks with scripts, notes, or annotations
- Any non-XPlane2Blender Blender settings we don’t care about
- Object, layer, material, and texture names
- A bunch of settings that can’t easily be inferred (more on that later)
- Blender’s parent child relationships
If the OBJ was produced with comments and correct indentation, you might be able to get some of these things back (likely just a few names.) A large complex Blend file without this stuff is a nightmare of an unorganized mess and would make the rest of the manual reverse engineering process even harder.
Multiple .blend files Can Produce The Same OBJ Content
If A.blend, B.blend, and C.blend can produce the same OBJ, which one should the OBJ be reversed engineered back into? The relationship between XPlane2Blender settings and what appears in the OBJ can be very esoteric and there is not always a 1:1 relationship. Some ATTR_s only appear when certain combinations of settings are used. You may find there are absolutely no good defaults.
A Moderately Smart Importer Would Need To Know Massive Amounts of History Of All Exporters
In order to perfectly solve these ambiguities and produce .blend files that are similar to what originally exporter the OBJ file, it would be incredibly useful to know about the behavior of the exporter that exported the OBJ in question. This means an importer would need to know all the bugs and features of every exporter, and we don’t even know that after developing the exporter. Bugs are waiting to be discovered, or used by artists until they have to be turned into a feature. Our exporter currently struggles to take into account past bugs, and that’s the exporter!
This turns into it’s own ambiguities to solve: “Is this OBJ’s mention of deprecated ATTR_s a choice the artist made. despite the deprecation warning, or was it a bug that this was still getting written, or was this OBJ written before it was deprecated?” Now you’re messing not only with valid or not, but what the OBJ is supposed to look like.
Optimizations Create Further Challenges
Exporters often take optimizations to improve an OBJ’s performance and quality. For instance:
- Removing duplicated vertices, keyframes, attributes
- Rounding or changing data on the fly
- Ignoring or appending ATTRs to handle deprecations or obsolete OBJ features
Now you will have even less information or, now, seemingly incorrect information! OBJs are meant for X-Plane, not humans. As such exporters can take many liberties with the content of OBJs as long as they match what the artist meant. This can result in very complex optimizations that might even break our own guidelines, all to deliver the best (and deliver on time) to the consumer and our artists. This makes developing an importer that reproduces the importer OBJ, either exactly or simply visually matching (let alone animated or textured properly) even harder.
In a raw .blend file, objects are like Lego bricks which get baked into one solid piece. Going in reverse will likely not get the same neat separation. Blender is not smart enough to tell what is a wing shape, what is a wheel shape, what is a throttle level shape. It may be impossible to separate the vertices back into these distinct meshes (especially after optimizations)! Making a “really smart” importer that is shape aware is a brutally hard algorithm that the world’s best computer scientists are still attempting to solve. It may not be challenge you want to take on.
We May Build A Reasonable Importer One Day!
With all these challenges, an importer would have to be willing to not handle all edge cases and not attempt to reverse engineer an OBJ back to the exact .blend file that made it. For instance, a 3 year old OBJ would not be reversed engineered into the .blend file that produced it 3 years ago, especially since an artist would want to then update their assets anyway! Having art assets “marooned” on other exporters or “dead” is a pretty terrible waste of time, likely be more painful than hand fixing all lot of little things. As Ben pointed out “If we can’t make a direct import [.skp->.blend, .ac->.blend] path, OBJ import is the least bad option.
2.49 to 2.7x Converter
A 2.49 converter is a much more manageable project (far on the back-burner.) The complexity of this tool is much more manageable, because the 2.49 is not in active development and you are converting .blend to .blend, not .obj to .blend. Blender to Blender is something which Blender is already very good at.
- Bone animation bugs, where multiple nested bones or meshes attached to Armature datablocks would not export animations correctly
- #317 Custom lights will now never autocorrect due to old hidden data being considered
- #313 Custom light properties work again
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.
Build Version Numbers
XPlane2Blender’s new version number system 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:
A break down of the components
3.4.0: The traditional Blend addon number
beta: The type of build cycle we’re in. Other choices you may see are
dev (a developer build),
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 changes
20170922151901: The “build number” date this source code was packaged and released in the form of YYYYMMDDHHMMSS in UTC.
The build version number is partially shown (elements after the + are hidden) in the scene settings under
Composite Normal-Textures, potentially along with warnings about the stability of the build you are using.
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 following:
- 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.
- #294 – A case where autodetect off was not fully trusting the author for Aircraft exports
- An uncaught spelling mistake
__updateLocRot. The fix for the updater altering the animation types was written for object’s dataref animations and bone’s dataref animation troubles. However, with this spelling mistake and Blender’s uncanny ability to eat exceptions from addons, it wasn’t realized until later that bone’s weren’t also getting updated. Fortunately, the updater can be run-again without fear of messing something else up.
At the bottom of the Scene Settings, check “Plugin Development Tools”. Use the Re-run Updater tool at the bottom: Put in
3.3.9 in Fake Version, and click the button. You should see your bone values corrected, as long as you successfully reverted any bad changes from v3.4.0-beta.1. Please e-mail me if you have problems!
- Some spelling and capitalization in the UI. Great care has been taken to ensure that none of the actual value or order of the addon properties has changed!
If you have been doing work with manipulators during beta.1, please download this new one and review the notes! Download the latest here: io_xplane2blender_3_4_0_b3.zip
- #ATTR_layer_group_draped causing KeyErrors
- Reverts bad change to manipulators properties*
“.beta.3” will be printed on all OBJs. This is not permanent, expect something better in the future
What happened to the manipulators?
A poor decision to change the Manipulator Type (Drag XY, Push, Command Knob, Toggle, Delta, etc) means that if you changed the type of manipulator between
7fe534ad1f906b7853827 if you constantly check out the latest cutting edge commits [which I do not recommend for this exact reason]), this beta will make those changes irrelevant.
Example, suppose on 8/1/2017 you create a switch and set the manipulator type to
Toggle, then with beta.1 you change the type to
Push. Beta.3 will show the type as
Toggle. All you need to do is go back to the switch and change the type back to
Push. The rest of the values you set will still be there. If you created manipulators during the beta, they will be set back to the default “Drag XY” type and will need to be fixed.
This is an unfortunate lesson to be learned, and if you are facing a lot of tediousness (30 manipulators to hunt down and change) or potential errors (you can’t remember how many or which ones you changed) please contact me!
I will personally help you recover the changes you made during beta.1 – present.
So far so good (aside from one big breaking problem)!
#289 periodic filename_ext error notifications.
#288, 292 loc/rot/show/hide upgraded improperly
Add X-Plane Layers button for new projects now longer hidden
- Re-run updater button – USE WITH CAUTION! – to force re-running the updater as if the file was previously saved with a different version of XPlane2Blender
See the next release here, download the .zip here. As always on-topic feedback is appreciated!
XPlane2Blender v3.4.0-beta1 is out!
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.