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
131 lines
3.3 KiB
GLSL
131 lines
3.3 KiB
GLSL
/**
|
|
* 2D Quadratic Bezier thick line drawing
|
|
*/
|
|
|
|
#define MID_VERTEX 65
|
|
|
|
/* u is position along the curve, defining the tangent space.
|
|
* v is "signed" distance (compressed to [0..1] range) from the pos in expand direction */
|
|
in vec2 uv;
|
|
in vec2 pos; /* verts position in the curve tangent space */
|
|
in vec2 expand;
|
|
|
|
#ifdef USE_INSTANCE
|
|
/* Instance attrs. */
|
|
in vec2 P0;
|
|
in vec2 P1;
|
|
in vec2 P2;
|
|
in vec2 P3;
|
|
in ivec4 colid_doarrow;
|
|
in ivec2 domuted;
|
|
in float dim_factor;
|
|
in float thickness;
|
|
in float dash_factor;
|
|
|
|
uniform vec4 colors[6];
|
|
|
|
# define colStart colors[colid_doarrow[0]]
|
|
# define colEnd colors[colid_doarrow[1]]
|
|
# define colShadow colors[colid_doarrow[2]]
|
|
# define doArrow (colid_doarrow[3] != 0)
|
|
# define doMuted (domuted[0] != 0)
|
|
|
|
#else
|
|
/* Single curve drawcall, use uniform. */
|
|
uniform vec2 bezierPts[4];
|
|
|
|
# define P0 bezierPts[0]
|
|
# define P1 bezierPts[1]
|
|
# define P2 bezierPts[2]
|
|
# define P3 bezierPts[3]
|
|
|
|
uniform vec4 colors[3];
|
|
uniform bool doArrow;
|
|
uniform bool doMuted;
|
|
uniform float dim_factor;
|
|
uniform float thickness;
|
|
uniform float dash_factor;
|
|
|
|
# define colShadow colors[0]
|
|
# define colStart colors[1]
|
|
# define colEnd colors[2]
|
|
|
|
#endif
|
|
|
|
uniform float expandSize;
|
|
uniform float arrowSize;
|
|
uniform mat4 ModelViewProjectionMatrix;
|
|
|
|
out float colorGradient;
|
|
out vec4 finalColor;
|
|
out float lineU;
|
|
flat out float lineLength;
|
|
flat out float dashFactor;
|
|
flat out int isMainLine;
|
|
|
|
void main(void)
|
|
{
|
|
/* Parameters for the dashed line. */
|
|
isMainLine = expand.y != 1.0 ? 0 : 1;
|
|
dashFactor = dash_factor;
|
|
/* Approximate line length, no need for real bezier length calculation. */
|
|
lineLength = distance(P0, P3);
|
|
/* TODO: Incorrect U, this leads to non-uniform dash distribution. */
|
|
lineU = uv.x;
|
|
|
|
float t = uv.x;
|
|
float t2 = t * t;
|
|
float t2_3 = 3.0 * t2;
|
|
float one_minus_t = 1.0 - t;
|
|
float one_minus_t2 = one_minus_t * one_minus_t;
|
|
float one_minus_t2_3 = 3.0 * one_minus_t2;
|
|
|
|
vec2 point = (P0 * one_minus_t2 * one_minus_t + P1 * one_minus_t2_3 * t +
|
|
P2 * t2_3 * one_minus_t + P3 * t2 * t);
|
|
|
|
vec2 tangent = ((P1 - P0) * one_minus_t2_3 + (P2 - P1) * 6.0 * (t - t2) + (P3 - P2) * t2_3);
|
|
|
|
/* tangent space at t */
|
|
tangent = normalize(tangent);
|
|
vec2 normal = tangent.yx * vec2(-1.0, 1.0);
|
|
|
|
/* Position vertex on the curve tangent space */
|
|
point += (pos.x * tangent + pos.y * normal) * arrowSize;
|
|
|
|
gl_Position = ModelViewProjectionMatrix * vec4(point, 0.0, 1.0);
|
|
|
|
vec2 exp_axis = expand.x * tangent + expand.y * normal;
|
|
|
|
/* rotate & scale the expand axis */
|
|
exp_axis = ModelViewProjectionMatrix[0].xy * exp_axis.xx +
|
|
ModelViewProjectionMatrix[1].xy * exp_axis.yy;
|
|
|
|
float expand_dist = (uv.y * 2.0 - 1.0);
|
|
colorGradient = expand_dist;
|
|
|
|
if (gl_VertexID < MID_VERTEX) {
|
|
/* Shadow pass */
|
|
finalColor = colShadow;
|
|
}
|
|
else {
|
|
/* Second pass */
|
|
finalColor = mix(colStart, colEnd, uv.x);
|
|
expand_dist *= 0.5;
|
|
if (doMuted) {
|
|
finalColor[3] = 0.65;
|
|
}
|
|
}
|
|
|
|
finalColor[3] *= dim_factor;
|
|
|
|
/* Expand into a line */
|
|
gl_Position.xy += exp_axis * expandSize * expand_dist * thickness;
|
|
|
|
/* If the link is not muted or is not a reroute arrow the points are squashed to the center of
|
|
* the line. Magic numbers are defined in drawnode.c */
|
|
if ((expand.x == 1.0 && !doMuted) ||
|
|
(expand.y != 1.0 && (pos.x < 0.70 || pos.x > 0.71) && !doArrow)) {
|
|
gl_Position.xy *= 0.0;
|
|
}
|
|
}
|