Files
test2/source/blender/gpu/shaders/gpu_shader_2D_nodelink_frag.glsl

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

65 lines
2.2 KiB
Plaintext
Raw Normal View History

/* SPDX-FileCopyrightText: 2018-2022 Blender Authors
*
* SPDX-License-Identifier: GPL-2.0-or-later */
#include "infos/gpu_shader_2D_nodelink_infos.hh"
FRAGMENT_SHADER_CREATE_INFO(gpu_shader_2D_nodelink)
#define ANTIALIAS 0.75f
2024-06-28 13:09:06 +02:00
float get_line_alpha(float center, float relative_radius)
{
float radius = relative_radius * interp_flat.line_thickness;
float sdf = abs(interp_flat.line_thickness * (interp.line_uv.y - center));
return smoothstep(radius, radius - ANTIALIAS, sdf);
}
Geometry Nodes: Dashed lines for function flow Use dashes to represent the function flow (while keeping continuous lines for the data-flow). It is important to tell both flows apart (the data and the function flow). The sockets help with that, the noodles help this further. The "data flow" is evaluated at every single node. A user can inspect the output sockets of those nodes and have a glimpse at their values. The "function flow" (nodes) however is only evaluated in the geometry nodes. The noodles are not transporting data in the same sense of the "data flow". All that can be inspected are the attributes the functions depend on. Having this clearly communicated should help users to inspect the nodetrees, read and understand the different flows in the same tree. --- Known limitations: At the moment the dash lines are not equidistant: * It would be nice to get the "uv.x" to be resampled for the bezier curve so the dashes are equally distributed in the curve. * Using distance between the P3 and P0 instead of the real bezier curve length seems to be fine. --- Full disclaimer: Changes with that much of a visual impact tend to be controversial. So far the main feedback is that dashed lines can be associated to broken link, and that there are better ways to represent the flows (or different information that should be visually represented). I'm fully aware of that. However dashed lines are already used in the viewport and outliner to indicate (hierarchical) relation. Besides, other approaches (double-lines, having the data flow to be more distinct, ...) didn't pan out in the end (or didn't look as good as this). --- Impact in other editors: The compositor uses mostly a "data flow" nodetree, so no change is expected there. The shader nodetree is one that could but doesn't have to change its visual language. The shader nodetree uses mostly "function flow" with some "data flow" nodes. One can argue that it should be adapted to follow the same pattern as geometry nodes (with the new noodles and the diamond sockets). Oh the other hand, a shader nodetree has a single context. When a node depends on the "UV", there is only one UV at a time for the entire nodetree. So it can also be treated as a psedo "data flow" nodetree if we want to avoid too many changes in other parts of Blender. Differential Revision: https://developer.blender.org/D12602
2021-09-28 17:02:47 +02:00
void main()
{
float dash_frag_alpha = 1.0f;
if (interp_flat.dash_factor < 1.0f) {
float distance_along_line = interp_flat.line_length * interp.line_uv.x;
Geometry Nodes: Dashed lines for function flow Use dashes to represent the function flow (while keeping continuous lines for the data-flow). It is important to tell both flows apart (the data and the function flow). The sockets help with that, the noodles help this further. The "data flow" is evaluated at every single node. A user can inspect the output sockets of those nodes and have a glimpse at their values. The "function flow" (nodes) however is only evaluated in the geometry nodes. The noodles are not transporting data in the same sense of the "data flow". All that can be inspected are the attributes the functions depend on. Having this clearly communicated should help users to inspect the nodetrees, read and understand the different flows in the same tree. --- Known limitations: At the moment the dash lines are not equidistant: * It would be nice to get the "uv.x" to be resampled for the bezier curve so the dashes are equally distributed in the curve. * Using distance between the P3 and P0 instead of the real bezier curve length seems to be fine. --- Full disclaimer: Changes with that much of a visual impact tend to be controversial. So far the main feedback is that dashed lines can be associated to broken link, and that there are better ways to represent the flows (or different information that should be visually represented). I'm fully aware of that. However dashed lines are already used in the viewport and outliner to indicate (hierarchical) relation. Besides, other approaches (double-lines, having the data flow to be more distinct, ...) didn't pan out in the end (or didn't look as good as this). --- Impact in other editors: The compositor uses mostly a "data flow" nodetree, so no change is expected there. The shader nodetree is one that could but doesn't have to change its visual language. The shader nodetree uses mostly "function flow" with some "data flow" nodes. One can argue that it should be adapted to follow the same pattern as geometry nodes (with the new noodles and the diamond sockets). Oh the other hand, a shader nodetree has a single context. When a node depends on the "UV", there is only one UV at a time for the entire nodetree. So it can also be treated as a psedo "data flow" nodetree if we want to avoid too many changes in other parts of Blender. Differential Revision: https://developer.blender.org/D12602
2021-09-28 17:02:47 +02:00
/* Checking if `normalized_distance <= interp.dash_factor` is already enough for a basic
* dash, however we want to handle a nice anti-alias. */
Geometry Nodes: Dashed lines for function flow Use dashes to represent the function flow (while keeping continuous lines for the data-flow). It is important to tell both flows apart (the data and the function flow). The sockets help with that, the noodles help this further. The "data flow" is evaluated at every single node. A user can inspect the output sockets of those nodes and have a glimpse at their values. The "function flow" (nodes) however is only evaluated in the geometry nodes. The noodles are not transporting data in the same sense of the "data flow". All that can be inspected are the attributes the functions depend on. Having this clearly communicated should help users to inspect the nodetrees, read and understand the different flows in the same tree. --- Known limitations: At the moment the dash lines are not equidistant: * It would be nice to get the "uv.x" to be resampled for the bezier curve so the dashes are equally distributed in the curve. * Using distance between the P3 and P0 instead of the real bezier curve length seems to be fine. --- Full disclaimer: Changes with that much of a visual impact tend to be controversial. So far the main feedback is that dashed lines can be associated to broken link, and that there are better ways to represent the flows (or different information that should be visually represented). I'm fully aware of that. However dashed lines are already used in the viewport and outliner to indicate (hierarchical) relation. Besides, other approaches (double-lines, having the data flow to be more distinct, ...) didn't pan out in the end (or didn't look as good as this). --- Impact in other editors: The compositor uses mostly a "data flow" nodetree, so no change is expected there. The shader nodetree is one that could but doesn't have to change its visual language. The shader nodetree uses mostly "function flow" with some "data flow" nodes. One can argue that it should be adapted to follow the same pattern as geometry nodes (with the new noodles and the diamond sockets). Oh the other hand, a shader nodetree has a single context. When a node depends on the "UV", there is only one UV at a time for the entire nodetree. So it can also be treated as a psedo "data flow" nodetree if we want to avoid too many changes in other parts of Blender. Differential Revision: https://developer.blender.org/D12602
2021-09-28 17:02:47 +02:00
float dash_center = interp_flat.dash_length * interp_flat.dash_factor * 0.5f;
Geometry Nodes: Dashed lines for function flow Use dashes to represent the function flow (while keeping continuous lines for the data-flow). It is important to tell both flows apart (the data and the function flow). The sockets help with that, the noodles help this further. The "data flow" is evaluated at every single node. A user can inspect the output sockets of those nodes and have a glimpse at their values. The "function flow" (nodes) however is only evaluated in the geometry nodes. The noodles are not transporting data in the same sense of the "data flow". All that can be inspected are the attributes the functions depend on. Having this clearly communicated should help users to inspect the nodetrees, read and understand the different flows in the same tree. --- Known limitations: At the moment the dash lines are not equidistant: * It would be nice to get the "uv.x" to be resampled for the bezier curve so the dashes are equally distributed in the curve. * Using distance between the P3 and P0 instead of the real bezier curve length seems to be fine. --- Full disclaimer: Changes with that much of a visual impact tend to be controversial. So far the main feedback is that dashed lines can be associated to broken link, and that there are better ways to represent the flows (or different information that should be visually represented). I'm fully aware of that. However dashed lines are already used in the viewport and outliner to indicate (hierarchical) relation. Besides, other approaches (double-lines, having the data flow to be more distinct, ...) didn't pan out in the end (or didn't look as good as this). --- Impact in other editors: The compositor uses mostly a "data flow" nodetree, so no change is expected there. The shader nodetree is one that could but doesn't have to change its visual language. The shader nodetree uses mostly "function flow" with some "data flow" nodes. One can argue that it should be adapted to follow the same pattern as geometry nodes (with the new noodles and the diamond sockets). Oh the other hand, a shader nodetree has a single context. When a node depends on the "UV", there is only one UV at a time for the entire nodetree. So it can also be treated as a psedo "data flow" nodetree if we want to avoid too many changes in other parts of Blender. Differential Revision: https://developer.blender.org/D12602
2021-09-28 17:02:47 +02:00
float normalized_distance_triangle =
1.0f -
abs((fract((distance_along_line - dash_center) / interp_flat.dash_length)) * 2.0f - 1.0f);
float t = interp_flat.aspect * ANTIALIAS / interp_flat.dash_length;
float slope = 1.0f / (2.0f * t);
Geometry Nodes: Dashed lines for function flow Use dashes to represent the function flow (while keeping continuous lines for the data-flow). It is important to tell both flows apart (the data and the function flow). The sockets help with that, the noodles help this further. The "data flow" is evaluated at every single node. A user can inspect the output sockets of those nodes and have a glimpse at their values. The "function flow" (nodes) however is only evaluated in the geometry nodes. The noodles are not transporting data in the same sense of the "data flow". All that can be inspected are the attributes the functions depend on. Having this clearly communicated should help users to inspect the nodetrees, read and understand the different flows in the same tree. --- Known limitations: At the moment the dash lines are not equidistant: * It would be nice to get the "uv.x" to be resampled for the bezier curve so the dashes are equally distributed in the curve. * Using distance between the P3 and P0 instead of the real bezier curve length seems to be fine. --- Full disclaimer: Changes with that much of a visual impact tend to be controversial. So far the main feedback is that dashed lines can be associated to broken link, and that there are better ways to represent the flows (or different information that should be visually represented). I'm fully aware of that. However dashed lines are already used in the viewport and outliner to indicate (hierarchical) relation. Besides, other approaches (double-lines, having the data flow to be more distinct, ...) didn't pan out in the end (or didn't look as good as this). --- Impact in other editors: The compositor uses mostly a "data flow" nodetree, so no change is expected there. The shader nodetree is one that could but doesn't have to change its visual language. The shader nodetree uses mostly "function flow" with some "data flow" nodes. One can argue that it should be adapted to follow the same pattern as geometry nodes (with the new noodles and the diamond sockets). Oh the other hand, a shader nodetree has a single context. When a node depends on the "UV", there is only one UV at a time for the entire nodetree. So it can also be treated as a psedo "data flow" nodetree if we want to avoid too many changes in other parts of Blender. Differential Revision: https://developer.blender.org/D12602
2021-09-28 17:02:47 +02:00
float unclamped_alpha = 1.0f -
slope * (normalized_distance_triangle - interp_flat.dash_factor + t);
float alpha = max(interp_flat.dash_alpha, min(unclamped_alpha, 1.0f));
Geometry Nodes: Dashed lines for function flow Use dashes to represent the function flow (while keeping continuous lines for the data-flow). It is important to tell both flows apart (the data and the function flow). The sockets help with that, the noodles help this further. The "data flow" is evaluated at every single node. A user can inspect the output sockets of those nodes and have a glimpse at their values. The "function flow" (nodes) however is only evaluated in the geometry nodes. The noodles are not transporting data in the same sense of the "data flow". All that can be inspected are the attributes the functions depend on. Having this clearly communicated should help users to inspect the nodetrees, read and understand the different flows in the same tree. --- Known limitations: At the moment the dash lines are not equidistant: * It would be nice to get the "uv.x" to be resampled for the bezier curve so the dashes are equally distributed in the curve. * Using distance between the P3 and P0 instead of the real bezier curve length seems to be fine. --- Full disclaimer: Changes with that much of a visual impact tend to be controversial. So far the main feedback is that dashed lines can be associated to broken link, and that there are better ways to represent the flows (or different information that should be visually represented). I'm fully aware of that. However dashed lines are already used in the viewport and outliner to indicate (hierarchical) relation. Besides, other approaches (double-lines, having the data flow to be more distinct, ...) didn't pan out in the end (or didn't look as good as this). --- Impact in other editors: The compositor uses mostly a "data flow" nodetree, so no change is expected there. The shader nodetree is one that could but doesn't have to change its visual language. The shader nodetree uses mostly "function flow" with some "data flow" nodes. One can argue that it should be adapted to follow the same pattern as geometry nodes (with the new noodles and the diamond sockets). Oh the other hand, a shader nodetree has a single context. When a node depends on the "UV", there is only one UV at a time for the entire nodetree. So it can also be treated as a psedo "data flow" nodetree if we want to avoid too many changes in other parts of Blender. Differential Revision: https://developer.blender.org/D12602
2021-09-28 17:02:47 +02:00
dash_frag_alpha = alpha;
Geometry Nodes: Dashed lines for function flow Use dashes to represent the function flow (while keeping continuous lines for the data-flow). It is important to tell both flows apart (the data and the function flow). The sockets help with that, the noodles help this further. The "data flow" is evaluated at every single node. A user can inspect the output sockets of those nodes and have a glimpse at their values. The "function flow" (nodes) however is only evaluated in the geometry nodes. The noodles are not transporting data in the same sense of the "data flow". All that can be inspected are the attributes the functions depend on. Having this clearly communicated should help users to inspect the nodetrees, read and understand the different flows in the same tree. --- Known limitations: At the moment the dash lines are not equidistant: * It would be nice to get the "uv.x" to be resampled for the bezier curve so the dashes are equally distributed in the curve. * Using distance between the P3 and P0 instead of the real bezier curve length seems to be fine. --- Full disclaimer: Changes with that much of a visual impact tend to be controversial. So far the main feedback is that dashed lines can be associated to broken link, and that there are better ways to represent the flows (or different information that should be visually represented). I'm fully aware of that. However dashed lines are already used in the viewport and outliner to indicate (hierarchical) relation. Besides, other approaches (double-lines, having the data flow to be more distinct, ...) didn't pan out in the end (or didn't look as good as this). --- Impact in other editors: The compositor uses mostly a "data flow" nodetree, so no change is expected there. The shader nodetree is one that could but doesn't have to change its visual language. The shader nodetree uses mostly "function flow" with some "data flow" nodes. One can argue that it should be adapted to follow the same pattern as geometry nodes (with the new noodles and the diamond sockets). Oh the other hand, a shader nodetree has a single context. When a node depends on the "UV", there is only one UV at a time for the entire nodetree. So it can also be treated as a psedo "data flow" nodetree if we want to avoid too many changes in other parts of Blender. Differential Revision: https://developer.blender.org/D12602
2021-09-28 17:02:47 +02:00
}
if (interp_flat.is_main_line == 0) {
out_color = interp.final_color;
out_color.a *= get_line_alpha(0.5f, 0.5f) * dash_frag_alpha;
return;
}
if (interp_flat.has_back_link == 0) {
out_color = interp.final_color;
out_color.a *= get_line_alpha(0.5f, 0.5f) * dash_frag_alpha;
Geometry Nodes: support attaching gizmos to input values This adds support for attaching gizmos for input values. The goal is to make it easier for users to set input values intuitively in the 3D viewport. We went through multiple different possible designs until we settled on the one implemented here. We picked it for it's flexibility and ease of use when using geometry node assets. The core principle in the design is that **gizmos are attached to existing input values instead of being the input value themselves**. This actually fits the existing concept of gizmos in Blender well, but may be a bit unintutitive in a node setup at first. The attachment is done using links in the node editor. The most basic usage of the node is to link a Value node to the new Linear Gizmo node. This attaches the gizmo to the input value and allows you to change it from the 3D view. The attachment is indicated by the gizmo icon in the sockets which are controlled by a gizmo as well as the back-link (notice the double link) when the gizmo is active. The core principle makes it straight forward to control the same node setup from the 3D view with gizmos, or by manually changing input values, or by driving the input values procedurally. If the input value is controlled indirectly by other inputs, it's often possible to **automatically propagate** the gizmo to the actual input. Backpropagation does not work for all nodes, although more nodes can be supported over time. This patch adds the first three gizmo nodes which cover common use cases: * **Linear Gizmo**: Creates a gizmo that controls a float or integer value using a linear movement of e.g. an arrow in the 3D viewport. * **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be rotated to change the attached angle input. * **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale. In the future, more built-in gizmos and potentially the ability for custom gizmos could be added. All gizmo nodes have a **Transform** geometry output. Using it is optional but it is recommended when the gizmo is used to control inputs that affect a geometry. When it is used, Blender will automatically transform the gizmos together with the geometry that they control. To achieve this, the output should be merged with the generated geometry using the *Join Geometry* node. The data contained in *Transform* output is not visible geometry, but just internal information that helps Blender to give a better user experience when using gizmos. The gizmo nodes have a multi-input socket. This allows **controlling multiple values** with the same gizmo. Only a small set of **gizmo shapes** is supported initially. It might be extended in the future but one goal is to give the gizmos used by different node group assets a familiar look and feel. A similar constraint exists for **colors**. Currently, one can choose from a fixed set of colors which can be modified in the theme settings. The set of **visible gizmos** is determined by a multiple factors because it's not really feasible to show all possible gizmos at all times. To see any of the geometry nodes gizmos, the "Active Modifier" option has to be enabled in the "Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of the following is true: * The gizmo controls an input of the active modifier of the active object. * The gizmo controls a value in a selected node in an open node editor. * The gizmo controls a pinned value in an open node editor. Pinning works by clicking the gizmo icon next to the value. Pull Request: https://projects.blender.org/blender/blender/pulls/112677
2024-07-10 16:18:47 +02:00
}
else {
/* Draw two links right next to each other, the main link and the back-link. */
float4 main_link_color = interp.final_color;
main_link_color.a *= get_line_alpha(0.75f, 0.3f);
Geometry Nodes: support attaching gizmos to input values This adds support for attaching gizmos for input values. The goal is to make it easier for users to set input values intuitively in the 3D viewport. We went through multiple different possible designs until we settled on the one implemented here. We picked it for it's flexibility and ease of use when using geometry node assets. The core principle in the design is that **gizmos are attached to existing input values instead of being the input value themselves**. This actually fits the existing concept of gizmos in Blender well, but may be a bit unintutitive in a node setup at first. The attachment is done using links in the node editor. The most basic usage of the node is to link a Value node to the new Linear Gizmo node. This attaches the gizmo to the input value and allows you to change it from the 3D view. The attachment is indicated by the gizmo icon in the sockets which are controlled by a gizmo as well as the back-link (notice the double link) when the gizmo is active. The core principle makes it straight forward to control the same node setup from the 3D view with gizmos, or by manually changing input values, or by driving the input values procedurally. If the input value is controlled indirectly by other inputs, it's often possible to **automatically propagate** the gizmo to the actual input. Backpropagation does not work for all nodes, although more nodes can be supported over time. This patch adds the first three gizmo nodes which cover common use cases: * **Linear Gizmo**: Creates a gizmo that controls a float or integer value using a linear movement of e.g. an arrow in the 3D viewport. * **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be rotated to change the attached angle input. * **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale. In the future, more built-in gizmos and potentially the ability for custom gizmos could be added. All gizmo nodes have a **Transform** geometry output. Using it is optional but it is recommended when the gizmo is used to control inputs that affect a geometry. When it is used, Blender will automatically transform the gizmos together with the geometry that they control. To achieve this, the output should be merged with the generated geometry using the *Join Geometry* node. The data contained in *Transform* output is not visible geometry, but just internal information that helps Blender to give a better user experience when using gizmos. The gizmo nodes have a multi-input socket. This allows **controlling multiple values** with the same gizmo. Only a small set of **gizmo shapes** is supported initially. It might be extended in the future but one goal is to give the gizmos used by different node group assets a familiar look and feel. A similar constraint exists for **colors**. Currently, one can choose from a fixed set of colors which can be modified in the theme settings. The set of **visible gizmos** is determined by a multiple factors because it's not really feasible to show all possible gizmos at all times. To see any of the geometry nodes gizmos, the "Active Modifier" option has to be enabled in the "Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of the following is true: * The gizmo controls an input of the active modifier of the active object. * The gizmo controls a value in a selected node in an open node editor. * The gizmo controls a pinned value in an open node editor. Pinning works by clicking the gizmo icon next to the value. Pull Request: https://projects.blender.org/blender/blender/pulls/112677
2024-07-10 16:18:47 +02:00
float4 back_link_color = float4(float3(0.8f), 1.0f);
back_link_color.a *= get_line_alpha(0.2f, 0.25f);
Geometry Nodes: support attaching gizmos to input values This adds support for attaching gizmos for input values. The goal is to make it easier for users to set input values intuitively in the 3D viewport. We went through multiple different possible designs until we settled on the one implemented here. We picked it for it's flexibility and ease of use when using geometry node assets. The core principle in the design is that **gizmos are attached to existing input values instead of being the input value themselves**. This actually fits the existing concept of gizmos in Blender well, but may be a bit unintutitive in a node setup at first. The attachment is done using links in the node editor. The most basic usage of the node is to link a Value node to the new Linear Gizmo node. This attaches the gizmo to the input value and allows you to change it from the 3D view. The attachment is indicated by the gizmo icon in the sockets which are controlled by a gizmo as well as the back-link (notice the double link) when the gizmo is active. The core principle makes it straight forward to control the same node setup from the 3D view with gizmos, or by manually changing input values, or by driving the input values procedurally. If the input value is controlled indirectly by other inputs, it's often possible to **automatically propagate** the gizmo to the actual input. Backpropagation does not work for all nodes, although more nodes can be supported over time. This patch adds the first three gizmo nodes which cover common use cases: * **Linear Gizmo**: Creates a gizmo that controls a float or integer value using a linear movement of e.g. an arrow in the 3D viewport. * **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be rotated to change the attached angle input. * **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale. In the future, more built-in gizmos and potentially the ability for custom gizmos could be added. All gizmo nodes have a **Transform** geometry output. Using it is optional but it is recommended when the gizmo is used to control inputs that affect a geometry. When it is used, Blender will automatically transform the gizmos together with the geometry that they control. To achieve this, the output should be merged with the generated geometry using the *Join Geometry* node. The data contained in *Transform* output is not visible geometry, but just internal information that helps Blender to give a better user experience when using gizmos. The gizmo nodes have a multi-input socket. This allows **controlling multiple values** with the same gizmo. Only a small set of **gizmo shapes** is supported initially. It might be extended in the future but one goal is to give the gizmos used by different node group assets a familiar look and feel. A similar constraint exists for **colors**. Currently, one can choose from a fixed set of colors which can be modified in the theme settings. The set of **visible gizmos** is determined by a multiple factors because it's not really feasible to show all possible gizmos at all times. To see any of the geometry nodes gizmos, the "Active Modifier" option has to be enabled in the "Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of the following is true: * The gizmo controls an input of the active modifier of the active object. * The gizmo controls a value in a selected node in an open node editor. * The gizmo controls a pinned value in an open node editor. Pinning works by clicking the gizmo icon next to the value. Pull Request: https://projects.blender.org/blender/blender/pulls/112677
2024-07-10 16:18:47 +02:00
/* Combine both links. */
out_color.rgb = main_link_color.rgb * main_link_color.a +
Geometry Nodes: support attaching gizmos to input values This adds support for attaching gizmos for input values. The goal is to make it easier for users to set input values intuitively in the 3D viewport. We went through multiple different possible designs until we settled on the one implemented here. We picked it for it's flexibility and ease of use when using geometry node assets. The core principle in the design is that **gizmos are attached to existing input values instead of being the input value themselves**. This actually fits the existing concept of gizmos in Blender well, but may be a bit unintutitive in a node setup at first. The attachment is done using links in the node editor. The most basic usage of the node is to link a Value node to the new Linear Gizmo node. This attaches the gizmo to the input value and allows you to change it from the 3D view. The attachment is indicated by the gizmo icon in the sockets which are controlled by a gizmo as well as the back-link (notice the double link) when the gizmo is active. The core principle makes it straight forward to control the same node setup from the 3D view with gizmos, or by manually changing input values, or by driving the input values procedurally. If the input value is controlled indirectly by other inputs, it's often possible to **automatically propagate** the gizmo to the actual input. Backpropagation does not work for all nodes, although more nodes can be supported over time. This patch adds the first three gizmo nodes which cover common use cases: * **Linear Gizmo**: Creates a gizmo that controls a float or integer value using a linear movement of e.g. an arrow in the 3D viewport. * **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be rotated to change the attached angle input. * **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale. In the future, more built-in gizmos and potentially the ability for custom gizmos could be added. All gizmo nodes have a **Transform** geometry output. Using it is optional but it is recommended when the gizmo is used to control inputs that affect a geometry. When it is used, Blender will automatically transform the gizmos together with the geometry that they control. To achieve this, the output should be merged with the generated geometry using the *Join Geometry* node. The data contained in *Transform* output is not visible geometry, but just internal information that helps Blender to give a better user experience when using gizmos. The gizmo nodes have a multi-input socket. This allows **controlling multiple values** with the same gizmo. Only a small set of **gizmo shapes** is supported initially. It might be extended in the future but one goal is to give the gizmos used by different node group assets a familiar look and feel. A similar constraint exists for **colors**. Currently, one can choose from a fixed set of colors which can be modified in the theme settings. The set of **visible gizmos** is determined by a multiple factors because it's not really feasible to show all possible gizmos at all times. To see any of the geometry nodes gizmos, the "Active Modifier" option has to be enabled in the "Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of the following is true: * The gizmo controls an input of the active modifier of the active object. * The gizmo controls a value in a selected node in an open node editor. * The gizmo controls a pinned value in an open node editor. Pinning works by clicking the gizmo icon next to the value. Pull Request: https://projects.blender.org/blender/blender/pulls/112677
2024-07-10 16:18:47 +02:00
back_link_color.rgb * back_link_color.a;
out_color.a = main_link_color.a * dash_frag_alpha + back_link_color.a;
Geometry Nodes: support attaching gizmos to input values This adds support for attaching gizmos for input values. The goal is to make it easier for users to set input values intuitively in the 3D viewport. We went through multiple different possible designs until we settled on the one implemented here. We picked it for it's flexibility and ease of use when using geometry node assets. The core principle in the design is that **gizmos are attached to existing input values instead of being the input value themselves**. This actually fits the existing concept of gizmos in Blender well, but may be a bit unintutitive in a node setup at first. The attachment is done using links in the node editor. The most basic usage of the node is to link a Value node to the new Linear Gizmo node. This attaches the gizmo to the input value and allows you to change it from the 3D view. The attachment is indicated by the gizmo icon in the sockets which are controlled by a gizmo as well as the back-link (notice the double link) when the gizmo is active. The core principle makes it straight forward to control the same node setup from the 3D view with gizmos, or by manually changing input values, or by driving the input values procedurally. If the input value is controlled indirectly by other inputs, it's often possible to **automatically propagate** the gizmo to the actual input. Backpropagation does not work for all nodes, although more nodes can be supported over time. This patch adds the first three gizmo nodes which cover common use cases: * **Linear Gizmo**: Creates a gizmo that controls a float or integer value using a linear movement of e.g. an arrow in the 3D viewport. * **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be rotated to change the attached angle input. * **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale. In the future, more built-in gizmos and potentially the ability for custom gizmos could be added. All gizmo nodes have a **Transform** geometry output. Using it is optional but it is recommended when the gizmo is used to control inputs that affect a geometry. When it is used, Blender will automatically transform the gizmos together with the geometry that they control. To achieve this, the output should be merged with the generated geometry using the *Join Geometry* node. The data contained in *Transform* output is not visible geometry, but just internal information that helps Blender to give a better user experience when using gizmos. The gizmo nodes have a multi-input socket. This allows **controlling multiple values** with the same gizmo. Only a small set of **gizmo shapes** is supported initially. It might be extended in the future but one goal is to give the gizmos used by different node group assets a familiar look and feel. A similar constraint exists for **colors**. Currently, one can choose from a fixed set of colors which can be modified in the theme settings. The set of **visible gizmos** is determined by a multiple factors because it's not really feasible to show all possible gizmos at all times. To see any of the geometry nodes gizmos, the "Active Modifier" option has to be enabled in the "Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of the following is true: * The gizmo controls an input of the active modifier of the active object. * The gizmo controls a value in a selected node in an open node editor. * The gizmo controls a pinned value in an open node editor. Pinning works by clicking the gizmo icon next to the value. Pull Request: https://projects.blender.org/blender/blender/pulls/112677
2024-07-10 16:18:47 +02:00
}
}