We are working towards the addition of a new feature to allow file format exporters to be associated with a Collection. This would provide a convenient, centralized, way of invoking one or more exporters on all objects contained within the Collection. Additionally, it provides a way to persistently store export settings, so they are remembered when reopening projects or when sharing with others.
The current implementation is ready for an initial round of feedback and discussion which is what this thread is about.
The way I think of this feature is like âRender Animationâ, but for when the output is a 3D model or scene file. For example when making assets for a game, or when working in a studio pipeline as a modeller or animator.
Eventually weâll want an operator to export all collections in a scene, with a shortcut bound to it.
setting up an âexportâ only collection with objects belonging to multiple collections still feels a bit strange to me after all this timeâŚ
if the export path is a directory nothing happens
its possible to emit files without endings for ex. â.objâ - which is not possible when using the regular export dialog
limit to selected only doesnât make much sense in this context in the exporter UI
there is no central place to kick off exports - need to find the collections in the outliner, and press the export button on the properties
great that it stores the exporter settings (much better than the current state where you need to remember those thingsâŚ) ⌠but presets are missing.
maybe an auto âexport on changeâ option? tho on heavy meshes this will probably not work.
Overall, I do not think this is a good idea. Thoughts:
Is the current UI intuitive and does it behave as you would expect given your typical usage of Collections?
No. I expect all import/export options to be in the File menu, not a separate place in the UI. The current design feels like what an Addon developer would do, if they werenât able to add code to the File menu/dialogs as it would normally be found.
Is this something that you would find useful in your typical work?
The basic answer is âyesâ, but the more accurate answer is - as proposed, this goes far below the needs for a feature such as this.
Is there something missing that would make this feature more useful?
What is actually needed is:
I select various things in the Outliner. It might be several objects + a collection, or just a collection(s), or 1 object, etc.
I go to the File menu, and choose SAVE SELECTED AS.
Iâm presented with a save dialog, that offers all the file types that Blender has - including both native and external (.blend, .obj, .etc)
The dialog notes my choice of file type, then presents the list of export options related to that file type.
I hit OK, and this is done.
While it may seem as the above merits a reminder of âBeyond the scope of this discussionâ, it is not. My intent is to point out that the proposal covers very few bases, and should not be implemented as such.
@thorn-neverwake what you are describing is the current File > Export workflow, but nothing about what would be different if you make those settings permanent? For example:
Where in the UI you can go to edit or delete the export settings
How you can quickly re-export without re-selecting object and opening a file dialog
How it deals with the case where you export multiple collections to distinct files
How to present difference between exporting currently existing selected objects, and exporting collection including future objects
Where these settings are saved, on which datablocks (collection, scene, blend file, âŚ)
Note that there is also an even further related goal, which is to place USD files directly in the scene hierarchy for import and export, and potentially have realtime sync with e.g. Omniverse or a game engine. In this case youâre not really thinking so much about exporting as an operation you do, but rather setting up a pipeline.
That requires thinking about the workflow differently, and it is a hurdle that may or may not be worth it depending on the user. Maybe there are ways to bridge the gap or make it more clear, but concrete suggestions for how to do that would be welcome.
Ok, with that in mind - it sounds more like this is a paradigm shift (of sorts), that would relate to both exporting and import to the scene. That wasnât obvious to me in the original description, so with that mind - I can see how the âproperty levelâ abilities would be a key factor.
So with that in mind, I think I understand the goal better now. In this such case, it feels that on the base level - it would have UX similar to how Baking is implemented, so I donât think would be a bit departure and require new thinking.
I donât think you always need a dedicated collection for export, it may be possible to organize it so objects are only in a single collection. But certainly there are complex cases where you need the control. Iâm not sure what would be a more user friendly alternative though. These alternatives donât sound great too me either:
Object flag to indicate if it should be exported or not
Some pattern matching based on object names
Indeed, the logic here could be made to match render output more I think, automatically adding a filename and extension when needed. Not sure if directory should be automatic or show a warning.
Yes, we definitely need a central place. Itâs a bit of a question where.
In some ways it is like rendering but the top level Render menu would be a strange fit. Though in for example Houdini I think these things are related.
Probably the File menu is the best existing places but the connection to the collection properties is not obvious. Suggestion for where this goes or how to tie it together are welcome.
Yes, presets should be added.
Probably too slow in practice even for not so heavy scenes. For now I expect a shortcut will be most practical. Live link and things like Omniverse are useful, and this can be a step in that direction, but it goes beyond this.
Thank you for the detailed and organized feedback! It is very much appreciated.
I can see how this would be the case for sure though in general we didnât really envision the use of an âexport onlyâ collection per se; though thatâs certainly possible to setup. The exporter would be configured directly on the Collection that contains the asset(s) to Export out; though that is obviously artist dependent depending on their preferred style of organization and general workflow.
As mentioned by Brecht, it will probably end up as a âFile â Export All Collectionsâ item right under the current âFile â Exportâ menu item if no other good place can be found for it. Though that of course has a downside that âall collectionsâ can be misinterpreted as really meaning âallâ of them, rather than âall collections with exporters configuredâ.
As for Presets, those require a bit more design and implementation work internally to support correctly but itâs on my radar to investigate at least. How much do you rely on Presets in your work? Is it because the default settings are really poor or because thereâs a wide split in how you export from asset to asset and you have, say, 2 or 3 vastly different FBX presets depending on the situation?
Thanks for following up - this was literally me trying the feature the first time and then reflecting about it.
Now after thinking a bit more about this - the object in multiple collections is not so bad, as it already exits in blender. Also the outliner is the place to manage such relations at the moment.
Guess itâs me not too being used to this workflow too much.
The plan with âFile â Export All Collectionsâ sounds fine to me - but I can see that its a bit hard to come up with a good name for this (also the not so obvious relation to the collection export panels).
For presets I think it depends on the project. I work in games, we are still quite dependent on fbx and there for example an export for unreal needs different options than an fbx which needs to go into maya.
Or often you need a certain scene scale on export which is nice to as a preset.
But itâs surely not needed for a first release iteration on this feature.
And again I think for games workflows this whole feature is pretty nice - one can setup the exports for highpoly, lowpoly and engine export just once and from then on its well defined and easy to iterate.
Some kind of feedback when export operations were successful would be useful
When something failed, it does not tell you which exporter was failed
Moving and renaming handlers, similar to the modifier stack, would be useful. For example when you want to export one with viewport settings and one with render settings
Duplicating collection does not duplicate exporters. Is this by design?
[Bug] With OBJ exporter when its filepath was emptied by Reset to Default Value, it does not warn about no file path given
[Bug] It seems changes in OBJ exporter does not register undo steps well. Try change settings in that and undo
I think this would still be useful when you want to do quick test without setting up another collection and another handlers.
Is it already possible, or would you consider exporting every object in collection as separate file, instead of one? Iâm exporting 50+ objects for 3D printing, .stl files, and I would like the feature that creates 50 stl file for 50 objects that I have in the collection.
I donât understand how this fits into the stated paradigm of:
And on top of that, we will start 2024 finishing projects!
For the first quarter the goal will be finishing the following projects:
âŚ
Projects like Geometry Nodes and Vulkan will be put on hold for the time being.
Weâre still in the first quarter of 2024, so why are new features being worked on when the official statement from the Blender Foundation is that Q1 2024 is for finishing high-priority projects?
Not every single developer is working on finishing these projects, just the large majority. This in particular fits the following statement of that blog post:
Cycles, USD and other modules will still continue their usual development.
This development is being done in the context of improving integration of USD and importers and exporters in general, in collaboration with developers from NVIDIA, Apple and AMD.
The ability to export different parts of the scene to different file paths is amazing! This is especially useful for game dev workflows! It seems pretty intuitive to me. Only things I noticed are:
I would expect the default file name to be the collection name with the file type suffix added
Selected Only doesnât really fit as mentioned
No success or failed indicators as mentioned
I would expect it to create the specified path if a folder doesnât exist
Overall, this seems like it might be better as a scene operation rather than a collection operation so we can see and manage all our exports in one place. If what to include was assigned to exports rather than the other way around, we could choose individual objects or even multiple objects or collections. A list of named exports in the scene properties and having them auto-populate a section in the File â Export menu sounds fantastic, but I could be overlooking the benefit of tying these to collections.
@jonlampel the original reason to have them as collections is that there is an idea to make this work for import and even two-way synchronization as well. Then you really need to place it in the scene hierarchy somewhere.
Though we backed out from that idea a bit and are now only concretely planning to do that for USD, since itâs technically challenging for arbitrary file formats and probably not worth the complexity.
For the USD case it seems more elegant for import and export to work in a unified way. But I can see how seeing all exports in a single place would be convenient too. Maybe there is some way to combine the benefits, not obvious.
Depending on how you use this, it may also be convenient for this kind of thing to get copied along with the collection when you duplicate or append it.
Perhaps add the ability to collection to collect objects based on pattern matching or object flag.
that could work for other purposes besides exporting, it will reduce the work done to arrange objects in collection if an object will appear automatically in the furniture collection if it contained the word furniture for example.
Or add a tag flag to an object that will make it appear automatically in a collection with the same name, that way the name doesnât get too complicated in the outliner if you want the same object to appear in multiple collectionsâŚ
The Collection Exporter is very useful for game development as @jonlampel mentioned, where you in general have blender files and the git or project folder separate and export into them.
I really like the functionality so far. It would be great to specify an external project folder from Preferences > File Paths. Likewise the file exported could be named the same as the collection. If needed, then you could enable specific options per collection like one of the following:
Specific location or name (like in the build linked)
Use external project folder from preferences ( /external/project/ + CollectionName.obj )
Option to add sub directory ( /file/paths/external/project/ + Subdir/ + CollectionName.obj )
Possibly make a hierarchy of Collections act as Subdirectories.
Another great option that would be to join all objects in a collection into one mesh.
I tried but failed at the context juggling in python and dealing the temporary copies of objects that then needed to be joined before export.
This idea would really benefit from the ability to specify global variables described in these suggestions:
The wording comes from houdini, but the concept to be able to specify your own paths to folders external to blender is really important in pipelines involving any other tools like houdini and maya and not least game engines like unity and unreal. At least, being able to set a project location once per user would be brilliant.
Thanks for the feedback everyone. The build has been refreshed with the following changes so far:
Thereâs now a File â Export All Collections item to invoke the exporters on all configured Collections.
Copying the collection should now copy any Exporters configured as well. The file path will not be copied to prevent accidental overwrites.
Undo for the OBJ exporter has been fixed.
Minor UI tweaks.
I havenât forgotten about the other feedback and Iâm actively working on addressing various other items mentioned above.
Work is ongoing to get the Python exporters fully working so that formats like FBX can be used. Additionally, thereâs changes required in order for the existing exporters to properly report their errors to the UI. Today, many of them report nothing for success or failure. Until that is fixed it will be difficult for a user to determine which Exporter is failing or succeeding etc.
Lastly Presets are still being looked at as well. Unfortunately thereâs a bit more investigative work to do there to get them to work fully in this setup.
Path substitutions and file names:
Having a set of âprojectâ related variables to substitute in paths is indeed something that has come up from time to time. Though itâs a bit outside the scope of this effort here.
For naming the file names the same as the Collection, how do folks envision that working if the user changes the Collection name after the exporter has been created? Does the path get modified accordingly? Does the user have control over the file name portion of the path at all?
This is a great addition to Blender, and as someone who already uses an addon called Bundle Exporter to do this exact thing I thought Iâd chime in with some things I find essential in said addon:
-The ability to set where the origin point is. The addon gives these options:
-âModifiersâ per collection. Essentially these are tasks that are run on a collection before export, and again Iâll list whatâs available in the addon:
Not all of these are self-explanatory, so Iâll talk about some of the ones I use often:
âExclude from Exportâ allows you to only export objects that are either visible or selectable, enabling you to keep helpers objects or backups around inside of your collection without risking exporting them.
-âGroup Instances to Objectsâ
Turns Collection Instances into objects so they export. Allows the use of them for, say, instancing screws on your object. Honestly, I think this should just be the default though!
-âRenameâ
Allows you to rename your object with this dialog:
This frees you from the constraints of whatever naming scheme you need for your final destination, say a game engine. You might need prefixes, postfixes to indicate where an asset belongs, what it does, etc⌠but all of those can make for long unfriendly names and itâs nicer to work with shorter, scene-specific ones in your Blender file.
âMerge Meshesâ
Merge all, by sub-collection or by parent
Very useful when your game-object needs to be one (or at least fewer) objects, giving you ultimate control over which objects are merged while keeping your collection separated (and: keeping each objectâs local pos/rot/scale). Extremely useful, especially as you often want your game asset to consist of as few separate objects and materials for drawcall reasons.
Some of these might go outside of scope for this task, but I do hope youâll consider at least some of them
That is not the point of this addition. I think that you are missing the use case. This addition is not trying to solve exporting related usability issues.
I developed an addon some years ago for exact use for objects and scene level batch export. The use case is that the user needs to export certain objects regularly with the same type of exporter format (GLTF, FBX, BLEND etc) to the same OS directories. This is especially important for the game development pipelines where the asset production and the engine integration is iterative. This is akin to set up once repeat forever approach.
