Modifiers on Collections
I often split my models into multiple submodels that I then put into one collection for easy instancing and handling. If I now could add modifiers like arrays, displacements or booleans onto the whole collection...
I often split my models into multiple submodels that I then put into one collection for easy instancing and handling. If I now could add modifiers like arrays, displacements or booleans onto the whole collection...
34 Comments
It's covered in part by the upcoming Overrides and Everything Nodes project, hopefully possible in 2.81 or 2.82
* @Pablo Vazquez * Just for clarity's sake, the modifier wouldn't be applied directly to the objects in the collection with the overrides system. Instead, the modifier would be applied as an override on an instance of a collection. Is that correct? That seems like a pretty sensible approach and neatly handles the case where an object belongs to multiple collections.
* @Jason van Gumster * Yes I believe that's how it would/should work.
* @Jason van Gumster * I think it could get over complicated quickly if you start having to have group instances. I'd prefer to just apply the modifier to the collection, and then whatever is in it will get the modifier applied. You could always create a seperate collection just for the modifiers if necessary. This would also mean that the collection could be instanced as a group instance and the more expensive geometry would only exist once.
Although I guess when blender adopts a USD scene description like Houdini just did, then memory issues will be a thing of the past anyway.
* @tibbyninja * The problem with applying a modifier directly to a collection is that the situation gets exponentially more complicated when an object belongs to multiple collections. It's much cleaner if you apply it to an instance.
* @Jason van Gumster * I'm not sure I follow, why would it be more complicated if it belonged to multiple collections? Would it not just be a case of having a collection suffixed with "modifiers", for example suzanneForeground_modifiers, suzanneLowRes_modifiers. Where the subdiv modifier on the lowres collection could have less subdivisions compared to the foreground suzannes. This would also mean you could instance suzanne with group instances as many times as necessary in the background and not have to add the modifiers to each instance. It would definitely be a huge memory saver too, faster viewport/rendering etc.
Not only that, but the workflow would be much more efficient too, because you would be able to turn off modifiers en masse for all objects in that container at once (during a simulation for example).
* @tibbyninja * Just to expand a little futher, with this method you could have the suzanne geometry once in memory without the modifiers, once with ow res modifiers, and one more time with high res modifiers. After this you could create as many group instances as you wanted and still only have 3 items in memory (each with different modifiers).
You could take advantage of cascading collections, for example one collection called "suzanne_arraymodifier" nested inside a "suzanne_subdivisionModifier" collection. You could then group instance the low res "suzanne_arrayModifier" collection in the background, and use the "suzannne_subdivisionModifier" collection in the foreground. Then only the foreground suzannes would have the higher res geometry, whilst the background suzannes would remain low poly.
Or another example, you could nest a "suzanne_RBD" inside a "suzanneSubdivision" colection, and then use the RBD collection in the RBD physics settings, and then the simulatin would calculate much faster by turning off the parent containers subdiv modifier during simulation.
* @tibbyninja * Here's the complication. You have a Suzanne mesh. She's in two collections, CollectionA and CollectionB. Let's assume you have modifiers applied directly to the collection. Now, CollectionA has a subdiv modifier with 1 subdivision and CollectionB has a subdiv modifier with 3 subdivisions. What happens to to Suzanne is very vague. There's three options:
In contrast, let's assume that you can't apply modifiers to collections, but you can apply them to instances of a collection. In that situation, all ambiguity is removed. All instances of CollectionA have Suzanne with 1 level of subdiv while all instances of CollectionB have Suzanne with 3 levels. It's a much more predictable situation.
* @Jason van Gumster * they would accumulate. The solution is to use collections properly and reap the benefits of a much more robust and memory friendly system.
Choosing a far inferior system to safeguard against people making mistakes is a bad route to take in my opinion.
* @tibbyninja * It's not a safeguard against mistakes. It's clear design. Furthermore, if you didn't want modifiers to accumulate, the scene becomes a lot more kludgey and difficult to maintain.
* @Jason van Gumster * I think we'll just have agree to disagree :)
* @Pablo Vazquez * Pablo any update on this? =D
Aaaanda it never happened...
Arrays to collections is a BIG dream. Curves as well.
I think this feature has already been added to Blender 5.2 projects.blender.org/blender/blender/commit/1504d9d5868ab8cedc44b4dbdb4414bf91211ac2
Wonder if theres any updates on this? Looks like gold to me XD
Absolutely need this.
+1 for me too
Does anyone know anything about the current development progress in this?
Cool that this is in development. Question: Is it going to be possible to put modifiers on collections or on collection instances? or both?
* @Jelleeey * At this point, the modifiers would be applied to collection instances.
* @Jason van Gumster * That's very useful.
Hello does that mean that wee could apply the modifiers on a linked object ? I think that would boost the performance ,, i'd like to link my model (wich is full of booleans and bevel modifiers wich i like to tweak ) in another blendfile for animation and be able to link it with the modifiers applied because the modifiers like booleans punch the performance on the face when mooving the object ... would that be possible? or am i missing something? :)
* @lucaspedrajas * I'm not sure that it would boost performance unless there was some kind of caching involved.
Alf, same here. A hard lesson learned years ago, BACKUP. This is why I'll miss the Layers bar.
Would be cool to find an easy solution for this. I'm using collections basically as groups, not sure what the traditional Blender way of doing this would be, pretty new to the software.
There is no traditional way of doing it. There was no way with groups, nor there are (yet) with collections. I would use Python for that and any advanced Blender user would do as well I think, since it's so simple to do.
* @Pablo Vazquez * Yes, python seems like on OK workaround, especially for single models which are split up into a few pieces (still, not a very user-friendly one I have to add). For larger more complex layout scenes which are getting constant updates it'd be something that'd exceed my python abilities though, for sure. I do like that you said "(yet)", so fingers crossed. :)
I agree that it would be handy to be able to add modifiers to a "group" of objects, but a collection is not the right way to do it. An object can be in more than one collection, how would you solve that?
* @testure * I think you could have it as a selectable option, one of many and it would be the one that is currently instanced with the modifier would have the modifier. Currently you can have the same mesh data using alt+d and have many variations due to modifiers.
* @testure * Why would that matter? I'd treat the whole collection as one mesh
* @testure * I think the best solution (and I think it's the one in development) is to apply the modifier to an instance of the collection as an override. That should elegantly solve the issue of an object in multiple collections.
* @testure * It shouldn't matter if an object is in multiple collections if each collection has it's own function, like one for modifiers and one for renderlayers for example. It could even simplify things. For example you could have 3 nested subdivision collections, each with subdivision level 1 (cascading subdivision). This way you could control the subdivision of the entire scene with only 3 modifiers (if 3 is the max subdiv level you want ).
Objects in the parent would get one level of subdivision, the objects in the child collection would get two levels (because they'd also inherit the parents modifier), and the grandchildren would get 3 levels. You could also turn them all off at once by just disabling all 3, or just have the grandchildren have 1 level by turning off the parent and child.
* @Jason van Gumster * Couldn't it be solved by simply putting a symbolic "clustered" [Collection "X" modifier] in the objects modifier stack that can be sorted like any other modifier?
To me that would be the most intuitive UX-wise / the behavior I would expect as a user. (Also easy to use)