Nodes Modifier: Use runtime RNA definitions for input properties #113823

New Issue

Lukas Tönne · 2023-10-17T12:38:01+02:00

Lukas Tönne commented

2023-10-17 12:38:01 +02:00

Currently the Nodes modifier uses plain ID properties to store input values for the node group it executes. This causes some difficulties:

Animation paths use myobject['socketidentifier'] format, which does not match the actual socket name and makes it hard to tell which socket is animated.
ID property drawing requires a lot of extra data and is difficult to customize. This is a problem for the new Menu Switch nodes (#113445) that add an enum socket type and require a full enum items list for proper UI display.

In the past the ID property system has been extended to allow for more customization of generic property display, using subtypes, min/max ranges, property descriptions, etc. But this approach is only adding to an already complicated and confusing system. (https://archive.blender.org/developer/D9697)

The problems mentioned would be solved if there was a full RNA definition for the modifier inputs, instead of relying on generic ID property data. Such RNA definition will need to be generated dynamically at runtime because the modifier inputs are based on data (i.e. the node group used). At the time the ID property storage for the nodes modifier was implemented this dynamic RNA definition was not possible because only a small subset of RNA definitions could be generated at runtime. Now runtime RNA is a lot more capable and can be used to define all relevant properties for the modifier inputs.

The proposal includes the following:

Add a dynamic runtime RNA definition to MOD_nodes.cc, based on the node group.
Keep existing ID property storage. This will ensure that files remain backward and forward compatible, since ID-property-based paths remain valid.

Currently the Nodes modifier uses plain ID properties to store input values for the node group it executes. This causes some difficulties: - Animation paths use `myobject['socketidentifier']` format, which does not match the actual socket name and makes it hard to tell which socket is animated. - ID property drawing requires a lot of extra data and is difficult to customize. This is a problem for the new _Menu Switch_ nodes (#113445) that add an enum socket type and require a full enum items list for proper UI display. In the past the ID property system has been extended to allow for more customization of generic property display, using subtypes, min/max ranges, property descriptions, etc. But this approach is only adding to an already complicated and confusing system. (https://archive.blender.org/developer/D9697) The problems mentioned would be solved if there was a full RNA definition for the modifier inputs, instead of relying on generic ID property data. Such RNA definition will need to be generated dynamically **at runtime** because the modifier inputs are based on data (i.e. the node group used). At the time the ID property storage for the nodes modifier was implemented this dynamic RNA definition was not possible because only a small subset of RNA definitions could be generated at runtime. Now runtime RNA is a lot more capable and can be used to define all relevant properties for the modifier inputs. The proposal includes the following: - Add a dynamic runtime RNA definition to MOD_nodes.cc, based on the node group. - Keep existing ID property storage. This will ensure that files remain backward and forward compatible, since ID-property-based paths remain valid.

👍 1

Lukas Tönne added the

Type

Design

label 2023-10-17 12:38:01 +02:00

Lukas Tönne added this to the Nodes & Physics project 2023-10-17 12:44:17 +02:00

Lukas Tönne commented

2023-10-17 13:08:28 +02:00

Regarding animation paths: I'm not sure if we can avoid socket identifiers. The reason these are used is because

They are unique, unlike socket names.
They are persistent and allow renaming a socket without breaking animation paths.

So RNA-based paths would just turn myobject['socketidentifier'] into myobject.modifier['Nodes'].socketidentifier.
The socket identifier is also not strictly guaranteed to be directly usable as a property name. It gets auto-generated so whitespace and other invalid characters can be avoided, but there might be legacy identifiers from older files that break this assumption and there isn't any official restriction on built-in socket identifiers that can be chosen.

Regarding animation paths: I'm not sure if we can avoid socket identifiers. The reason these are used is because 1. They are unique, unlike socket names. 2. They are persistent and allow renaming a socket without breaking animation paths. So RNA-based paths would just turn `myobject['socketidentifier']` into `myobject.modifier['Nodes'].socketidentifier`. The socket identifier is also not strictly guaranteed to be directly usable as a property name. It gets auto-generated so whitespace and other invalid characters can be avoided, but there might be legacy identifiers from older files that break this assumption and there isn't any official restriction on built-in socket identifiers that can be chosen.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Nodes Modifier: Use runtime RNA definitions for input properties #113823