Sébastien de GraffenriedApr 2
Mikko Mononen

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

Mar 27 at 7:07amWeb
Show threadMikko MononenMar 27
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!
Show threadPer VognsenMar 27
@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.
Show threadMikko MononenMar 27

@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.

Show threadMikko MononenMar 27

@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 :)

Show threadDavidMar 30

@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).

Show threadMikko MononenMar 30

@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).

Show threadSébastien de GraffenriedApr 2

@MikkoMononen Thanks for the article, this kind of stuff is super-valuable!

I tried to build the project out of curiosity but got an error referring to a local path on your computer I believe. I'm a bit scared of CMake so I didn't dig deeper, but I thought I'd let you know!

Show threadMikko MononenApr 2

@seb_degraff You're welcome :)

There's note at the end of the readme.md on how to fix that. Omar fixed a thing about how the dear bindings are packaged (now also includes the backends), but there was no download link at the time.

Looks like there's a new Dear ImGui being released today, which should allow me to fix that.

Show threadSébastien de GraffenriedApr 2
@MikkoMononen Oh sorry, shame on me for not RTFM!
Configuration worked, but I had a bunch of compilation errors I didn't manage to fix. Maybe due to my somewhat old macos version and apple clang. I'll try on linux sometime!
Show threadMikko MononenApr 2
@seb_degraff Feel free to dump the errors on an issue. Could be that the cmake setup is borked on osx (have not tested it).
Show threadSébastien de GraffenriedApr 2
@MikkoMononen
Got this first, which I could solve by adding set(CMAKE_CXX_STANDARD 23) in CMakeLists.txt
```
In file included from /Users/seb/dev/data_inheritance/build/_deps/imgui_external-src/imgui_tables.cpp:198:
/Users/seb/dev/data_inheritance/build/_deps/imgui_external-src/imgui.h:303:5: error: unknown type name 'constexpr'
constexpr ImVec2() : x(0.0f), y(0.0f) { }
```
Show threadSébastien de GraffenriedApr 2
@MikkoMononen and then this one which I didn't look into:
```
In file included from /Users/seb/dev/data_inheritance/src/edit_gradient.c:4:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdlib.h:66:
[...]
MacOSX.sdk/usr/include/sys/_types/_uid_t.h:31:31: error: typedef redefinition with different types ('__darwin_uid_t' (aka 'unsigned int') vs 'int32_t' (aka 'int'))
typedef __darwin_uid_t uid_t;
```
Show threadSébastien de GraffenriedApr 2
@MikkoMononen data_inheritance/src/utils.h:5:17: note: previous definition is here
typedef int32_t uid_t;
Show threadMikko MononenApr 2
@seb_degraff Looks like the uid_t is type conflict with some darwin code, and the first one seems to be that it tries to compile the c++ imgui code as c.
Show threadSébastien de GraffenriedApr 2
@MikkoMononen Indeed, replacing uid_t by something else gets it to compile. (Even though *_t identifiers are technically reserved, not cool of apple squat uid_t when you include stdlib.h!)
The example runs and seems to work fine, thanks
Show threadMikko MononenApr 3
@seb_degraff I fixed the uid_t issue, and added some hints for the compiler to deal c++ better, and also included dear bindings. If you have time, I would be curious if it fixes the issues you had. If you dont have time, that's fine.
Show threadSébastien de Graffenried6d ago
@MikkoMononen Works perfectly!
Show threadMikko Mononen6d ago
@seb_degraff Thanks!