Feature Request: New export modes, "Auto, No Recursion" and "Auto, Single Recursion"

[sna-scourtney]

I've just started using this excellent tool (thank you for making it!), and I hope it's not presumptive to offer a suggested enhancement to the export feature. In addition to "Auto" and "Export Recursively", I think it would be helpful to have "Auto, No Recursion" and "Auto, Single Recursion" options.

My Blender project is using Archipack to create room geometry with procedural doors and windows. For export, I've created my own Collections in Blender that define what I want to export to UE, independently of the Collections that Archipack sets up automatically. I am linking objects into my custom Collections, rather than moving them. With that background, here are some examples of use-cases for the proposed features:

• Archipack creates an object hierarchy for doors in which the handle or knob is a child of the door panel, and the door panel is a child of the door frame, and the door frame is a child of the wall. I want to export the walls all together as a single static mesh (or as a group of separately-exported static meshes, if necessary for occlusion culling performance). But I do not want the doors exported, because that creates a lot of identical UE static mesh assets. Instead, I want to manually export the door assembly once, set up an animation/activation Blueprint for it in UE, then place them around my level using UE Sockets that I would place at the lower center point for each door. If I export the Collection recursively, it's hard to get a hierarchy of walls, floor and ceiling slabs, etc., but not recurse into the door and window assemblies.
• In some cases, one might put rough placeholder objects into the Blender project but replace them in UE with detailed models from purchased (or separately developed in-house) from elsewhere. In these situations, it would be useful to set their parent object to never export its children. This avoids the need to remember to set "Do Not Export" on each child as they are added.
• The "Do Not Export" flag is useful, but in some cases whether or not something should export depends on the ancestry path of reaching it. Take the preceding wall and door example: The door assembly should definitely export when it's selected as part of a "openings" Collection, but should not export as a child of the "structures" Collection. The proposed feature would allow setting a one-level recursion on "structures" and full recursion on "openings", while leaving the individual walls, floors, ceilings, etc., at "Auto". Then just link one of each door and window type into the "openings" collection, and link all the walls, floors, and ceilings (but none of the doors or windows) into the "structures" Collection. Now the exports can be iterated simply by toggling one or both of those Collections on or off at the export dialog.

For clarity, the requested behavior of these two settings is as follows:

• "Auto, No Recursion" causes the object or Collection to be exported if its parent is exported (just like "Auto"), but no recursion will be done on this object or Collection regardless of the parent's recursion option.
• "Auto, Single Recursion" causes the object or Collection to be exported if its parent is exported (just like "Auto"), and recursion will include exactly one level of children, no more. Each child will be exported if its setting is anything other than "Do Not Export", but no recursion below the child will occur, regardless of which variant of "Auto..." applies to the child.
• In any case where the parent or child disagree on recursion below the child, the less-inclusive behavior is chosen. The intent is to allow leaf objects to be "Auto" or "Export Recursively" most of the time, presuming those are the most common situations, but to allow the parent to restrict recursion for situations in which some objects are exported from different parent Collections.

The inspiration for this suggestion comes from LDAP directories, where queries can recurse zero, one, or infinite depth.

Thank you for creating this excellent plugin, and for reviewing and (hopefully) considering this proposed feature.

[xavier150]

Hey @sna-scourtney I have not yet had time to answer and test but I wanted to specify that I have noted and taken into account your request. Thanks for the support I will recontact you later ^^