Change Details

In the attribute workflow with fields some sockets/links contain data while some contain functions that only compute data later on. The goal of this task is to decide how we want to visualize different aspects of this design in the node editor. In earlier discussions we noticed that there are numerous aspects that can be visualized. Showing all different aspects at all times will probably overload the ui. Therefore, part of this task is to prioritize it is to visualize different aspects. The most important aspects can then always be shown, while other aspects are e.g. only visible in tooltips or when creating new links. Aspects that can be visualized: * Inputs that only allow data (includes geometry inputs). * Inputs that allow fields that are evaluated by this node. * Inputs that allow fields that are only passed through. * Outputs that are pure data. * Outputs that are fields. * Fields that only depend on built-in, named or derived attributes (those can generally be used on every geometry). * Fields that only depend on anonymous attributes (those can only be used on "downstream" geometries that contain the anonymous attribute). * Fields that depend on both. The main things we can change for the visualization are socket shapes/colors/borders/... and link styles/colors/... Changing node shapes has also been discussed a bit, but I don't find that very practical for this purpose. That quickly breaks down when one starts to build node groups. ------ Currently, my personal take on this is as follows. The two most important things to visualize are: 1. What sockets/links contain a (non-constant) field. 2. Which inputs allow a field vs. allow only data. I would not visualize the different kinds of fields differently based on what they depend on. In the majority of cases that will probably be obvious based on where the field is coming from. Still, the exact dependencies of a field should be visible in the socket inspection. Note, the same node can sometimes output a field sometimes not (e.g. the math node) depending on the inputs, so the visualization has to be a bit dynamic. For better learnability I like the idea of graying out sockets that you should not connect a field to (because it is not "downstream" and is missing required anonymous attributes).

In the attribute workflow with fields some sockets/links contain data while some contain functions that only compute data later on. The goal of this task is to decide how we want to visualize different aspects of this design in the node editor. In earlier discussions we noticed that there are numerous aspects that can be visualized. Showing all different aspects at all times will probably overload the ui. Therefore, part of this task is to prioritize it is to visualize different aspects. The most important aspects can then always be shown, while other aspects are e.g. only visible in tooltips or when creating new links. Aspects that can be visualized: * Inputs that only allow data (includes geometry inputs). * Inputs that allow fields that are evaluated by this node. * Inputs that allow fields that are only passed through. * Outputs that are pure data. * Outputs that are fields. * Fields that only depend on built-in, named or derived attributes (those can generally be used on every geometry). * Fields that only depend on anonymous attributes (those can only be used on "downstream" geometries that contain the anonymous attribute). * Fields that depend on both. The main things we can change for the visualization are socket shapes/colors/borders/... and link styles/colors/... Changing node shapes has also been discussed a bit, but I don't find that very practical for this purpose. That quickly breaks down when one starts to build node groups. We should also keep in mind that we might want to reuse the concept of fields in other node systems in the future. So if possible, we should try to avoid making the visualization too specialized for geometry processing. ------ Currently, my personal take on this is as follows. The two most important things to visualize are: 1. What sockets/links contain a (non-constant) field. 2. Which inputs allow a field vs. allow only data. I would not visualize the different kinds of fields differently based on what they depend on. In the majority of cases that will probably be obvious based on where the field is coming from. Still, the exact dependencies of a field should be visible in the socket inspection. Note, the same node can sometimes output a field sometimes not (e.g. the math node) depending on the inputs, so the visualization has to be a bit dynamic. For better learnability I like the idea of graying out sockets that you should not connect a field to (because it is not "downstream" and is missing required anonymous attributes).

In the attribute workflow with fields some sockets/links contain data while some contain functions that only compute data later on. The goal of this task is to decide how we want to visualize different aspects of this design in the node editor. In earlier discussions we noticed that there are numerous aspects that can be visualized. Showing all different aspects at all times will probably overload the ui. Therefore, part of this task is to prioritize it is to visualize different aspects. The most important aspects can then always be shown, while other aspects are e.g. only visible in tooltips or when creating new links. Aspects that can be visualized: * Inputs that only allow data (includes geometry inputs). * Inputs that allow fields that are evaluated by this node. * Inputs that allow fields that are only passed through. * Outputs that are pure data. * Outputs that are fields. * Fields that only depend on built-in, named or derived attributes (those can generally be used on every geometry). * Fields that only depend on anonymous attributes (those can only be used on "downstream" geometries that contain the anonymous attribute). * Fields that depend on both. The main things we can change for the visualization are socket shapes/colors/borders/... and link styles/colors/... Changing node shapes has also been discussed a bit, but I don't find that very practical for this purpose. That quickly breaks down when one starts to build node groups. We should also keep in mind that we might want to reuse the concept of fields in other node systems in the future. So if possible, we should try to avoid making the visualization too specialized for geometry processing. ------ Currently, my personal take on this is as follows. The two most important things to visualize are: 1. What sockets/links contain a (non-constant) field. 2. Which inputs allow a field vs. allow only data. I would not visualize the different kinds of fields differently based on what they depend on. In the majority of cases that will probably be obvious based on where the field is coming from. Still, the exact dependencies of a field should be visible in the socket inspection. Note, the same node can sometimes output a field sometimes not (e.g. the math node) depending on the inputs, so the visualization has to be a bit dynamic. For better learnability I like the idea of graying out sockets that you should not connect a field to (because it is not "downstream" and is missing required anonymous attributes).