Time for an upgrade. Ben Supnik discloses the future of X-Plane Panel Rendering and UI SDKs, including some long-awaited requests!

For the last few months, I have been working on our road map for user interface and avionics. This effort is now far enough along that I can share what it looks like.

We have two goals with this roadmap:

1. Improve performance by allowing plugins to create user interface and avionics without OpenGL. OpenGL drawing requires expensive bridging and is impossible to make multi-core, so I see it as a roadblock to faster FPS. We want something that can be faster.
2. Make it easier to create user-interface and avionics. OpenGL is high-level for a graphics API but low-level as an avionics API; plugin developers often have to add libraries on top of it, like ImGui , or use slower alternatives like Cairo.

The roadmap addresses both of these, based on three bits of tech:

1. XPLM Panel Graphics
2. Native ImGui Integration Support
3. Browser-Based Windows

The rest of this post describes these three things and how they fit together.

Panel Graphics: an X-Plane Native Drawing API

Panel graphics is a new set of APIs in the plugin SDK that supports high-level drawing into an avionic or XPLM window. The AP supports:

• Vector graphics (outlined and filled shapes) with anti-aliasing, line width, and stipple, e.g. the things you need to draw avionics.
• True-type font rendering (rendered as MSDFs, so they look good at multiple scales and rotations).
• Texture atlasing – you give us some PNG files and we batch them together and draw textured meshes for you. This is the technology underneath Plane-Maker’s generic instruments.
• Scissors, stencil clipping and 2-D transforms to make complex avionics.
• Hot zones, e.g. the ability to recover touch-screen clicks and act on them.
• The ability to save bits of panel graphics and re-run them for efficiency.

Panel graphics meet our goals because:

1. It is implemented directly by X-Plane using Vulkan, so we have a fast, potentially thread-safe path to the hardware.
2. A bunch of problems are taken care of for you. We will load and render the true-type font into our shaders; you just name your file. We will load your PNG files, atlas them together, DMA them to VRAM, etc.

While panel graphics is not a general-purpose 3D drawing API, it should be better suited to avionics than OpenGL was.

Panel graphics will be an opt-in option for both windows and avionics.

Aside: Why Roll Your Own?

It’s a question you have to ask: why would we create a graphics API when there are already so many out there?

The short answer is: we looked at the other options, and none of them met our needs. We looked at Cairo, Skia, GLES, NanoVG, ImGui and we considered exposing Vulkan directly (but came to our senses in about 15 µsec). We have looked at a lot of stuff.

The biggest problem was integration: to meet our performance needs, we needed a graphics API where we could really get fine-grained control over how it interacted with the rest of our rendering engine. This, for example, was why we rejected Skia – we looked at how it rendered and concluded it would likely have similar integration pain as Zink. (They’re both great technologies – but they’re not meant to be “thin middleware for games” the way ImGui is).

Other APIs had the opposite problem: integration would be great, but they wouldn’t be useful to our users. For example, ImGui contains a “graphics API” in there somewhere, but it’s not the library you want if you want to make avionics. The libraries small enough to integrate well often didn’t have the functionality, and the really big APIs that could do everything were hard to integrate.

Having made it a significant way through implementation, I have no regrets; it’s not trivial to make a full-featured API, but we have most of the tools we need inside X-Plane, and straight implementation is much less hairy work than, for example, debugging Zink.

Native ImGui Support

Dear ImGui GitHub: https://github.com/ocornut/imgui

ImGui has become a de facto way to do UI in X-Plane plugins, for obvious reasons: it’s fully featured, easy to use, and is about 1000x better than the old “widgets” API I created (and then abandoned) in 2004.

To support ImGui natively, the panel graphics API (which can be used in a window as well as avionics) has an API designed to consume and draw ImGui draw lists directly. To upgrade an ImGui plugin to draw natively, a plugin developer would need to:

1. Set the drawing type for their XPLMWindow from OpenGL to Panel Graphics.
2. Replace the OpenGL draw callback that calls glVertexPointer, etc., with two XPLM panel graphics calls to draw.

My expectation is that the change will make the plugin smaller, and we can post sample code showing how to do this.

Aside: Why Not Just Put ImGui Into the SDK

We looked at compiling ImGui directly into the X-Plane SDK – heck, we had it working internally for a while.

The main drawback for this approach is that ImGui really, really, really wants to be a C++ API, and shipping C bindings for it would mean plugins couldn’t use any custom widgets in their ImGui code (because the custom widgets are almost always meant to be compiled against the C++ API).

By leaving ImGui inside plugins and making the actual drawing native, we are leaving more complexity in plugins, but we’re making adoption, versioning and upgrading easier while hitting the thing we care about: performance.

Browser-Based Windows

The third way to make window content will be to use a browser: plugins can specify the contents are a browser than set a URL for the window. We use CEF (which we ship with) to render. Browser-based windows will have some limited communications ability to send JavaScript messages to the browser and receive plugin callbacks from it for integration.

This is one area where I am not sure of the full extent of what we will offer because while we have this working, we have not worked through all of the security implications. One thing I can say is: a plugin window browser is not an appropriate secure context; every key stroke the user can enter will have gone through X-Plane’s event loop, so maybe don’t use a browser-based plugin window to access your crypto wallet.

Aside: What About Your Own UI Framework?

We have our own custom, fully built native-drawing-based UI framework inside X-Plane. (It’s name, “GUI”, is not my most original work.) GUI was born to support the Plane-Maker panel editor, then grew to support the current X-Plane mobile UI, and then grew again to support the X-Plane 11 user interface rewrite.

For a while, we were considering providing a wrapper around our UI, which would provide a look matched to X-Plane’s native UI and native drawing. But there are a few things that would make this not that great:

• The interface isn’t that mature; we add features as we need them (which would be API-disruptive).
• The interface is wide so it would be a lot to wrap (locking us into compatibility issues).
• There isn’t a widely developed ecosystem to support UI using our tools, the way there is for ImGui and browsers.

In fact, my own coworkers complain regularly about developing using our own internal UI (“why the hell is GUI doing this? This sucks, ima rewrite everything using HTML”), which doesn’t bode well as a developer-friendly framework.

We could still potentially add our own native framework as yet another option, but at this point, we are not pursuing it at all; my guess is that ImGui , panel graphics, and browser-based windows will be a good foundation for the future.

Timeframes and Adoption

I do not know what the time frame is for shipping the panel graphics API. What I do expect is that we will have some kind of not-yet-released developer preview for our developer lobby by this summer at the latest. So there are a few situations where, if you are an add-on dev, you might care:

1. If you are starting or designing a new project that uses avionics or has UI, you should consider whether you should be using panel graphics for the avionics, panel graphics, ImGui, or a browser for the UI.
2. If you have an ImGui -based plugin, you should plan to swap over to panel graphics for drawing when possible.
3. If you support an existing product (particularly middle-ware), you should consider whether any of your APIs can be moved over to panel graphics for better performance.

ImGUI is currently scheduled for 12.5.0 (However may be subject to change.)

The post X-Plane SDK Roadmap | User Interface and Avionics appeared first on X-Plane Developer.

XPlane2Blender v4.1.0-beta.1

This is a beta so make backups of your work before using!

New features!

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:

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.

Cockpit Device

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.

Minor features

(#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.

Important fixes

• 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!

The post XPlane2Blender v4.1.0-beta.1 appeared first on X-Plane Developer.

XPlane2Blender v4.1.0-alpha.1

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.

Cockpit Regions

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!

The post XPlane2Blender v4.1.0-alpha.1 appeared first on X-Plane Developer.

Download this from GitHub!

We did it folks! Long in development (mostly because I kept adding features, not because of many disastrous releases) we can call this complete! A huge thanks to our dedicated volunteers who beta tested, send bugs, e-mails, and trusted their projects and livelihoods to us. We hope to live up to that trust everyday. Again thank you. Also thanks to a few people who contributed code (Premek Truska and @kbrandwijk)!

This release notes page serves as an overview of important new features and changes since Blender 2.79. Since the manual has not kept pace with development, you’ll find documentation on the new features in past release notes. This is being worked on.

Don’t be surprised if you see the words “Exportable Collection/Object”. That name was later changed to “Root Collection/Object”. Read more about that change here.

New Features

Blender 2.80-83 upgrade!

• Blender 2.80-83 is supported! XPlane2Blender in Blender 2.90 has been tested by some with positive results but is not officially supported yet.
• The UI is almost entirely the same. The replacement for the Layers Mode feature, “Root Collections”, is almost identical in nature (but also much more powerful!). A few unclear property names and poor tooltips have been reworked, but are still in the same place. Unlike Blender 2.80’s large UI change, we have changed much at all.
• I have yet to meet an artist who, after learning modern Blender’s UI, wishes they could go back. Have no fear in upgrading!

Root Collections and Root Objects

• Blender 2.79’s 3D View’s layer system has been removed and replaced with Blender 2.80’s Collections. To adapt, we removed “Layers Mode” and replaced it with “Root Collections”. It is nearly the same as Layers but is much more flexible. The updater preserves Layers Mode projects and the UI for this workflow is still in the Scene Properties Tab. For old tutorials you can, in general, replace the word “layer” with “a collection”. Read more about the feature here. “Exportable Collection” and “Root Collection” refer to the same concept, don’t get confused by the old name.
• You can use Root Collections and Root Objects in the same scene, no need to pick only one workflow

Automatic lights

• Automatic Lights makes lighting in XPlane2Blender easy! Automatic lights are aimed for you without the need for tricks, any parameters are filled in automatically or with easy to use Blender properties, and the exporter and UI prevents many types of lighting mistakes. Pick your X-Plane light name and What You See Is What You’ll Get! Read more here.
• Knowing what lights to use and how is now easier. The “Create lights.txt Summary” button makes a text block with light names available and what parameters an Automatic Light will be setting in an easy to use format. See the “Feature Controls” table in beta.2’s release notes for the translation between parameter name and Blender control.
• Don’t worry, Named and Param light types haven’t been changed at all.
• Though it shouldn’t be necessary to read lights.txt anymore, it has been cleaned up quite a bit!

Split Animations

• “Split Animations” offers a new way of sharing animations between objects and even .obj files. An excerpt from the manual explains some uses: Split Animations allows you to share animations that are outside the current root collection. *Its purpose is to reduce the manual labor of keeping these shared animations in sync. Some examples uses of this feature include
  • Synchronizing the motion of a landing gear and wheel in separate OBJs
  • Synchronizing the movement of complex wings flex and their lights
  • Synchronizing the movement of the cockpit OBJ’s door handle manipulator and a door OBJ’s door mesh
  • Having groups of manipulators follow the animation of a parent element of the cockpit
  • Many useful cases I’m sure no one else has dreamed of yet!

The feature is activated by very specific uses of Collections and parenting instead of checkboxes and buttons, so read the tutorial on how to take advantage of this powerful new feature.

Override LODs

• The Levels of Detail feature in XPlane2Blender has been expanded to reduce the amount of clicking required and also to accommodate the removal of Blender 2.79’s 3D View layer system. How Root Objects projects use LODs had to be changed. See details and backwards compatibility instructions in alpha.5’s notes.

Optimizations

• Thanks to Premek Truska and @kbrandwijk the Vertex Deduplication algorithm (aka using the Optimize checkbox) is set) takes almost no time at all, even for large .objs
• A one time keyframe gathering pass makes Objects with many keyframes export twice as fast as before
• Highly optimized string formatting increase the performance of the exporter across its whole write and logging operation
  All optimizations work automatically, no work is needed to enjoy the benefits! A full export of the BD-5J on my computer now takes 14 seconds over 2.79’s 30. Other people report similar or better results.

Removed

• Layers Mode removed due to Blender’s choice (but Collections are far better anyways so this isn’t a big loss).
• Blender removed Texture Slots so we removed autodetection and certain texture validations. For now the root’s texture file path string properties must be used.
• 2.79 support. Additionally v3.5.1-beta.2 is cancelled (not that anyone ever asked for it of course). Future versions of the converter will consider Blender 2.79 a pit stop before Blender 2.80.
• Include In Export, Export Mesh In Layers for being redundant and broken

Fixes for bugs that existed in 2.79

• #570 Drag Rotate Bug Fix

Again, thank you so much to everyone who uses this addon and sends screenshots and bug reports and e-mails and forum posts and stories of all the great things you’re making. X-Plane wouldn’t be X-Plane without talented people like you making the world real with Blender and XPlane2Blender!

The post XPlane2Blender v4.0.0-rc.1 appeared first on X-Plane Developer.

As always make backups

So close to release!

Unless something’s gone wrong, this is rc1!

A big speed boost for aircraft!

• By fixing #571 and #569 aircraft with complex animations should receive seconds off their export time! It basically marks the end of the “can squeeze more out of Python” quest which is good (and a bit sad).

Drag Rotate Bug Fix

• Fix for #578. For those struggle with trying to make things like trim wheels that rotate multiple times around (going from -1440 to 1440), this beta fixes it. Please let me know if this fix broke other manipulators.

A tiny UI fix

#570 is fixed for anyone who was bothered by this. Yes, even the small bugs matter to me I swear!

Once confirmed that these have gotten the fix, we’re at rc.1!

The post XPlane2Blender v4.0.0-beta.3 appeared first on X-Plane Developer.

As always, remember that this is a beta, so make back ups!

We’re Going Back To Saying ‘Root Objects’

• #544 – it appears the “Exportable Collection/Object” naming scheme was confusing. We’re going back to 2.79 phrasing “Root Collection/Object” in the UI, error messages, bug reports, feature requests, e-mails, everything. If I make a mistake please correct me quickly!

Automatic Lights

Our bright and shiny new fun feature is here! Automatic Lights (also called WYSIWYG lights) replaces Named and Param lights. It fills out parameters and aims directional lights for you in the most efficient way possible! No more doing math by hand, no more reading the lights.txt file, no more being scared to experiment! The UI guides you and prevents mistakes! Automatic lights are the new XPlane2Blender default light. Download this example to see many different uses of this feature!

Feature Controls

We’ve tried to make this as intuitive as possible, but just in case you’re not sure what fills in what parameter, see this table:

Any other parameter found in lights.txt can’t be changed in Blender.

Limitations

• Some very very old lights are not compatible.
• This is currently an opt-in feature only. An updater for old named and param lights would be difficult and limited and likely won’t happen.
• A dataref search window style feature feature is planned, but currently to get a list of lights and their parameters you’ll need to click
  “Create lights.txt Summary” and look at the internal text block “lights.txt Summary
• The lights.txt included is the same content as X-Plane’s lights.txt, with slightly different formatting. Your .obj will be completely correct in X-Plane, but X-Plane’s old and currently shipping lights.txt is not compatible with XPlane2Blender. This will hopefully be corrected soon.

Please send me pictures and stories of what you’re trying now that the light system is more easy! I can’t wait to see more sparkling lights across the skies and airports of X-Plane!

The post XPlane2Blender v4.0.0-beta.2 appeared first on X-Plane Developer.

Download it from GitHub!

As always, make backups!
Well folks, we are finally feature complete, very stable, and as bug free as we can be at the moment! This update was for some small bugs and to wait and see if there would be feedback on alpha.6.

Features

• When attempting to export a project with no exportable collections or objects you’ll get an error asking if you forgot to check any Exportable Collection|Object checkboxs, Hopefully this helps beginners find those checkboxes and get started.
  

Bugs Fixed

• #504 Where, when the collection algorithm starts in the middle of the tree, walks up, and re-enters the exportable collection it started in, it now respects the visibility and ensures the XPlaneBone is re-used. For an example of this weird case see parent_out_of_collection_snake_out.test.blend
• #514, #536, #538 which all related to making the Hidden or Visible feature work as intended – not including what shouldn’t be included. Hidden Lights with the Default, Strobe, Traffic, or Flashing lights no longer include the VLIGHT table entry. ATTR_manip_ is not included across split animation OBJ boundaries, Objects hidden by other means than their or their parent’s visiblility are still counted as hidden (“True WYSIWYG”)

Sorry for keeping XPlane2Blender in Alpha for so long. I develop everything with the knowledge that the artist community will jump on the latest and greatest as soon as it is out there and strive for the greatest possible quality at all times. In the future I think we’ll not use the label as much. It caused a lot of concern about whether or not it should be used, even when it was quite ready.

XPlane2Blender is developed using Blender 2.80 because some Linux Distros are slow to update Blender, and some people are slow to update Blender versions. If you are using Blender 2.82 it should work, but, tell me how it goes. I haven’t heard anything bad yet.

As always, please report any bugs you find and thank you for using XPlane2Blender!

The post XPlane2Blender v4.0.0-beta.1 appeared first on X-Plane Developer.

XPlane2Blender v4.0.0-alpha.5, aka LODs

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.

[Picture]

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.

Override LODs

1. In the Object Properties Tab of the Properties Editor, you’ll see a new “Override LODs” checkbox.
2. When checked, the familiar 4 LOD bucket choice checkboxes will appear.
3. 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.

Backwards Compatibility

There are only a few differences from 2.79 to be aware of

LOD Validations

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!

The post XPlane2Blender v4.0.0-alpha.5, aka LODs appeared first on X-Plane Developer.

XPlane2Blender v4.0.0-alpha.4

As always, make backups!

Over the past month people have reported to me all sorts of weird things:

• OBJ geometry moving with every export
• Blender Objects moving after every export
• Animations spiraling out of control
• Even simple renaming Blender Objects and restructuring of the Blender hierarchy might trigger a bad export.

And the only cure was to apply all transformations or restart Blender!

Thanks to your bug reports and e-mails I was able to track down the source: all these problems were facets of the same bug!

To make a long story short: I have a fix for XPlane2Blender, but other Blender exporters and users may not be so lucky. I’ve filed a bug with Blender itself, but that is nothing to worry about for X-Plane artists.

Please continue to send me your bug reports! I do read every one of them, even if I don’t get back to you right away.

The post XPlane2Blender v4.0.0-alpha.4 appeared first on X-Plane Developer.

XPlane2Blender for 2.80 has crossed a new milestone! Exportable Collections are in! They work just like root objects (which we are now calling Exportable Objects), the settings for them are just where Layers Mode settings used to be, and Layers Mode projects keep their OBJ settings automatically. More details down below.

As always, make backups! This is still an alpha and how collections work could change!

New Name For Root Objects

As mentioned, Root Objects – the concept – has been renamed to “Exportable Objects”. Everything is the same, it is only the name that is changing in the UI and the docs. This was done to let people know there really isn’t much difference between using the new Collections and the old Root Object system. Half the name is the same! Otherwise it sounds like “Root Objects vs Exportable Collections” are as different as how it used to be with “Root Objects Mode” vs “Layers Mode”. From here on I will use the new names – Exportable Collections and Exportable Objects.

New Features

Exportable Collections

We’re very excited about this: Collections are in! Many thanks to the people who talked about it on #450. I think the feature will be able to do all or most of what you wanted. Here’s how to use them.

1. When you open a 2.79 file in 2.80, the contents of Layer 1 will be put into a collection called “Layer 1_{the scene’s name}”, the contents of Layer 2 will be put into a collection called “Layer 2_{the scene’s name}” and etc.
2. Blender has new and exciting ways of using Collections and the 3D View. If Show is on but you can’t see the contents of a collection, try right clicking on it in the outliner, go to Visibility and ensure Render and Viewport are enabled.
   

I highly recommend reading
– New Outliner Controls
– Collections Overview. Complex instancing is planned but not supported: #495 and #452.
– View Layers

1. You’ll find the exact same OBJ settings in the exact same layout where Layers Mode used to put them.
2. The updater will have copied the previous settings if the layer had some object in it or the OBJ settings was changed in some way.
3. Collections can be marked as “Exportable” or not. Non-Exportable Collections can be used as a way to organize your project, similar to using Empties. Unlike empties
   • An important terminology note: Datablock Objects (Meshes, Lights, Armatures, Empties) can have 1 Object parent and many Object children. Collections can have 1 Collection parent and many Collection children. This means a datablock objects can have 1 parent and be in multiple collections. When an object is linked to a collection, it is in that collection and all that collection’s chain of parents.
   • Collections do not have a location or rotation.
   • A mesh, armature, or other objects can have a blender parent and be in multiple collections. A great opportunity for re-use that XPlane2Blender supports. Also key for another new feature called “Split Animations”.
   • Every object inside the exportable collection and its chain of child collections is collected and exported together as one OBJ. Any children of those objects found outside the exportable collection are ignored, just like how Layers Mode used to work.
   • Each object is included once. Attempting to make duplicates by putting an object in multiple sub-collections of the exportable collection won’t work. In this example Cube only appears once in the OBJ.
     
4. What is exported only depends on what objects are in what collection and the value of that collection’s Exportable Collection checkbox. Viewport visibility doesn’t matter.
5. Everything inside the exportable collection and any of its child collections will be exported. If any object has a child that is outside of the exportable collection, that child and all its children will be silently ignored.
6. There is no more “Layers Mode vs Root Object” divide, and projects can use Exportable Collections and Exportable Objects at the same time (just not nested).

Here is a picture showing a side by side comparison of the relevant UI in 2.79 and 2.80, using the BD-5J Microjet. After opening the file I hit export and it just worked!

In this picture I’ve unchecked Exportable Collection on Layer 2_Scene. Now it won’t export.

Split Animations

Split Animations is one of our most exciting new features – something never before possible in XPlane2Blender! See the guide in the manual, click here to find more.

Other Bug Fixes

• #493 Unit test system slowly healing and getting back to usable.

Caveats

Things Move On Every Export

There appears to be a Blender bug in 2.80 where sometimes after every export (of any exporter) the objects drift apart. It is unknown why this happens but there are two ways to fix it.

1. Restart Blender and try again and hope it works
2. Select all objects and bones and use Apply > Transformations > Scale. And if that doesn’t work, Apply > Transformations > All Transformations. These are drastic, but, if it works, please e-mail and help confirm this bug that we can report to Blender.

Updater Changes

The updater has had some changes and not all of them tested 100 times over like I normally like. I don’t think it will be a problem however. Please e-mail me if you have trouble. If you have a multi-scene project, double check your updated OBJ settings and tell me if you see an automatically made collections with names like “Collection.001”. They should have been renamed.

For those of you patiently waiting for an e-mail back from me about a problem you’ve had with your .blend file, thank you for your patience. I’m going to try to respond to all of them this week!

The post XPlane2Blender v4.0.0-alpha.3, aka Exportable Collections! appeared first on X-Plane Developer.