Change Details

The purpose of `NodeTreeRef` was to speed up various queries on a read-only `bNodeTree`. Now that we have runtime data in nodes and sockets, we can also store the result of some queries there. This has some benefits: * No need for a read-only separate node tree data structure which increased complexity. * Makes it easier to make reuse cached queries in more parts of Blender that can benefit from it. A downside is that we loose some type safety that we got by having different types for input and output sockets, as well as internal and non-internal links. This patch refactors `DerivedNodeTree` so that it does not use `NodeTreeRef` anymore but uses `bNodeTree` directly. To provide a convenient API (that also somewhat close to what `NodeTreeRef` had), a new approach is implemented: `bNodeTree`, `bNode`, `bNodeSocket` and `bNodeLink` now have C++ methods declared in `DNA_node_types.h` which are implemented in `BKE_node_runtime.hh`. To make this work, I had to change `makesdna` a bit to skip the C++ methods when parsing the dna header files. While this approach is not entirely clean, I couldn't think of a way to make the API work well without this yet. This approach also fits into potential future plans where DNA is only used for IO and Blender works more on C++ types internally (that was discussed in chat before). No user visible changes are expected.

The purpose of `NodeTreeRef` was to speed up various queries on a read-only `bNodeTree`. Now that we have runtime data in nodes and sockets, we can also store the result of some queries there. This has some benefits: * No need for a read-only separate node tree data structure which increased complexity. * Makes it easier to make reuse cached queries in more parts of Blender that can benefit from it. A downside is that we loose some type safety that we got by having different types for input and output sockets, as well as internal and non-internal links. This patch refactors `DerivedNodeTree` so that it does not use `NodeTreeRef` anymore but uses `bNodeTree` directly. To provide a convenient API (that also somewhat close to what `NodeTreeRef` had), a new approach is implemented: `bNodeTree`, `bNode`, `bNodeSocket` and `bNodeLink` now have C++ methods declared in `DNA_node_types.h` which are implemented in `BKE_node_runtime.hh`. To make this work, I had to change `makesdna` a bit to skip the C++ methods when parsing the dna header files. While this approach is not entirely clean, I couldn't think of a way to make the API work well without this yet. In the future we may want to split DNA C structures more from C++ types (e.g. like we did with `CurvesGeometry`), but that should be done separately. No user visible changes are expected.

The purpose of `NodeTreeRef` was to speed up various queries on a read-only `bNodeTree`. Now that we have runtime data in nodes and sockets, we can also store the result of some queries there. This has some benefits: * No need for a read-only separate node tree data structure which increased complexity. * Makes it easier to make reuse cached queries in more parts of Blender that can benefit from it. A downside is that we loose some type safety that we got by having different types for input and output sockets, as well as internal and non-internal links. This patch refactors `DerivedNodeTree` so that it does not use `NodeTreeRef` anymore but uses `bNodeTree` directly. To provide a convenient API (that also somewhat close to what `NodeTreeRef` had), a new approach is implemented: `bNodeTree`, `bNode`, `bNodeSocket` and `bNodeLink` now have C++ methods declared in `DNA_node_types.h` which are implemented in `BKE_node_runtime.hh`. To make this work, I had to change `makesdna` a bit to skip the C++ methods when parsing the dna header files. While this approach is not entirely clean, I couldn't think of a way to make the API work well without this yet. This approach also fits into potential future plans where DNA is only used for IO and Blender works more on C++ types internally (that was discussed in chat before).In the future we may want to split DNA C structures more from C++ types (e.g. like we did with `CurvesGeometry`), but that should be done separately. No user visible changes are expected.