LibOverride: Modify automatic handling of which IDs to override in a hierarchy. #115853

Bastien Montagne · 2023-12-06T16:50:56+01:00

Bastien Montagne commented

2023-12-06 16:50:56 +01:00

The previous behavior, fairly rough, was simply considering all
Collections and IDs found as part of the root's hierarchy as to be
overridden.

The new behavior is based on a specific tag added to some ID usages.
Currently, these are only the links from a Collection to its Objects
and children Collections, and the link from an Object to its parent.

The goal of this huge reduction of the 'automatically overridden' set of
data in a hierarchy is to avoid creating liboverrides for 'utils' data,
e.g. a collection used as source of data by a GeometryNode generating
some parametric geometry (Blender Studio use-case: some form of LOD
handling).

In general, it means that only Collections and objects part of the
collection hierarchy of the root collection are now overridden.

This should not change in the typical recommended use-case so far (where
there is a clear root collection to the whole overridden hierarchy, and
it contains all related collections and objects).

But this should allow much less overhead (and viewport pollution, due to
the current principle that local (and therefore liboverridden) objects
have to be instanciated in a Scene) for more complex setups.

Note that the initial idea/change is fairly simple and easy to
implement, but it creates some additional complexity in the partial
resync code, since now some linked data may not be detected as needing
a liboverride anymore when processing a sub-hierarchy, while it would
require it when processing the whole hierarchy.

This required adding some more processing to the util functions which
define which ID should be overridden. It essentially creates a
'reference set' of all reference IDs that should be overridden when
the whole hierarchy is considered, and use this as additional input to
decide which ID to override when processing a sub-hierarchy for the
partial resync.

The previous behavior, fairly rough, was simply considering all Collections and IDs found as part of the root's hierarchy as to be overridden. The new behavior is based on a specific tag added to some ID usages. Currently, these are only the links from a Collection to its Objects and children Collections, and the link from an Object to its parent. The goal of this huge reduction of the 'automatically overridden' set of data in a hierarchy is to avoid creating liboverrides for 'utils' data, e.g. a collection used as source of data by a GeometryNode generating some parametric geometry (Blender Studio use-case: some form of LOD handling). In general, it means that only Collections and objects part of the collection hierarchy of the root collection are now overridden. This should not change in the typical recommended use-case so far (where there is a clear root collection to the whole overridden hierarchy, and it contains all related collections and objects). But this should allow much less overhead (and viewport pollution, due to the current principle that local (and therefore liboverridden) objects have to be instanciated in a Scene) for more complex setups. Note that the initial idea/change is fairly simple and easy to implement, but it creates some additional complexity in the partial resync code, since now some linked data may not be detected as needing a liboverride anymore when processing a sub-hierarchy, while it would require it when processing the whole hierarchy. This required adding some more processing to the util functions which define which ID should be overridden. It essentially creates a 'reference set' of all reference IDs that should be overridden when the whole hierarchy is considered, and use this as additional input to decide which ID to override when processing a sub-hierarchy for the partial resync.

Bastien Montagne commented

2023-12-06 16:51:31 +01:00

@blender-bot build

Bastien Montagne force-pushed tmp-liboverride-default-hierarchy-handling from bd02784663 to 11a5626888

2023-12-06 18:50:08 +01:00

Compare

Bastien Montagne changed title from ~~WIP improvements and fixes to liboverride code.~~ to LibOverride: Modify automatic handling of which IDs to override in a hierarchy.

2023-12-06 18:52:19 +01:00

Bastien Montagne commented

2023-12-06 18:58:41 +01:00

@blender-bot package

Blender Bot commented

2023-12-06 18:58:44 +01:00

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR115853) when ready.

Demeter Dzadik commented

2023-12-11 15:25:51 +01:00

LGTM. 👍

To re-explain our use case here at the Blender Studio:

Let's take the Rocket Exterior, a very complex prop from "Wing It!". This has the case of a GeoNode modifier using a collection to instance some geometry and then do further operations on it.

So, we have a 0-vertex object, with a GeoNode modifier, which instances a collection named rocket.wing_improvised_umbrella.L. This collection is not used for any other purpose, and its objects never reference any objects outside the collection.

Without this patch, when linking and overriding the asset, the rocket.wing_improvised_umbrella.L collection and all its objects would still get an override created for them, and with this patch, they do not. So it works!

Although in this particular case, I did have to make a couple changes for this to work:

Collection had to be moved out of the asset's collection hierarchy. (It didn't need to be unlinked from the scene though)
Objects in the collection used to have some drivers on some modifiers, pointing at the asset's armature. These had to be removed.

So I think if we are mindful of those aspects and create our assets accordingly, we can indeed spare ourselves the creation of some overrides, in cases where they aren't meant to be deformed directly and don't need to reference anything in the asset.

It can be tricky to avoid any references back to the asset, but we should be able to tackle that using our future Convention Checker add-on.

LGTM. 👍 ---------------------------- To re-explain our use case here at the Blender Studio: Let's take the Rocket Exterior, a very complex prop from "Wing It!". This has the case of a GeoNode modifier using a collection to instance some geometry and then do further operations on it. So, we have a 0-vertex object, with a GeoNode modifier, which instances a collection named `rocket.wing_improvised_umbrella.L`. This collection is not used for any other purpose, and its objects never reference any objects outside the collection. Without this patch, when linking and overriding the asset, the `rocket.wing_improvised_umbrella.L` collection and all its objects would still get an override created for them, and with this patch, they do not. So it works! Although in this particular case, I did have to make a couple changes for this to work: - Collection had to be moved out of the asset's collection hierarchy. (It didn't need to be unlinked from the scene though) - Objects in the collection used to have some drivers on some modifiers, pointing at the asset's armature. These had to be removed. So I think if we are mindful of those aspects and create our assets accordingly, we can indeed spare ourselves the creation of some overrides, in cases where they aren't meant to be deformed directly and don't need to reference anything in the asset. It can be tricky to avoid any references back to the asset, but we should be able to tackle that using our future Convention Checker add-on.

Bastien Montagne force-pushed tmp-liboverride-default-hierarchy-handling from 11a5626888 to 26050cbdab

2023-12-12 17:02:55 +01:00

Compare

Bastien Montagne force-pushed tmp-liboverride-default-hierarchy-handling from 26050cbdab to 9efa36aca2

2023-12-12 18:44:13 +01:00

Compare

Bastien Montagne commented

2023-12-12 18:44:34 +01:00

@blender-bot build

Bastien Montagne merged commit fb8bf8b0c8 into main

2023-12-13 11:59:05 +01:00

Bastien Montagne referenced this issue from a commit