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!
LR customers can now get the first public beta of X-Plane 11.40 by running the installer, checking the box to get betas, and completing the update. Steam will most likely be available tomorrow, barring any unforeseen crises with this build.
Release notes here.
This youtube video has a thorough explanation of the new flight modeling stuff.
PLUS new stuff for “official” beta 1: Read More
Download it here!
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!
Read More
The Problem
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.
Please ask any questions!
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!
A quick note on 11.30: we have an internal build of 11.30 that seems to be working and we’ll be rolling out private betas next week, as soon as we get menu items for the particle system editor. Once we get some feedback on the private beta we’ll know if we’re close to public beta or not.
Two new feature for aircraft authors coming in 11.30:
4K Panels. I do not promise that this is going to have good performance, so try it and go back to 2K if things get slow, but in X-Plane 11.30 you can use a 4K texture for your panel. This is mostly useful for aircraft that are generating a lot of plugin-based dynamic texture effects.
Cockpit Objects. Before X-Plane 11.30 the cockpit object is a magical object found by file name (aircraft name_cockpit.obj). In X-Plane 11.30 the cockpit object is just one among many “misc” objects in Plane-Maker, with the “cockpit object” check-box set.
X-Plane and Plane-Maker will automatically upgrade/interpret old planes, so there’s no “todo” here or compatibility loss.
This feature means that, starting with 11.30, you can now share a single cockpit object amongst multiple .acf files in the same folder. This means you can create multiple editions of your aircraft (e.g. for engine types) and not have to duplicate your cockpit .obj files.
Update: just to clarify something that a number of authors asked about, you cannot have multiple cockpit objects under the new system. You are still required to put all of your manipulators and camera-stopping surfaces in a single cockpit object. Now you have complete control over which object that is. (Panel texture may be used in any aircraft-attached object; this is true for all of X-Plane 11 and some X-Plane 10 versions.)
As you saw at Flightsim Expo, X-Plane 11.30 offers a wide range of new features for airplane authors, who wish to make their airplane engines and systems more realistic. This post links to the documents with technical details that are of interest to aircraft authors mostly. End-users are encouraged to try the Cessna 172, King Air C90 and Boeing 737 of X-Plane 11.30 to experience more fidelity in true-to-life autopilot and other system simulation.
Oxygen System
X-Plane has two separate oxygen systems, bottled/compressed O2 and chemical oxygen that can be used for both general aviation aircraft and airliners with separate crew and pax oxygen. How to set up the system for you airplane is explained here: https:/article/the-x-plane-oxygen-system/
Anti-Ice and De-Ice Systems
Airplanes can make use of electrical or bleed-air thermal anti-ice systems, inflatable boots de-ice or chemical TKS anti-ice systems, each with their own characteristics: https:/article/the-x-plane-anti-and-de-ice-systems/
Vacuum and gyro systems
Besides engine-driven vacuum pumps, X-Plane can now also simulate venturi-powered vacuum systems as found on vintage aircraft and electrical backup pumps that are sometimes found in slightly better equipped general aviation aircraft. The interaction of all the pumps, manifolds and instruments is explained here: https:/article/vacuum-systems/
The traditional vacuum-driven attitude indicator is now subject to the same limitations as in real life, and can be equipped with a caging or fast erect mechanism to help cope with them: https:/article/vacuum-gyro-limitations-and-caging/
Propeller Governors
Propeller-driven aircraft can have distinct behavior of the prop governors reaction to engine failure or loss of oil pressure. Depending whether your plane is a single or multi-engine, whether it is driven by piston engines or propeller turbines, and wether the turbines are of the free-rotating or single-spool design, the equipment might be drastically different. X-Plane now features negative torque sensing in addition or instead of auto-feather, overspeed governors and fuel topping governors, to make turboprop aircraft even more true-to-life: https:/article/propeller-feathering-systems/
Turboprop engines now have additional overspeed and fuel-topping governors for free turboprops, and fuel delivery control for fixed shaft turboprops. How to set up fuel delivery control is explained here: https:/article/setting-up-a-fixed-turboprop-engine-governor/
Autopilots
X-Plane now comes with a few pre-configured autopilots for airplane designers to chose from, and offers more flexibility in creating a custom one.
General Aviation Autopilots
X-Plane 11.30 adds support for single- and dual-axis rate-based autopilots, control over the trim servo, and a separate static system for an altitude pre-selector.
Airliner Autopilots
Airliner autopilots learn new auto-throttle modes, Control Wheel Steering, have two independent flight directors and up to three channels for auto land. They can optionally even have a directional servo for CAT 3 landing rollout guidance.
Learn more about the X-Plane autopilots here: https:/article/preconfigured-autopilots-and-other-autopilot-changes-in-11-30/
The documentation for tuning the autopilot constants has been clarified and expanded with new sections about the new autopilot functions in 11.30: https:/article/x-plane-autopilot-params/
Finally, have a look at the X-Plane airliner autopilot in action, performing an auto land in a gusting cross wind:
https://youtu.be/EAOKNaSPuo8
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!
It turns out that my teachers in college, a ton of engineering textbooks, and the internet in general all seem to understand what wings do. Also my airplane has wings, and those wings are designed to interact with the air as much as possible, so I can flight-test my airplane at any time (and I constantly do) to collect information about what the wings in said airplane do. And then I use the information from the several sources listed above to really dial in the flight dynamics in X-Plane. Without question, on my death-bed I will look back on my many flights flown while frantically scribbling down notes and flying the airplane at the same time fondly. This is a challenge that not enough people get to enjoy, and then turning that knowledge into a simulator that then turns into money for me… well, let’s just say I have very little to complain about. Read More
(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.
