After some unfortunate delays, the 2.49 converter is released! The instructions for installation, configuration, and use are quite long, so I won’t copy them here as usually do. To download the files, scroll down to the bottom of the page to “Assets”.
The GitHub page has an updated copy of our the 2.49 scripts. Download and install them.
The converter will only get better from real world examples, so please send me your feedback and screenshots so I can fully understand the world of 2.49.
And don’t worry, it was designed to work without Blender 2.49 if needed.
Download here! I can’t wait to see life breathed into these old projects!
We have a lot of exciting news for XPlane2Blender users on three fronts: the Blender 2.49 Converter, Blender 2.8 support, and v3.5.1-beta.2!
Firstly I want to say a huge thank you to all the community for all your patience, advice, and support during this time of heavy development and slow releases. One of the biggest changes, I think, to XPlane2Blender in the last few months has actually been all of you! I’ve asked for advice and gotten constructive comments in droves, I’ve asked for projects and I’ve gotten example files to work with! I even asked for help with contributions to the project and gotten several pull requests to merge! Your passion for Blender and X-Plane inspires my passion for making the tools you want and need!
Now for the details!
The 2.49 Converter
The XPlane2Blender 2.49 converter has been in development for nearly a year, and the alpha is almost here. Some doubted if it was even possible to save these old projects, but the results speak for themselves. Observe these screenshots of Laminar Research’s KingAir C90B, F-4, and Boeing 737 that have been converted and exported with XPlane2Blender for 2.79!
KingAir C90B
KingAir C90B Cockpit Lit Up At NightKingAir C90B Exterior, Showing Flaps AnimatingKingAir C90B Interior Seating
McDonnell Douglas F-4
F-4 Cockpit Showing Panel Textures And Dials Rotated
Boeing 737
737 Main Gear, Beginning Retraction Animation
These are not proofs of concept, they actually work very well! Animations, manipulators, panel textures, meshes, lights, OBJ directives like shading, no shadow, DISABLE_DRAW, ATTR_light_level, and more, autodetecting textures, and preserving workflow features like picking the same OBJ file names and BULK export vs Regular export are all in the alpha. Basic scenery objects also convert, but some directives aren’t included yet.
We are not feature complete, and it will never be perfect: pre-conversion and post-conversion fixes will likely be necessary. However, spending only a day or two for the conversion is far better than redoing years of work!
Getting Your Old Projects Ready
The alpha is about two weeks away from release. In that time I HIGHLY recommend finding your old projects and doing the following
Make backups of your files, because there is no return if you accidentally save over a 2.49 file after opening it in 2.79
If you are able to do so and it can run in X-Plane 11.36, the converter has a very good chance of bringing it forward with few things to fix post conversion.
The big thing I’ve noticed is that DataRefs usually need to be fixed as future versions of X-Plane added more that made unambiguous Datarefs ambiguous.
I’ve noticed that some Blender 2.49 Datablocks have become “haunted” – where it crashes Blender 2.49 if clicked on or changed. I have no idea why or how. I can’t see a pattern or do anything about it, so take notes as these objects may need special attention post-conversion. If you have ideas, let me know!
Also be on the look out for game properties with bad values, like an “litlevel” that is missing a dataref, or a “GLOBAL_tint” that doesn’t have two numbers separated by a space. X-Plane may fill in defaults, but the converter doesn’t. Don’t worry, the converter will help find some of these – as long as the property names are spelled correctly!
If you are unable to run Blender 2.49, the converter may still work but you won’t get a chance to clean up the file and correct mistakes – it may require a lot more work post-conversion if you even get the chance. I highly recommend finding an old computer in the attic if needed.
Most importantly, make sure you have the DataRefs.txt that 2.49 was or is using during export. Otherwise it may be impossible to correctly convert animations.
The cleaner the input file, the cleaner the conversion, the better the 2.79 file. That is why I’m releasing this guide before releasing the alpha – so that some of this work can be done beforehand and day 1 questions will be about the converter and not 2.49 problems.
One last note: Releasing our internal version of XPlane2Blender for 2.49 does not indicate support for it. It is merely there to help prepare your project for use with the converter. Remember, we’re trying to run away from 2.49 as fast as possible.
Blender 2.8 Support
A person recently e-mailed me: “Will Blender 2.8 have support before the New Year?” My answer: Yes! Yes it will! Don’t lose hope!
During the alpha cycle for the converter I will be finishing the alpha for Blender 2.8 as fast as possible. We’re very close – the UI is working and I’m about half way through figuring out which API calls need to be replaced and how.
XPlane2Blender’s UI and Custom Data in Blender 2.80
Before September is over you will start seeing more commits on the 399-blender-28-support branch. To keep up the hope, check out this screenshot of the BD-5J Microjet in XPlane2Blender in 2.8!
v3.5.1.beta.2 + Pull Requests
When I put out a desperate plea for some help developing the project I was gladly surprised by Kim Brandwijk, who has made several high quality pull requests that are small enough in scope to be added to v3.5.1.beta.2. I regret that I did not have time to merge them in a timely matter, but now with both alphas releasing soon all users can look forward to some excellent optimizations and speed increases soon. Hopefully the pull requests and community development can pickup some energy again.
I hope you all are as excited about this as I am! It has been a long summer of lots of coding, but I think people will be very happy with all the new features! Stay tuned for more news!
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!
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!
The Solution
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.
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!
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 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.
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!
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.
(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:
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.
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!
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
Important bugs
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!