2022-11-15 Geometry Nodes sub-module meeting

[HooglyBoogly]

Meeting time: 15:00 CEST (Your local time: 2022-11-15T14:00:00Z).

Links

• Video Call
• Calendar
• Workboard
• Patches
• Chat Channel

Present

• Brady Johnston
• Chris Clyne
• Dalai Felinto
• Daniel Bystedt
• Eric
• Erindale Woodford
• Hans Goudey
• Iliya Katueshenock
• Jacques Luckes
• Jarrett Johnson
• Lukas Tönne
• Martijn Versteegh
• Miro Horvath
• Wannes Malfait
• Zhen Dai

Since the Last Meeting

• Post BCON22 Workshop
• Add node group assets in add menu
• New features in curve nodes
  • Trim curve node selection input and corrections
  • Add index and value inputs to sample curve node
• A few small performance improvements
  • Use templates for disjoint set data structure
  • Improve socket node lookup performance

General Discussion

• Jacques presented module planning for Blender 3.5
  • Detailed list (to be moved to tasks)
  • Main Targets
    • Simulation
      • It needs cache on disk and in memory to be handled as well.
    • Procedural hair nodes (and groups)
      • Fully destructive workflow for now.
      • “Edit Geometry” node to mix procedural and destructive pipelines for later.
      • Targets nodes still need to be validated.
    • Import nodes
      • Miro mentions using drag and drop to add a file to a node network.
      • A point cloud format would be helpful as well. Alembic supports point clouds.
      • There is still uncertainty about what formats would be supported in the long term, so for now the goal is not to extensively support all formats, but to focus on the well established interchangeable formats:
        • CSV
        • Alembic
    • Attribute editing in mesh edit mode
      • This wouldn’t apply to curves yet, since the legacy curve type doesn’t support attributes and the new curves don’t have a proper edit mode quite yet.
    • Reorganizing the add menu
    • Field context Inspection
  • Bonus Targets
    • Dynamic Socket Types
    • Spreadsheet Editing
    • Capture Attribute Gesture
    • Comments

Patch Review & Decision Time

• Reminder for everyone to please include screenshot in the patches.
• D16394: Geometry Node: Collection Info: Change output socket name to Instances
  • It was generally agreed this was an improvement.
• D16396: Geometry Nodes: Rename Transform node to Transform Geometry
  • People generally preferred this as well. The internal identifier should remain the same though, so we don’t break the Python API for such a common node.
• D14281: Geometry Nodes: Add “Capsule” geometry primitive
  • There was discussion about whether this should be a node group (possibly shipped with Blender) or a built in node.
  • For primitives, besides the benefit of being readily available, a built in node can offer improved performance. However, it has a code maintenance cost, and the possibility of making too many redundant built in nodes.
  • For now, the consensus was to not add this as a built in node, but reconsider in the future if it offers performance benefits.
• D16435: Geometry Nodes: Group Face by Edge Node
  • Hans asked those interested to check out the patch and leave feedback there. There wasn’t time to discuss the patch in this meeting.
• D16456: Geometry Nodes: Add Select Edge Ring Node
  • The “Edge Rings” node is a lower level option compared to this node that would probably be preferable.
• D16404: Geometry Node: Index of Nearest
  • Hans mentioned that this node raises the question of duplication of field input nodes with a geometry input. For example, it’s slightly similar to “Sample Nearest”, but it uses the geometry from the field context. This wasn’t discussed further though.
  • Since this is such a common request, it might be worth adding now, even if it will be redundant when/if list fields are added.
• D16316: Nodes: “Exists” boolean for the Named Attribute Input node
  • Good to go!
• D16471: Geometry Node: Edge Rings
  • People like the general idea
  • There was conversation about naming-- “Set” vs. “Group”. Hans liked “Set” at first, but Chris mentioned that “Set” sounds like “Set Position”. This needs more discussion, since we haven’t been consistent in the past.
• D16397: Image to Points geometry node
  • The meeting ran out of time before this was discussed, it will have to move to the next meeting or be discussed in chat or in the patch.

Follow Up

• Hair (call for help from artists to validate procedural hair nodes)
  • Find right low level nodes for efficient hair interpolation.
  • Build node groups the encapsulate high level behavior like Clumping.
  • Daniel will organize a meeting for that (if you are interested let him know).

Next Meeting

The next meeting will be on Tuesday November 29, 15:00-16 CEST (Your local time: 2022-11-29T14:00:00Z), which is 2 weeks from this meeting. The provisional meeting agenda will be linked in the #geometry-nodes channel before the meeting.

[modmoderVAAAA]

I’m not an artist (for at least the last year I’ve been writing code longer than doing something in blender ) but I have something to say about hair interpolation.
I see this as related to the mathematical problem of knot analysis, since often the hairs are not parallel straight.
But if we consider a group of nodes close to the roots as an extruded polygon, then I had an add-on describing the use of this concept.

Example

Initially, this was conceived as an extension of control over the final shape for those who are at odds with the comb.
But interpolation in full 3d space also gives chances for interpolation.

Full math 3d space advantage

I’m not saying that you can correctly interpolate the hair in the general case, since it’s a bunch of curves with different, both quantitative and qualitative parameters. But if this variant can help…

I’m not sure what this might look like in production (because I haven’t experimented with implementing this in nodes yet), so it’s more of a possible concept.

[F_Scociety]

So happy to see Simulations on the agenda