Thanks, I love this style of modelling for gamedev. Thanks to the yavne addon that predates the native modifier, which was my introduction to this style of modelling. Btw, I have always found it works best on 100, even though 50 is the default.
How would collection modifiers work if an object can be in multiple different collections simultaneously?
Lots of people model in the context of the final image. No need to model for 10 minutes if you can see from the final shot angle that 2 minutes of modeling hints at the desired amount of detail more than good enough.
I would guess that a bend modifier, applied to a collection, would only bend things within that collection.
You can have an object in that collection at the same time that it is in 1024 other collections. 1 collection has a bend modifier, 1 has subdiv, 1 has mask modifier, one has twist, one has build, one has remesh, and 500 have different varieties of bevel.
What should the mesh look like if it happens to be a member of more than one collection simultaneously?
Ah, sorry⌠i mis-thought that. I forgot that Blender collections are ⌠weird like that, and that the object isnât instanced across the multi-verse. For this very reason, I just naturally avoid doing that, so didnât remember what you were pointing out as a problem.
So, Iâll pull back my thought on that.
Well⌠why would anyone do that in the first place? I mean if youre seeing result and its messy you will simply not use that feature and use alternative right? Youre describing such a fringe case that absolutely every new feature can be questioned and break like that. Weâll just use the feature for the purpose it was created for
Come on, now youâre being a bit too easily dismissive of @thinsoldierâs point.
- There could be any number of reasons why such a thing might happen other than
'anyone doing it in the first place'
. Maybe you work on top of other peopleâs work who just happened to organize the scene in such a way (for any number of valid reasons). And then youâre tasked with âput a bevel on all the stuff which belongs to that excavatorâ. But itâs already not only inside the âexcavatorâ-collection exclusively. - In any case, independent of weather you or me consider it
messy
ora fringe case
, Blender would have to make some sense of it, in some fasion. I mean it would have to make something out of it. That,- from a development perspective - clearly raises the design-problem @thinsoldier referred to.
I guess one way it could work would be to automatically exclude anything (any object) from the collection-modiferâs effect, which isnât exclusive to that collection (but also contained in others).
greetings, Kologe
and to add to that, technically nested collections are just that, objects in multiple collections, though one never âseesâ it that way to be lacking some marker to show object is in more than one collection, at least in the default overview.
Well, yes and no.
Yes insofar as whatever is in the subordinate collection in the hierarchy is also in the superordinate one.
No insofar as this still doesnât mean the same mapping problem arises in such a case.
That is to say, the underlying problem here lies in the fact, the mapping
collection_00
object
collection_01
⌠⌠⌠⌠⌠⌠⌠.
⌠⌠.collection_02
âŚcollection_03
isnât unique. Only the inverse mapping
collection_00
object
So in other words, for any given collection, any given object either belongs to it or it doesnât. This includes the possibility it belongs to a subordinate collection.
But from the fact a superordinate (parent-) collection can have arbitrarily many subordinate (child-) collections, yet not the other way around (a subordinate collection always has exactly one immediate parent), it follows nested collections are unproblematic here.
You could basically treat the collection hierarchy like the modifier stack (the only difference being it can branch out from top to bottom).
So any object exclusive to a collection one hierarchy-layer into the collection-hierarchy (starting at the topmost level) would reveive the effects of the top-level-collectionâs modifiers, and on the evaluated result of that, the subordinate collectionâs own modifers would take effect.
edit: This is effectively the way C4Dâs semi-equivalent to modifiers (I donât quite remember the name of) works (iirc).
greetings, Kologe
Reusing parts of assets to make a variety of assets in different configurations.
Think of an old appliance store and in the corner you have 5 of the same lamp in different stages of incompleteness. One has all parts, one has no lamp shade, one has no bulb, one has no shade and no bulb.
You can have a single master collection with all parts as an asset and in sub collections you can link the various objects into the collections for the various incomplete asset versions.
Blender needs GROUPS separate from collections.
I enjoy and make use of the ability to put objects in multiple collections. Itâs like a tag (many to many) system in a database or blog. Itâs wonderful. BUT, IT IS NOT GROUPS.
Blender needs real groups like other software. While real groups may be able to reuse a lot of code from collections, I think it is essential that we get a real new data type with its own unique representation and name in the UI instead of just tacking on a way to make collections behave like groups.
We donât want âlayersâ + âcommon sense groupsâ + âwhatever collections actually areâ all shoved into this single thing called Collections.
I donât think that is the case. Objects seem to only know which collection(s) they are manually assigned to. It seems the collections themselves know which other collection they are a child of. To get what you describe I had to intentionally link the object to all child collections.
What is that an attempt to have a scene with 1000 objects and 4000 collections?
Even having collection in collection makes live harder. Just look at the move to collection menu⌠you need choose the collection twice!
Workflow⌠daily workflow. 40-60 per week in Blender and you think different.
When I tried to use collections as tags (aka 2.79 groups) I was very annoyed by fact what collections not linked to scene get lost on object duplication. For example, before:
After Shift+D:
So you are kinda forced to have 2 parallel hierarchies linked in outliner:
After Shift+D:
So weirdly old 2.79 groups worked much better as tags since they didnât need linking:
After Shift+D:
But Iâm not arguing for return to monke 2.79 groups, thinsoldier is right about:
I seen many new approaches during Modo 201-801 development. Some great, some really stupid. New is not automatically better. It mostly happens when developers do not know what users really need. If I want to select all linked objects, I also want the hidden ones selected. And if this is optional, so what. But they didnât do that. Things like that make live harder.
So, groups, layers, parent/child inheritance, object instances⌠all possible and it would greatly help USD implementation. But thats huge work and it doesnât result in beautiful images that work on public shows. Thats the problem, always been. It take many years till Maya got a file format that made loading 10 times faster. It happens with all 3d software. The users do not have a saying, nowhere.
What? Then, the broken feature was suggested as a solution for another broken feature?
Blender developers doing something thatâs technically interesting to them but messing up the UX for a lot of users doesnât feel uncharacteristicâŚ
But anyway, when they roll out this feature I really hope they add detection for old file formats, and automatically add the modifier (in the correct place in the stack) to all objects because as has been pointed out, copy modifiers wonât work (without scripting).
Not going to hold my breath for instances with modifiers, but seems instanced collections is a workaround for now⌠and that flashes me back to when we used Max at work and everything was a group and exported files became a structural mess⌠with USD being adopted as a collaboration format (and Blender lagging behind) Iâm seeing a chance to become red in the face many times in the years aheadâŚ
It is not about making something that is technically interesting. It is about making something consistent with all the other parts that have been converted to it as well. At the same time, it will likely improve UX in the sense that how and where the mesh data can be found in the UI is going to be more consistent.
I can confirm it does automatically add the modifier. Not sure about the stack position.
Instancing, alt D and instances on verts, work fine with the modifier, so you can breath now