Yes, I noted that above.
1 Like
Hello,
Another new build is available at the original link.
Updates include:
- Presets should work now
- A default file path, based on the Collection name is present (relative paths with
//also work now) - An icon will be displayed in the Outliner for Collections that have exporters configured
- Better error handling from OBJ in case of failures during export. It should be easier to see if one of the exporters has encountered a problem now
Let me know how the latest additions feel and look.
4 Likes
Hey, I was just testing the 4.2 Beta, I guess this feature now will have to make it into 4.3, but can we be able to export from the outliner icon? I can see why it might not do it, since you can have multple presets with the same collection included and different settings, in that case what about when clicking the icon having a dropdown with multiple export presets?
3 Likes
I think thatās great idea actually
Hi, here are three things that i noticed so far:
-
First one is a bug i suppose? When you go to the classic export window and define a new preset (i tested it with gltf) that has āInclude/ selected objectsā enabled - this setting will still be used for collection exports. Ideally it would ignore that Setting, and always export the full collection (or maybe only the visible one?). The path and file name are another settings that it loads from the preset, and i am not sure how useful that is.
-
Other than that, Blender also crashes about 30% of the time when i click the āfolderā button to pick an Export path. But i have no idea what could be affecting that, so unfortunately it is not easy to reproduce.
-
And one question - is there an expression i can add after an absolute path that will name the exported file according to its collection? My assumption was that i could simply leave it blank and only have the folder path in there. But when i do that, it throws an error about the path beeing invalid, so it clearly wants a complete file path, not a folder path.
1 Like
To add on to @Thane5ās comment about expression-based export paths: The collection export options are great conceptually, but theyāve been implemented in a way that makes them a bad pick for studio workflows and pipeline tooling. It doesnāt expose the right kind of API surface for that, especially for game dev.
A lot of the suggestions I see in this thread are for things that add-ons (albeit mostly internal, studio-specific ones, in my experience) already do, by wrapping the basic exporters in an operator with a scene iterator that exposes various pre-export hooks for things like renaming, grouping/splitting, altering transforms, and so on. It takes some boilerplate to set up, but itās robust, itās flexible, and it lets studios separate their core tooling from their project-specific stuff.
Expression-based renaming is a great example of something thatās both a good baseline feature and an opportunity to provide a pre-export hook. Simple substitutions and expressions are enough 80% of the time, but you canāt cover that remaining 20% without making the syntax far messier than anyone would want it to be. Similarly, only having a hook makes pipelines overly opaque and slows onboarding; having both makes both features better.
2 Likes
Now that this has been checked in for some months now, it would be best to file proper bugs instead of reporting to the feedback thread here. Can you do that?
No, not right now. There are ideas to add a few general path substitutions throughout blender but no concrete timeline or design on that yet. That said, from what I remember hearing about it, I donāt think there were going to be any ācontext specificā variables that could be used - i.e. like say a ${Collection-Name} expression that would only be valid in the context of the collection. Though maybe it could be special-cased in this instance if we had a general way of making that replacement.
Yeah, this was never intended to be a way to, or even a start of, implementing a general purpose āpipeline processorā inside of blender where you could assembly a bunch of steps to be executed during an export. Ideas or designs for that would probably be better suited to right click select or similar.
In a similar vane, if thereās something that the current python API makes difficult or impossible for external addons that want to write their own pipeline processor, that too would be interesting to have on right click select as well.
Blenderās workflows will never be everything to everybody, but the API can at least assist those who want to innovate with UI and workflow concepts themselves while leaving the heavy grunt work of certain tasks to the exposed API.
All studios really need is the ability to throw their own exporters into the collection exporter list, and itāll function as a pipeline processor. Everything else (including stuff like the USDHook post-export hook) can be done, and is often more easily done, with an operator that wraps an existing exporter.
Iād even use the wrapper approach for implementing path substitutions as a baseline feature. Makes it inherently extendable, gives folks a starting point for writing their own wrappers, and keeps the core exporters from accumulating overly-specific cruft.
1 Like
Will the role of the importer also be carried out here? For example, we really need a feature that can merge an animation cache into a collection made up of numerous meshes that have completed surfacing. I am curious if this aspect is being considered for future development.
By path substitutions you mean using expressions in paths, right? If so, I totally agree. Blender lacks path expressions in many areas.
Add-ons can register their own exporter in the list , see the 4.2 Python API release notes.
So studios can create their own, and hopefully there will be extensions with more advanced processing.
5 Likes
Thatās fantastic. I already have some stuff Iām pulling together for the USD Assets work group, this gives me another aspect I can integrate.
This seems kind of fundamental, but why canāt we rename the Exporters? If I need to export an FBX to say two different version installs of Unity, I canāt change the name. It seems like everywhere else in the blender interface, when you create something, you can rename it.
8 Likes
Thatās something Iām looking on improving in 4.3. Thereās a task we have containing some items that Iāll be considering for improvement at some point in the future: #125189 - Collection Export: Workflow and UX improvements - blender - Blender Projects
4 Likes
Sorry if iām late to the party here or if iām missing something. Is there a way when exporting a collection, the objects inherit their names from the scene. For instance, if i have cube001 and cube002 in my export collection, they will be named cube001.fbx and cube002.fbx on export?
Great feature tho. This really speeds up shipping assets into unreal and updating them on the fly. GG
apologies in advance if this question has been answered, still not exactly clear if itās a bug or not (based on reading through the feedback above). When I attempt to give the Export Collection and filepath, it says not a valid file. Unless I put the directory that includes the actual name of the collection itselfā¦
Example: (What doesnāt work)
Desktop/Meshes/
Example: (What does work)
Desktop/Meshes/MyExportCollectionAsset.fbx
Ideally we shouldnāt have to place the name inside the file path, its a lot of extra manual work when it could be as simple as selecting the folder, and done
love this update btw, Iāve been wanting a collection exporters for years, this make my job as a game dev so much easier
2 Likes
Yes! When I add an FBX exporter, I shouldnāt need to specify the extension since Blender knows what file I want to create. You should only have to select the folder where you want to export, and the file name and extension should be generated automatically. The name should come from the collection, and the extension should come from the selected exporter. Also just saw that in the official Blender video showcasing this feature the guy made the same mistake.
1 Like
Right, a full file path is expected right now. I donāt have any plans to change this for now.
I donāt want to encourage always naming your collections to be file-path-like since thatās where the file name would be coming from. Especially since collection names can contain non-filesystem-safe characters and are limited to being only 64 bytes in length (i.e. itās worse with collection names containing Unicode). It feels a bit restrictive to force Collection naming to align with file system naming in general.
Additionally, when configuring multiple exporters of the same type, like 2 FBX exporters, each of those would require a full path anyhow when saving to the same directory, which seems reasonable to want to do. The current UI placeholder and property for the file at least makes it more obvious about the concrete file name thatās going to be used.
Lastly, guessing the name is problematic for some types like USD, and to a lesser extent glTF, since files are written differently depending on the file extension. We provide a default placeholder name+extension but itās already not perfect. The current system nudges the user into providing the actual file name themselves in order to reduce additional surprises and ambiguity.
You raise a valid point about the use of unsafe characters in file paths. 
But then why have it so when the user does not specify a path, it defaults to the collection name with the appropriate extension anyway. Maybe adding a āFile Nameā field above the āFile Pathā window, allowing the user to specify the file name directly would solve this? Everyone is familiar with the workflow in the File ā Export menu, where the default file name is automatically derived from the Blender file and the appropriate extension is appended so if it did this from the āFile Nameā field?
Alternatively, at the very least, please ensure that users cannot set a path without specifying a file name. I recently encountered another video where the user was unaware they had omitted the file name. Just like in the showcase video.
1 Like