2022-1-10 - 2022-01-14 Geometry Nodes Sub-Module Meetings

Meetings
,
1

Info

Developers or artists interested in contributing are welcome to join at the links below.

Week of 2022-1-10

  • D12035: Geometry Nodes: Add Easing Function Node
    • The inputs and functionality are very similar to the map range node.
    • Conceptually the node feels different though, and there are also in and out options, which probably makes it worth adding.
    • The clamp option could be named differently, since it clamps the input rather than the output.
    • Or the clamp option can be removed, because there doesn’t seem to be a strong use case for it and the behavior seems expected.
    • There could be more settings for the sinusoidal modes:
  • D13764: Function Node: Add Integer Math node
    • It’s great to avoid conversions, both conceptually and for performance reasons.
    • GCD and LCM are useful and take advantage of the integer data type.
    • There doesn’t seem to be a strong reason to add decrement and increment
    • “Right shift” and “Left shift” just multiply and divide by 2.
    • There also doesn’t seem to be a strong argument for the bitwise operations, and it’s a implementation detail we don’t usually expose.
      • One reason is to create “flags” for various features of a node tree. However we should try to design that in a more user-friendly way (with booleans or enums).
  • D13550: Extending vector math node
    • “Negate” seems useful since it’s such a common operation.
    • Naming for the “One Over” mode is a bit awkward. But there was no agreement that another option like “Reciprical” or “Inverse” is better.
    • Interpolation options feel redundant with the mix node that’s being designed now, especially when we have map range, easing, and the mix node.
      • Full words shopuld be used “Lerp → Interpolate”
      • “Inverse Lerp” seems more confusing than helpful.
        • All of the input names are the same for “Inverse Lerp”.
    • Generally the vector math operations seem excessive. We agreed that the vector math node should work on vectors conceptually, rather than doing all of the float math operations on a group of three floats. The point is a bit subtle and not always followed exactly, but there was agreement that the node provided too many options.
    • The following are the operations we agreed were worth adding to the vector math node:
      • “Negate”: This is a common operation, there was no objection to this.
      • “Angle”: Conceptually works on an XYZ vector, and a useful formula.
    • “Midpoint” is handled by the mix node (the default factor is 0.5)
    • We already have the compare node for the comparison operations.
    • Generally we want to move to an operation based workflow rather than a data type based workflow. That should be addressed sooner rather than later, especially because it resolves the design issues these math node patches bring up. Rather than adding operations that we will want to replace, we could fix the actual issue
  • D13640: Add Primitive Arc
    • (Charlie) This continues one of Johnny’s older patches for the Arc primitive.
    • “Invert Arc” might be a more intuitive and more consistent than “Shortest Arc”, and that would even work in radius mode
    • “Radius” can be the default mode, since it’s a bit easier to understand and much smaller
  • D13577: Add Range comparison to compare node
    • This looks useful, it’s usually much easier to control this than an equals operation with a range.
    • Should the selection be exclusive or inclusive? “Between” sounds exlusive. “In Range” is suggested as an alternative that’s a bit more descriptive.
    • The implementation of the “between” and “not between” should not be duplicated.
  • D12792: Add Random value to object info node
    • (Charlie) Erindale has mentioned this in his most recent tutorial. This patch was originally rejected but I’ve reopened with simplified patch. This solves the problem of having an automatic random number when duplicating objects with the same GN tree without manually inputting a group input seed. There may be better ways to do this.
    • The self object could be a specific input node.
    • Generally there was agreement that this is an important use case, but outputting a different value inside a node group just depending on where it’s used was controversial, since node groups should have predictable behavior.
    • A “random ID” could be a value on each object that is randomized when it’s duplicated. Otherwise the node input giving a random uncontrollable value breaks the idea of a node group a bit.
      • That would help solve the problem mentioned above, where the value isn’t controllable or visible.
    • It’s not totally clear if there should be a new node to get the random ID from an object or if it should be added to the object info node.
      • The object info node might become cluttered if we add to it in situations like this, where it’s currently a more “narrow” use case to get a geometry and its transform.
    • Providing access to custom properties is a related feature, but it probably shouldn’t be necessary to use them for this relatively simple behavior.
  • T92588: Mix Node
    • (Charlie) I have created a couple of patches in response to this task. One consideration is non-uniform mixing. With a single factor socket this is not possible.
    • Expose “Clamp” as input socket. Conceptually it feels less like an input, but it’s good to have all inputs available as sockets unless there is a strong reason not to.
    • “Clamp” can be called “Clamp Factor” to clarify that the factor is clamped rather than the output.
    • “A” and “B” work for naming
    • The factor should be a slider and should be 0.5 by default
    • Specify default link socket (is_default_link_socket).
    • Having two mix nodes (“Mix” and “MixRGB”) might be confusing. There are a few options:
      • Add the data type to the label of the new node “Mix Float”
      • Merge the existing MixRGB node with its options into the new mix node, and expose the options only for the color mode. (Remove the MixRGB node and version it to the mix node).
        • However, there are two different clamp options. How would that behavior be preserved?
          • Refactor the clamp node to work on different types.
          • Keep the separate clamp output option, but just for colors.
          • Either way, the clamp node should support multiple data types.
  • D13693: Geometry Nodes: Rename String To Curves socket
    • Eventually there could be some different way to see instances, like an overlay option. But it looks like this can be helpful in some situations.
  • Propagating selections in the Extrude node.
    • We thought there might be problems with propogating some selections, but interpolating with different domains seems to make it work fine.
  • Legacy behavior of Realize Instances node.
    • The node has a hidden legacy option that can be confusing when loading an old file in a new version and expecting it to behave differently.
    • Show a warning in the node that it’s using legacy behavior.
    • The option only has subtle effects in one file that we know of. It could be removed eventually, but not for a smaller release like 3.1.
  • T93817: Convert Triangulate node input to a selection
    • Only having the selection seems best.
    • Seems to be uncommon to triangulate only ngons.
  • T94851: Fields UI: Differentiate between dynamic attribute fields and anonymous attributes
    • Node Groups have to derive the information of what to display from context but have to show consistent interface.
    • When a geometry node does not have a geometry input connected no field inputs should be greyed out.
  • Field at Index, Field at Position node proposals
    • Field at Index solves a common problem where one has to connect the context geometry to a field, though that should be unnecessary. The names could still use some discussion, but the concept is straightforward, since it just shuffles data after it’s evaluated.
      • For the naming, “Field at Index” was preferred.
        • “Field” is a word that people working with geometry nodes know anyway, we use it in tooltips, and in the documentation. It’s not clear why we would hide the word at this point.
    • Field at Position could allow getting different outputs from fields that just depend on position. This would be useful for curl noise or finding derivatives of fields. However, it could be solved more generally by allowing overriting any attribute. It didn’t seem that intuitive that it only changed the output of the position node but nothing else.
  • Naming: Source vs. Target in transfer nodes.
    • Proximity, Raycast: Target still makes sense.
    • Transfer: Target is very confusing, this will be helpful.
  • Set of input nodes: Edge Vertex, Edge Face, Face Vertex, Face Edge
    • D13827: Geometry Nodes: Experimental new Face Vertex/Edge node
      • “Weight” might be more clear if it was called “Order Weight”
      • “Index” could be clearer, maybe “Pick Index”
      • Combining them into a “Face Element” node might be preferable if we want to group the outputs “by concept”.
        • Discoverability is a concern as menus get larger, we may want to use deeper menus to address this. Since the main use case of the menu is seeing which nodes are available, deeper menus shouldn’t have much of a cost.
      • These are much easier to explain and understand when the extrude node is available.
  • Johnny’s Patches - Continue with better design, Finalize, or Abandon?
    • Accumulate Node - Grouped Index D13716
      • The patch should be renamed, but it looks good.
    • Edge Angle Node - Add Signed Angle Output D13796
      • Seeing the diagram for how the sign is computed would be very helpful.
      • Usually people will probably want the signed output, but since it is more expensive and not always necessary, it should make sense to have two outputs.
    • Mesh Island Node - Additional Outputs D13700
      • Index could be renamed to “Island Index”.
      • There doesn’t seem to be any strong reason to add these yet, though they do make sense. The accumulate node should make this possible for now.
      • We could revisit the patch when it’s possible to compute multiple field outputs from a node at the same time, and there are more use cases for the node.
      • The “Island Count” output seems more obvious than the other s, that could be added now.
    • Curve Handle Position Input Node - Relative Mode D12947
      • This one just needs code review.
    • Add Selection to Triangulate Node D13804
      • Just needs code review
  • Charlie’s Stuff
    • Request another review for Random Spherical Distribution node D12746. Accepted by Simon.
    • Mix Node D13749
      • (Charlie) Does this resolve the questions from Tuesday. Clamp socket is not currenly supported on shader nodes so it is added as checkbox. The new node supports color blending and input factor clamping. Accepted by Simon.
      • There is agreement on that here, it just needs versioning and code review.
  • Set Handle Type Node: Both handles by default
11 Likes
2

Geometric nodes are currently more process-oriented, mathematical functions are more brain-wasting, will more object-oriented elements be added in the future?