For the end user:
Designing the material = designing the configuration of the object graph.
Design Space
How do we want to build those object graphs in VL?
In a special UI
In a descriptive patch outof process nodes
Do we want to have many ways of expression or one?
Do we want to have default object graph configurations or are they behaving counter-intuitive?
What can we learn from prefabs (term stolen from Stride) and templates (term stolen from code-centric thinking)?
High and Low
Importing libraries is tricky. You want to have a high-level node-set that every user can use without really being able to do something wrong. And you often want to also combine this with an advanced node set for those users that want the low-level functionality as well. It would feel right if the user would also be able to combine these high-level and low-level nodes in some way.
The low-level nodes typically are nothing else than the original methods of the original types offered as nodes, coming with State In- and Output pins of the respective original types.
What's more blurry is the quest to design the high-level nodes. There are several design possibilities. And there are different ways to glue them to the low-level node-set. The quest is about high-level nodes; a proposal should also address how those combine with the low-level nodes.
Isolated vs. Object Graph
There are examples of nodes that are high-level and are isolated, making them super easy to use.
With isolated, I mean nodes with very common input and output types or nodes that do something right there.
A damper or a OpenCV filter e.g. are high-level process nodes that can be perceived as isolated. They act on established data, outputting new data.
But I'd say also the Skia layer nodes can be understood as somewhat isolated. They all are there serving a particular task without influencing them much.
But there are examples of object graphs where you need many nodes to build up something meaningful. The user-built object graph is a form of description, that might internally also distribute some computation between the nodes, but not necessarily. From a user perspective, the most important aspect is that several objects need to reference each other - building an object graph - in order to express something meaningful.
E.g. in order to build ONE material, you need an object graph describing that material.
Proposals for the quest should address how to easily build object graphs from a high-level user perspective and how to modify them
at design time
at runtime
How to ensure the readability of a patch and how to make sure that the node-set is self-explaining.
Immutable vs. mutable object graphs
In the Skia library, there is a SKPaint type that got wrapped in an immutable fashion, yielding the new type: SkiaPaint, which is a record. There are several ways to build such an immutable type that then somehow translates to instances of the mutable type, but they all come with their issues.
You wrap instances of the mutable type inside the instances of your immutable type -> this might force you into cloning those wrapped instances a tad too often
You work with your immutable type and only in the end - in your sinks - translate the immutable description into some living and mutable. You need some synchronization mechanism, which might be tricky or tedious to get right.
However, there are also cases where it feels right to work with the original types. Proposals on how to patch and manage object graphs in a high-level and readable fashion should be aware that there are these two flavors:
purely descriptive node graphs as seen in the SkiaPaint node-set. A SetColor node does not mutate a paint object. It outputs a paint object that differs from the incoming paint object in that one property. Allowing the user to make use of the different paint objects that arise along the way. An object graph that is built of many snapshots.
descriptive node trees. Those describe ONE mutating object graph over time.
Object Graphs are Objects that refer to each other. Here you can see the desciption of a material, organized as a nested object structure, allowing different configurations and permutations of material features: https://doc.stride3d.net/latest/en/manual/graphics/materials/material-attributes.html
For the end user: Designing the material = designing the configuration of the object graph.
Design Space
How do we want to build those object graphs in VL?
Do we want to have many ways of expression or one? Do we want to have default object graph configurations or are they behaving counter-intuitive? What can we learn from prefabs (term stolen from Stride) and templates (term stolen from code-centric thinking)?
High and Low
Importing libraries is tricky. You want to have a high-level node-set that every user can use without really being able to do something wrong. And you often want to also combine this with an advanced node set for those users that want the low-level functionality as well. It would feel right if the user would also be able to combine these high-level and low-level nodes in some way.
The low-level nodes typically are nothing else than the original methods of the original types offered as nodes, coming with State In- and Output pins of the respective original types.
What's more blurry is the quest to design the high-level nodes. There are several design possibilities. And there are different ways to glue them to the low-level node-set. The quest is about high-level nodes; a proposal should also address how those combine with the low-level nodes.
Isolated vs. Object Graph
There are examples of nodes that are high-level and are isolated, making them super easy to use. With isolated, I mean nodes with very common input and output types or nodes that do something right there. A damper or a OpenCV filter e.g. are high-level process nodes that can be perceived as isolated. They act on established data, outputting new data.
But I'd say also the Skia layer nodes can be understood as somewhat isolated. They all are there serving a particular task without influencing them much.
But there are examples of object graphs where you need many nodes to build up something meaningful. The user-built object graph is a form of description, that might internally also distribute some computation between the nodes, but not necessarily. From a user perspective, the most important aspect is that several objects need to reference each other - building an object graph - in order to express something meaningful.
E.g. in order to build ONE material, you need an object graph describing that material.
Proposals for the quest should address how to easily build object graphs from a high-level user perspective and how to modify them
How to ensure the readability of a patch and how to make sure that the node-set is self-explaining.
Immutable vs. mutable object graphs
In the Skia library, there is a SKPaint type that got wrapped in an immutable fashion, yielding the new type: SkiaPaint, which is a record. There are several ways to build such an immutable type that then somehow translates to instances of the mutable type, but they all come with their issues.
You wrap instances of the mutable type inside the instances of your immutable type -> this might force you into cloning those wrapped instances a tad too often
You work with your immutable type and only in the end - in your sinks - translate the immutable description into some living and mutable. You need some synchronization mechanism, which might be tricky or tedious to get right.
However, there are also cases where it feels right to work with the original types. Proposals on how to patch and manage object graphs in a high-level and readable fashion should be aware that there are these two flavors:
purely descriptive node graphs as seen in the SkiaPaint node-set. A SetColor node does not mutate a paint object. It outputs a paint object that differs from the incoming paint object in that one property. Allowing the user to make use of the different paint objects that arise along the way. An object graph that is built of many snapshots.
descriptive node trees. Those describe ONE mutating object graph over time.