280: Implement Collections instead of Layers

[tngreene]

During 2.8 loading a 2.79 file, each Layer with something in it gets all its contents automatically put into Collection N. Layer 1,2, 20 becomes Collection 1, 2, and 20 with those items in it.

1. We can simply map Layers 1-20 to Collections 1- 20 as possible, but, xplane.layers that don't match will get dropped
2. We can also give Layer Props a new "Linked Collection" field, auto fill with name on first open. It allows us to rename a collection but must be manually tracked
3. We can put the data on the collection bpy_structs (?) themselves and draw it in the scene settings, using only top level collections as OBJs. Downside: If a collection is deleted, it would delete the props. Similar to deleting the Empty Root Object. Doesn't seem like a big deal though

I like 1 during the upgrade, then 3 for daily experience. This would be a very easy migration path.

Current Plan for Collections

1. **Collections will have a Root Collection marking that it is the root of an OBJ, similar to an object's Root Object checkbox property. This way we aren't re-using any Blender UI.
2. A collection with nothing in it still exports an empty OBJ.
3. A fake Properties Tab for Collections will be visible in Properties Editor > Scene > X-Plane. It will be split in two sections, one for Exportable Collections, one for Collections.
4. To make this easier to sort through, a hierarchy of the layout.box matching the collection parent children chain may be used, or a search window or drop down may be used.
5. During update Layers Mode projects have their layers settings mapped 1:1 to the new Collections. If there is a Layers Setting with unique data, but no collection (because the user had nothing on the layer at the time), an empty collection will be made for it with those settings copied, waiting for the user to put something back in it or delete the collection. It will not be marked as an Exportable Collection, however. Collection will be named "Collection N" as with the auto generated names.
6. The top level "Scene Collection" does not count as a Collection that can have OBJ Settings, you need to make at least one Collection first
7. As with Root Objects, the name of the collection is the default name of the OBJ if the OBJ Settings' name isn't filled in with something different

For now Root Objects won't get transferred, LODs won't get touched (sorry Scenery authors, it's coming). Other questions:

• Can an OBJ be inside an OBJ? ~(In #275 and #420 it seemed to be decided that that was a bad idea, though now I'm not sure why. It seems overly conservative to me.)~ No. #420 now has a decision.
• I think I like the idea of calling it "Exportable Collection" vs "Collection" (the folder use) maybe that's how I'll talk about it now.
• Keeping Root Objects instead of using the updater to get rid of it has a benefit: The start of an OBJ also has initial Location, Rotation, (and if you use a mesh) Material, keyframes, etc. The concept of "The root has the default origin, property data, etc" is very powerful and we may want to use it one day. I vote not to get rid of Empties and Meshes as Root Objects yet.

People's proposals for workflows such as @airfightergr's screenshot will work with this, and it will be very familiar.

Progress (in not much of an order)

• [x] Basic UI showing collections with layer properties
• [x] Still recurses exports Exportable Objects, Armatures
• [x] Something is actually exporting
• [x] Correct animations still export
• [x] Collection or collection stand-ins aren't in the XPlaneBone tree
• [x] Enabling/Disabling is_exportable_collection enables and disables export
• [x] Rewrite of collection algorithm to allow for collection
• [x] Cleaning up of old dead code
• [x] Sorting bones by weight still works
• [x] Unit tests for all this stuff!

UI Spec

• [x] Scene has fake Collections Panel Tab
• [x] Every Collection besides the Master Collection is listed
• [x] Every Collection has an "Exportable Collection" checkbox

[lehthanis]

Having come from 3ds Max and the exporter there used root objects and all my previous game engine export experience used root objects I think it might be best to decide on a root object only approach and leave collections up to organization only. But that may hurt some people's workflow. I always default to root object because layers and collections to me are best used for visibility and scene management. Otherwise I agree with your 1,3 path.

On Tue, Aug 6, 2019, 14:03 tngreene notifications@github.com wrote:

During 2.8 loading a 2.79 file, each Layer with something in it gets all its contents automatically put into Collection N. Layer 1,2, 20 becomes Collection 1, 2, and 20 with those items in it.

1. We can simply map Layers 1-20 to Collections 1- 20 as possible, but, xplane.layers that don't match will get dropped
2. We can also give Layer Props a new "Linked Collection" field, auto fill with name on first open. It allows us to rename a collection but must be manually tracked
3. We can put the data on the collection bpy_structs (?) themselves and draw it in the scene settings, using only top level collections as OBJs. Downside: If a collection is deleted, it would delete the props. Similar to deleting the Empty Root Object. Doesn't seem like a big deal though

I like 1 during the upgrade, then 3 for daily experience. This would be a very easy migration path.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/X-Plane/XPlane2Blender/issues/450?email_source=notifications&email_token=ABAJ3BRSY4RVFZD2TBUCMW3QDG4IXA5CNFSM4IJY4HO2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HDWLXTA, or mute the thread https://github.com/notifications/unsubscribe-auth/ABAJ3BRDIONTRQTIKM4YHPLQDG4IXANCNFSM4IJY4HOQ .

[lehthanis]

I often have layers and now root level collections that also have non export able things in it like reference drawings and template objects for kit bashing. Having a root object only approach means you'll always have an actual scene object that has its own set of xplane specific properties for the obj itself.

Another thing I contributed to the godot engine better collada exporter for blender was the ability to make each root object export as 0,0,0. This would mean that scenery developers could model entire airports in blender and place the root object at a corner of each building. Each building would get exported with that corner being the 0,0,0 point of the individual obj. Just a thought.

On Tue, Aug 6, 2019, 14:08 Robbie Powell lehthanis@gmail.com wrote:

Having come from 3ds Max and the exporter there used root objects and all my previous game engine export experience used root objects I think it might be best to decide on a root object only approach and leave collections up to organization only. But that may hurt some people's workflow. I always default to root object because layers and collections to me are best used for visibility and scene management. Otherwise I agree with your 1,3 path.

On Tue, Aug 6, 2019, 14:03 tngreene notifications@github.com wrote:

During 2.8 loading a 2.79 file, each Layer with something in it gets all its contents automatically put into Collection N. Layer 1,2, 20 becomes Collection 1, 2, and 20 with those items in it.

1. We can simply map Layers 1-20 to Collections 1- 20 as possible, but, xplane.layers that don't match will get dropped
2. We can also give Layer Props a new "Linked Collection" field, auto fill with name on first open. It allows us to rename a collection but must be manually tracked
3. We can put the data on the collection bpy_structs (?) themselves and draw it in the scene settings, using only top level collections as OBJs. Downside: If a collection is deleted, it would delete the props. Similar to deleting the Empty Root Object. Doesn't seem like a big deal though

I like 1 during the upgrade, then 3 for daily experience. This would be a very easy migration path.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/X-Plane/XPlane2Blender/issues/450?email_source=notifications&email_token=ABAJ3BRSY4RVFZD2TBUCMW3QDG4IXA5CNFSM4IJY4HO2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HDWLXTA, or mute the thread https://github.com/notifications/unsubscribe-auth/ABAJ3BRDIONTRQTIKM4YHPLQDG4IXANCNFSM4IJY4HOQ .

[tngreene]

@dpospisil said in #399

does not need to support two export strategies (root objects and layers), but just collections

This is worth a thought: after all, the organization unit (Collection vs Empty or Cube marked Root Object) both now appear in the outliner and almost entirely alike in abilities.

So, what should happen to the content of Collections 1-20 as created by 2.8 during its conversion of old .blend files? They all get put under an empty root object? Then you're just making a redundant organizational unit (a collection that can group and control visibility, and an empty that can group and control visibility)? Is that okay?

Or, what should happen to the content of Root Objects? The Root object Information removed and placed in a collection?

Where would you see the Root Object content if there is no UI panel or properties tab for a collection? All of the information in the Scene properties page? I thought in 2.79 it was too many to have 20 OBJ settings bubbles to scroll through. I've seen some projects with many many many root objects. What if it is more than 20?

Then, worst of all, what are we going to do about LOD support in Root Objects mode now that we don't have layers... (see #413 and #390) for more. Root Objects mode secretly is dependent on layers too.

(And my apologies to @lehthanis, I started typing this out while you were typing your response. Give me a second)

[arb65912]

going along with my previous explanations on simplicity and standardization for users using different setups I would simply treat collections and layers in 2.79. Simple. Just my opinion.

[arb65912]

I am sorry but I did not read all previous comments in dept, just added mine fast.

[lehthanis]

No worries... Next time I get to my machine I'll check out collections properties. If collections don't have an easy to access properties page but root objects do, then root objects seem like the best option to me.

I'd even get behind an empty as root with children empties representing each LOD. And the meshes as children of each LOD. But that may be difficult to code. If collections and sub collections is much more obvious and makes the most sense then that's a given too. There's no limit to number and depth of collections just like there's no limit to number and depth of children empties for organization and properties settings. So either way is good.

As a matter of fact, collections might be the way to go so as to not confuse with empties used for animation axes.

This breaks my suggestion for having each object export as 0,0,0 though.

On Tue, Aug 6, 2019, 14:19 tngreene notifications@github.com wrote:

@dpospisil https://github.com/dpospisil said in #399 https://github.com/X-Plane/XPlane2Blender/issues/399

does not need to support two export strategies (root objects and layers), but just collections

This is worth a thought: after all, the organization unit (Collection vs Empty or Cube marked Root Object) both now appear in the outliner and almost entirely alike in abilities.

So, what should happen to the content of Collections 1-20 as created by 2.8 during its conversion of old .blend files? They all get put under an empty root object? Then you're just making a redundant organizational unit (a collection that can group and control visibility, and an empty that can group and control visibility)? Is that okay?

Or, what should happen to the content of Root Objects? The Root object Information removed and placed in a collection?

Where would you see the Root Object content if there is no UI panel or properties tab for a collection? All of the information in the Scene properties page? I thought in 2.79 it was too many to have 20 OBJ settings bubbles to scroll through. I've seen some projects with many many many root objects. What if it is more than 20?

Then, worst of all, what are we going to do about LOD support in Root Objects mode now that we don't have layers... (see #413 https://github.com/X-Plane/XPlane2Blender/issues/413 and #390 https://github.com/X-Plane/XPlane2Blender/issues/390) for more. Root Objects mode secretly is dependent on layers too.

(And my apologies to @lehthanis https://github.com/lehthanis, I started typing this out while you were typing your response. Give me a second)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/X-Plane/XPlane2Blender/issues/450?email_source=notifications&email_token=ABAJ3BSYD33WGFJNHXILSSTQDG6CDA5CNFSM4IJY4HO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3WATIA#issuecomment-518785440, or mute the thread https://github.com/notifications/unsubscribe-auth/ABAJ3BVIISKCRVJT26LPP4LQDG6CDANCNFSM4IJY4HOQ .

[danklaue]

What I am most interested in recently, is a way to work together as a team on GitHub. The Blender 2.79 workflow with layers exporting to individual .obj files has been difficult to manage, as layers (bound to textures) aren't exactly a logical way to subdivide a plane into more manageable chunks.

I'm looking forward to Blender 2.8 workflow, since what I'm gathering about collections so far is, that they can be organized more flexibly. What I'd love to be able to do is, subdivide a plane into logical sub-components, such as:

-doors -landing gear -engines -control surfaces -panel objects

etc.

Ultimately, it'd be ideal to have each of the above stated logical objects be a .blend file unto itself, linked (or short-cutted) into a parent .blend file in such a way that the parent .blend file would contain no objects or meshes of its own, but only linked .blend meshes. This parent file could take care of exporting the .obj files, and the sub .blend files would be git-friendly miniature projects, each with their own version history, that could be tackled by different team members, with much less risk of conflicting while committing to the repo.

Most of the time these logical subdivisions do NOT coincide with how the project is laid out in the modelling and texturing phase, so you'll find, for example, your doors distributed over 4-5 .obj files.

My hope is, that with 2.8 a new workflow could be worked on that could facilitate a team-based environment, where several people could work on several different .blend files without stepping on each other too much, or without always uploading large binary files to the repo for any little change done to the .blend file.

I wonder if this could be achieved with Blender 2.8's new collections tools. If the collections are hierarchical, then maybe. The greatest challenge would be, to keep the "parent" file up-to-date with the latest version of all the child files, preferably somehow in real-time.

[tngreene]

@danklaue Checkout this little project I made. There are two absolutely amazingly modeled .blend files for the doors and wing of a plane and a master file that links both together. The "work lights" in doors.blend and wing.blend are outside their collections so when linked the lights are not in master.blend

In the future running Export OBJs in Door and Wing separately would produce one OBJ each, running it in Master would export all OBJs at once. Is this what you're talking about?

As far as real time collaborative editing in Blender, I think that is not a feature of Blender itself. You'll have to investigate that.

LinkedWorkflow.zip

[tngreene]

To reply to @lehthanis

If collections don't have an easy to access properties page but root objects do, then root objects seem like the best option to me.

The panels can draw anything you want on them. For instance, I could, on the lights page, give you a place to change the name of the 5th object datablock only if there is a collection called "Banana" in the blend file.

As said before, the Scene panel could draw the properties assigned to collections, thereby avoiding the need to reuse Empties or specially named Objects or Whatever. Then, of course, we would have the same thing we have now: Root Object OBJ Settings are visibile on the Object Panel, and Collection-based OBJ Settings are visible all on the Scene panel, similar to the Layers mode right now.

That's..... good? I'm sure there are some people who like having all OBJ settings in one place. I guess.

This breaks my suggestion for having each object export as 0,0,0 though.

Without thinking too hard about the situation there's always a checkbox to solve any problem!

[danklaue]

@tngreene , I opened your project, and it is truly, indeed absolutely brilliantly modelled. :)

So, this is a really good start, and I have actually gotten a bit farther than this in Blender 2.79. There, I've found (and modified) a Python script that allows you to "enter" into the child Blend file simply by hitting a shortcut. (I chose "TAB" as my shortcut, since it's the "Tab into Edit mode" function, which isn't available for linked files, but the script uses that shortcut to save the Master file and open the file of the selected mesh instead.)

Then you can edit the "child" file and press another shortcut to save the "child" blend file, close it, and open up the parent file again. The parent file then reflects the edits you've made to the linked child file... at least edits you've made to existing appended meshes. (Adding a new mesh object in the child .blend file will NOT be reflected in the parent .Blend file, unless you explicitly import that newly created object via "Link" command. This is not good, as your sample file already illustrates... I'd rather NOT have the child file have lights or other meshes that the parent file isn't automatically loading... they should be in sync).

Question: in Blender 2.79 there is only an option to append individual objects from another blend file. I see this is how you've appended them in 2.8 as well. This means, indeed, that something added to the child blend file after the fact (such as a light) will not be reflected in the parent Blend file, unless you pro-actively append it, right? ... but I'd LIKE it to be there... essentially, so that whatever change you make to the "Doors.blend", will be automatically and fully loaded into the "collection" of the Master.blend file.

Now, the "doors.blend" would probably contain interior windows, exterior windows, a manipulator, an exterior panel, and an interior panel, if the example file were a bit more, um, "complete". Each of these sub-components of the door would be textured with a different .png file, and thus, in Blender 2.79, would be sitting on a different layer. However, the main door animation bone would be spanning all of these layers. So, you'd have, for example, an animation bone that is present in layer 1, 2, 11, 12, and 20, and you'd have a mesh textured with "Exterior1.png" on layer 1, another mesh with "Exterior2.png" on layer 2, and the same for layers 11, 12, and 20, all parented to that main animation bone. This "doors.blend" file, if linked to the master file, would then ALSO have components in layers 1, 2, 11, 12, and 20.

How would this translate to Collections in Blender 2.8? Since collections and layers aren't 1:1 translated between 2.79 and 2.8, I'm not sure how one could link a complex, multi-layered item, such as a door, into the "Master.blend" file in such a way that if you were to export "Layer 1" (or "Collection 1" in the new paradigm), it'd export the part of the door that is textured with "Exterior1.png", along with the rest of the parts that are textured with "Exterior1.png".

I'm probably coming at this with the limitations of Blender 2.79... my HOPE would be, that 2.8 offers new tools or a new paradigm that would make this sort of thing possible, and perhaps even easier. I'm not too familiar with Collections yet, but I understand you can arrange them hierarchically.

I assume the "top level" of the hierarchy would be, what gets exported to the X-Plane .obj file (for example, "Exterior 1"). But if the "Exterior1.obj" file consists of "sub-objects" like a door, an aileron, landing gear parts, etc. the challenge would be, to harmonize all these. In Blender 2.79 this is done simply by un-checking the check box "Active Layer" upon linking... and since all Blender 2.79 files have identical layer layouts (from 1-20), the parent file will link the objects from the child file into their respective layers.

We'll have to find a workflow to do something similar in 2.8, if we want to pursue this method of being able to work on individual "objects" that all end up linked into a parent file.

[tngreene]

Collections actually kinda are mapped 1:1 with layers.

If you make a 2.79 .blend file with Objects on layers 1, 3, and 15 then open in 2.8 you'll get: Collection 1, Collection 3, Collection 15 under "Scene Collection".

The updater can count on that.

[tngreene]

I think, fortunately, ViewLayers have only one interaction with XPlane2Blender: Is a collection Included In The View Layer aka we shouldn't export that OBJ? Maybe? Yet another way to decide what Objects are going to be included or not! See my unwritten rant about all the ways to export or not export an OBJ or include or exclude a mesh using the outliner and other things. Yay.

[danklaue]

Can't wait to have SOMETHING to export .obj files in with Blender 2.8. Then I'll kick these experiments into high gear, and see what an be developed with collections. Looks powerful.

[tngreene]

(tl;dr at the bottom)

I think I'd like to think about some of this like this:

Where does OBJ settings live?

1. All on Root Objects, updater creates empties to place under collections?
2. All on Collections, updater moves OBJ settings from root objects if needed?
3. Root Object settings are kept where they are, Layers Mode settings are transferred to Collections

1 and 2 unify everything under one export mode, at the expense of changing the parentage and making Datablocks (1) or making a lot of current Root Objects useless (2). (Maybe we'd remove it for the user automatically?)

3 gets us two workflows again, which might be useful. I don't know what I like the most. I think the "Root Objects vs Something Else kinda like layers mode or not question" needs to be answered first.

What represents an OBJ?

1. Root Object and all its children, specially marked Collection and all its children
2. Update everything to specially marked Collections and all their children

2 would be much more powerful. Not only is it just 1 mode, but 1 object can be in multiple Collections, but each object can only have 1 parent (We'd be going with choice 2 in the above section then)

Where do you see the OBJ settings in the UI?

This part is easy!

• Replace Scene's Layers Settings with sections for each Collection that has OBJ settings
• If we're keeping them, Root Object settings are still on Object Settings
• Specially Marked Collections appear at the top, ones that are inactive and just represent grouping is at the bottom

Current Idea

So far what I like is

1. "Layers Settings and Root Object Settings both get transferred to collections on update"
2. A collection's children (with exceptions for when they're hidden and etc) goes into the OBJ
3. Manage collection settings on the Scene settings panel (because Blender doesn't have a Collections Panel as far as I've found, and, it is where everyone knows where to look)
4. ViewLayers are simply another way to change what Collections are active or not

Not sure about autodeleting any empties that used to be root objects and reparenting their children for the author. We'd have to see how that effects things. I'm leaning towards not since we can use them. Maybe "Used To Be Roots and Empty Type and at 0,0,0"? That's really representing nothing and is easy to remake...

With this we get a simpler XPlane2Blender and a lot more flexibility, but it still works in a familiar way, and the updater should have no problem handling these sorts of moves.

Root Objects projects can stay basically the same, Layers Mode Projects stay basically the same and even the OBJ settings are in the same place, and people get even more flexibility with organizing Objects!

[Karl1206]

I have nothing new to add but would just like to say how amazing root objects are for a cross-platform workflow. I would love to see the 2.8 exporter update keep this option. That's all haha

[airfightergr]

I thought of a way using collections, a bit different, but I'll give a shot... It's about aircrafts, mainly.

RATIONALE: Since there is an established way of doing things regarding the aircraft folder structure, may be is a good idea to transfer this way to blender with collections.

PROPOSAL:

• Have the whole aircraft under one main collection.
• Inside that collection, will exist 2 sub-collections. 1 for the COCKPIT_OBJ, and 1 for the rest of the OBJECTS.
• All cockpit obj stuff, will be inside the respective collection.
• Each individual object will have its own collection, inside the OBJECTS collections, following the rule 1 object (collection) -> 1 texture.

Here's how might look:

THE PROS:

• Makes "logical" sense, as it mirrors aircraft folder structure.
• You can easily show/hide items/collections etc in the outliner. My view is that the outliner will play a crucial role to my workflow, since, I think, that is the way that has been designed to work.
• Possibility to use collections (and outliner) for more stuff.

THE UNKNOWN: (at least from my side)

• Could collection naming be used as exported object's name?
• Could use one of the filters (for example Render or Holdout) to indicate which collection (object) should be exported?
• Other that I haven't thought of them yet.

THE CONS: (not any...I'm always perfect!)

• Have to adapt in a different workflow?

What's your thoughts?

[arb65912]

I like the structure and explanations that came with it.

I have a question though. What will be exported and how will it be determined?

If all collections are visible and are exported, would it export components to proper folders?

How would we "tell" exporter where to export objects?

[airfightergr]

Is your question about my proposal, @arb65912?

The place is the base for the export is the root folder of the plane. The cockpit object there, and since the other ones are inside the OBJECTS collections, will be exported to the objects folder. I can elaborate on this and say that if a collection is empty of objects and has only sub-collections, should reflect a folder.

For example, you might create inside the objects collection, another collection, ie, particles, which will only have a sub-collection for the particles.obj.

About which one to export, might be able to use one of the filters in Outliner, like the hold out here.

All the above is subject to, if this is possible to be coded.

[danklaue]

airfightergr, you actually bring up a very interesting way of working that I wasn't thinking about... up until now, my paradigm has been, to work with roughly one object per texture file (sometimes more are needed, because of characteristics like glass vs. non-glass). This paradigm was heavily influenced by Blender's 20-layer limit.

But since PlaneMaker now supports appending limitless objects, even in a hierarchical manner (and even supports putting the cockpit object inside the "objects" folder), AND Blender supports limitless layering and hierarchical layering, I agree that a new workflow might be in order, taking advantage of this.

So, based on your screenshot, I'd just even remove the parent hierarchy, at least for my projects, because I've become used to putting the cockpit.obj inside the "objects" folder. Everything related to 3D .obj files can be contained in the "objects" folders, and I think that should be considered "good practice" to keep it that way.

[arb65912]

@airfightergr : yes Ilias, that is what I meant. Thank you!

@danklaue : I would also second the proposal suggested by Dan. Cockpit.obj does not have to be anymore in aircraft root directory (smart move from LR in my opinion) but in "objects" folder as well as other objects. making it "special' is done in Plane maker as far as I know.

[lehthanis]

This folder structure is probably irrelevant to scenery obj modelers. Can't forget to make sure they're properly represented.

On Fri, Aug 9, 2019, 09:09 danklaue notifications@github.com wrote:

airfightergr, you actually bring up a very interesting way of working that I wasn't thinking about... up until now, my paradigm has been, to work with roughly one object per texture file (sometimes more are needed, because of characteristics like glass vs. non-glass). This paradigm was heavily influenced by Blender's 20-layer limit.

But since PlaneMaker now supports appending limitless objects, even in a hierarchical manner (and even supports putting the cockpit object inside the "objects" folder), AND Blender supports limitless layering and hierarchical layering, I agree that a new workflow might be in order, taking advantage of this.

So, based on your screenshot, I'd just even remove the parent hierarchy, at least for my projects, because I've become used to putting the cockpit.obj inside the "objects" folder. Everything related to 3D .obj files can be contained in the "objects" folders, and I think that should be considered "good practice" to keep it that way.

[image: 62769737-436a0280-baa2-11e9-9ca6-a7c18c227d55] https://user-images.githubusercontent.com/359923/62781066-bbbdcd00-ba7c-11e9-92f9-f98146178350.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/X-Plane/XPlane2Blender/issues/450?email_source=notifications&email_token=ABAJ3BUT5AFCQLSO6NFLCNLQDVUARA5CNFSM4IJY4HO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD36T3LQ#issuecomment-519912878, or mute the thread https://github.com/notifications/unsubscribe-auth/ABAJ3BRD723UJH3ESMIRHZDQDVUARANCNFSM4IJY4HOQ .

[danklaue]

Whoops, that screenshot turned out wonky. But while I was posting, airfightergr, I noticed your new post, which I really like.

I would strongly advocate for a simplification of the relationship between the .obj file format and how we visually work with it in X-plane, taking advantage of the Blender 2.8 upgrade, to eliminate unnecessary and superfluous options.

For example, all the things that end up in the header of the .obj file should be applied to collections, NOT to meshes or materials. These would include things like:

-Albedo texture -Night texture -Normal texture -NORMAL_METALNESS -GLOBAL_Specular -anything else we as authors have direct control over, and that wouldn't change throughout the .obj file

Then, all the "ATTR_" should be coupled to either meshes or materials, which I think we should consider carefully, based on usage in the real world. (For example, ATTR_light_level would make more sense to link to material, but "ATTR_OS" would make more sense to link to mesh, in my mind.)

A complete list of .obj8 format related stuff should probably be put forth as discussion material, maybe allowing us as authors to "vote" on where we think such features should be best placed for optimal integration into Laminar's intended way of using the format.

[airfightergr]

@lehthanis yes you are right. But was, and I believe always should be a way to choose your target. Until now is:

• Scenery Obj
• Instanced scenery Obj
• Aircraft part
• Cockpit obj.

Now we can have only Aircraft and Scenery objects, and use collections to set up things.

Also I have a proposal for scenery developers. Use 1 collection per object, which will contain sub-collections to reflect LODs.

[Karl1206]

@airfightergr Yes having LOD setup like this would be fantastic!

[tngreene]

I'm loving all these proposals, this is great stuff. I'm intrigued by the Collection with no objects is a folder concept. Very easy way to determine what will and will not be an OBJ!

Remember - there is a different between conventions and required set ups. I'm trying hard to not limit people to conventions unless there is a very good reason for it. Special names are a hard no, but using the names as data we can do (like taking the name of an OBJ from its root object name or collection name).

@airfightergr and others thinking about LODs: See my proposal here #451 which supports your screenshot idea but doesn't require special names or special patterns

[danklaue]

I guess I don't quite understand the "root object" workflow or paradigm... must be something people are carrying over from other programs or workflows.

I personally like the idea of naming the exported .obj by its collection name.

[arb65912]

Same here. I do understand root object concept. I like the idea of naming the exported .obj by its collection name.

[tngreene]

Something important to consider:

An object can only be under 1 root object at a time, but can be in multiple collections at once.

How does this change the question of

1. "Collections and Root Objects have OBJ settings"
2. "Collections are the only thing to have OBJ Settings, move Root Object settings to a parent Collection during update"
3. "Only Root Objects have OBJ Settings, Layers Mode projects all become Root Objects projects during update where there is one Root Object per layer

previously asked?

The ability to have the same mesh in multiple collections sounds awesome if collections are going to be making OBJs. I don't know how I would use it, but I can imagine other people have ideas! That makes #3 the worst.

I think we're all in agreement we want to use Collections as a way of making OBJs right?

The difference between 1 and 2 is simplicity of XPlane2Blender. I would love for everything related to OBJ settings to be in one place - in the UI and the data.

[tngreene]

@danklaue @arb65912 and others: Root Objects mode is more than just using the name of an object for the name for the .obj's file name. And yes, no matter what, that little fun feature is going in.

https://xp2b-docs.gitbook.io/xplane2blender-docs/index-4/35_indepth/workflow-options

[tngreene]

I think I answered my own question:

New plan, for the first draft Collections and Root Objects will have OBJ settings. Later on the updater can unify everything if we'd like.

[tngreene]

Alright, I've updated the current plan based on all the possible feedback I've gotten. Sometime during the next week I hope to have more of the 2.8 API changed over, or just a proof of concept in the UI that I can take a screenshot of.

We'll see how it works live instead of talking about it soon enough!

[danklaue]

Just to document another factor here: night lighting. Right now, I'm working on setting up a plane by its lighting groups. (Knob 1 lights up the overhead panel, knob 2 the pedestal, etc.)

This adds another layer of "grouping" to the mix, which in the current version of Blender is handled relatively well by materials. (Only exception here is, the "glass" type materials, which apply settings that should be global to the .obj into the material, which isn't ideal... the .obj header attributes should trump the material attributes every time, in my mind.)

What would be really helpful, would be a schematic of all the possible ways in which exports can be grouped... like, animations, lighting groups, textures, how they attach to PlaneMaker, ATTRs, etc.

When Laminar put forth the .obj8 format specifications, they obviously had a certain workflow or "best practices" in mind. It'd be great to use this Blender 2.8 transition as an opportunity to structure these types of considerations a bit better, closer to the way Laminar envisioned us working iaht them.

[tngreene]

Since I haven't released a screenshot in a while, here are two:

THIS IS A ROUGH DRAFT!

• The things to notice here are that it works (out put is the same, "Don't Use" cube doesn't show up)
• Where the collections UI is and that there is a checkbox to mark it as exportable. This way we're not using any UI of Blender that something else or somebody else might want to use.

The second screenshot is very boring: It shows that all the regular "Root Object" stuff you're used to is still there. It all works the same, and fans of Layers mode will note that all the per-layers settings are now in the exact same place in the UI

Use of collections is not dead! I do not, however, have a time table for alpha.2 or beta.1. This feature is simple from Blender's perspective, but not from an XPlane2Blender perspective.

[arb65912]

Thank you Ted!!!! Great news. 🥇

[tngreene]

We've basically got it it all! UI stuff moved to #506 (oh my god we're past 500 bugs - 2.49 what did you do to me!), bone tree collection is fine, it is the unit tests that needs being changed #493.