2021-07-12 Geometry Nodes Sub-Module Meetings



  • Planning for the week
  • Design discussion as needed

Meeting Notes

  • Discussion on “Geometry Expander” proposal
    • Hans’ feedback
      • Attribute interpolation is an intrisic part of geometry nodes. To to have to handle it explicitly is a big down-side.
      • The visual cues for the new elements are hard to grasp (the +, -).
      • For topology change nodetrees, the tree still becomes extremely linear.
      • More cumbersome:
        • Harder to tweak.
        • Harder to read the tree.
        • Slower to build the tree.
  • Product Demo.
    • 3.0 will need an actual face corner domain icon.
    • There is something about IDProperties to discuss with Bastien
  • Geometry Nodes: Curve Fill
    • Projection direction
      • Should the normal for each fill group be automatic? Erik proposed this. Or a single “projection direction” per node. A “Split” or equivalent could be used when more than one directions are necessary.
        • (note from Hans writing notes: I’m not sure we had a conclusion about this, but I think the preference was a single direction input for the whole node)
    • “group_index” input attribute for limiting fill
      • Potentially an important piece for optimization, though it also may be a useful option.
        • For optimization, an alternative is limiting with bounding boxes, though that may be more expensive.
      • In the patch it is hardcoded input, which is useful when other nodes generate lots of curve groups (separate characters text nodes).
      • If it was not hard coded, users would have to manually pass the attribute for what is in most cases and optimization.
      • Other options:
        • Filling the string field with a default (only works with string workflows).
        • Making “group_index” an optional built-in attribute on the spline domain.
      • Conclusion: Bounding box buckets should be used as an optimization at first. If that is too slow or doesn’t work out, then we can consider the “group_index” solution.
  • Geometry Nodes: Catenary Curve Node
    • It’s a common use case, but a very specific node.
      • Yes, we want it, it seems useful as a building block, and there were no concerns about it being two specific
    • Should the use case be handled in a more general way?
      • There were no concerns about it being too specific.
    • The direction should be adjustible, and there should be a choice to vary the direction per-segment, just like the tension.
    • If it is possible mathematically to represent the shape with bezier splines and handles, that would be preferrable. Maybe with a control point in the middle if that is necessary.
  • Add more warnings to Geometry Nodes
    • These are nice to have, but they shouldn’t appear in the terminal or the modifier, since often it is valid, at least temporarily, to have inputs outside of the standard range.
      • They should use the “Info” node warning type, and it should be verified that the info warnings only appear in the node header.
  • Geometry Nodes: Add alternative distribution options to the Attribute Randomize node
    • This needs another check, from Simon probably.
      • The options seem good, but Simon will check it again.