I have been working on data inheritance recently. The kind of stuff that you usually see with prefabs, but I believe that all the assets should support data inheritance.

I just released an article how to do that on property and container level. It tries to cover both the low level bits and the UI. It's one of those problems that have to be worked as a whole.

https://github.com/memononen/data_inheritance

I tried to keep things simple and used Dear ImGui for the example code, i n the hopes that someone can pick up the ideas and run whit them. Thanks @ocornut for awesome support!
@MikkoMononen Nice article! Even augmented with some of the additional information (e.g. the override flags), the derived data still feels more like a snapshot representation than a delta/change-based representation. My intuition is that a delta representation would be better at capturing the user's intention and therefore be better for rebasing, but I haven't thought deeply about it.

@pervognsen I had a bit of trouble trying to explain that. In my experience people coming from delta serialization or version control often has subtly different idea how things should be set up, and things can go wrong.

I still have some battle scars from UEs delta serialization, which makes me avoid it like plague :) So many things are simpler when you don't need think about where to get the data that is missing.

@pervognsen Some systems I've seen have an overlay of variants laid on top of the data, getters will do map lookup, which means custom storage and it becomes hard to debug.

In many ways this snapshot+flags is the simplest and quite resistant when things go sideways.

I also do recognize that I'm been thinking about this in a vacuum for 2+ years, and I might have just hit some local minimum :)

@MikkoMononen @pervognsen
I think especially with that screenshot example of a gradient, an artist would appreciate marking the colours as overrides regardless of whether the base changes.

The snapshot+flags seems like a good approach and the UI does well to make it clearer what is pinned in the derived data, but still not entirely obvious how the gradient works. I wonder if it would be easier to understand if you could flag entire blocks of data (the whole gradient).

@idbrii @pervognsen In my books the "mark entire block as overridden" goes into the "Hierarchical data" section, which I omitted :)

With hierarchical data like nested structs or objects, it makes sense to allow you to say at any point in the hierarchy that this struct/object and anything below it is overridden.

There are some cases where you may want to override the whole struct/object. For example, I think you should not override a component of a vec3 (and some people disagree with passion).