2025-04-01 Nodes & Physics Module Meeting

Meetings
1

Check the overview thread for more information about the meeting.

Present

  • Hans Goudey
  • Jacques Lucke
  • Lukas Tönne
  • Simon Thommes
  • Ben
  • Mattias Fredriksson
  • Raiko
  • Falk David
  • Casey
  • Dalai Felinto
  • Ya hia
  • Quackers
  • Forgot someone?

Since the Last Meeting

Meeting Topics

  • Brief discussion about GPU evaluation
    • No immediate plans, but in the future Geometry Nodes may benefit from running certain calculations on the GPU.
    • It’s not clear what API we’ll want to use right now (whether it’s Blender’s GPU API like the compositor or something like SYCL).
    • Not all nodes would be GPU compatible, so it would require work on the UI as well (e.g., to indicate what may not run).
  • Merging closures and bundles as experimental feature
    • This is ready to go in main, which is helpful now because Lukas is using the feature in his development.
  • Geometry Nodes: Align inputs and outputs in many nodes
    • Remove sample index for now, look at the sampling nodes as a package.
    • Also remove nodes that require reordering of outputs or inputs for now, do those explicitly later since it breaks the API.
    • Should we wait for 5.0? There isn’t really a specific reason to wait.
  • Geometry Nodes: Add option to set the depth order in “Curves to Grease Pencil”
    • Discussion about whether to expose the option for convenience on the Curves to Grease Pencil conversion node. The consensus is to just add the new node.
  • Geometry Nodes: “Instance Bounds” node
    • Simon mentions that this is somewhat related to the larger problem of getting data from instance geometries to the instance domain. The For Each Geometry Zone might be a more general way to solve that problem in general. But it still seems okay to add this node.
  • Geometry Nodes: “Scene Info” node
    • This still needs a bit of work with the dependency graph, and a few outputs to reconsider, but that is being discussed as part of code review.
    • Simon mentions from previous experience that it’s worth being careful about which scene settings cause reevaluation. Things like “brush size” have caused this in the past apparently.
      • Dependency graph granularity might be a requirement for this node in that situation.
  • Nodes: Align Sockets on Nodes to the Grid
    • The idea is interesting to the module. Currently the tradeoff is a bit too big though. This seems to benefit a small number of users without benefit to most users that don’t worry about alignment. Maybe with more iteration the amount of new buffer space could be reduced.
    • Maybe there are other ways to avoid angled links, like drawing them differently, since the fundamental problem may be the ugly links rather than the sockets actually being on the grid.
  • Geometry Nodes: Match String node
    • No objections, good to go.

Ran out of time before discussing these topics (to be discussed next time or in the meantime):

9 Likes
2

That’s a good point, as far as I am concerned the problem is both angled links and text alignment. In my experience, reading a node tree is easier when

  1. the interface is generally less crowded, which straight & horizontal node links contribute to
  2. an output socket is exactly aligned with the input socket on the node it’s connected to (because their labels are aligned as well, making text that much easier to read)
1 Like
4

I liked Mapzone’s approach to drawing node links when the destination is behind or below the previous node,

That is, it was a strong and emphasized ‘S’ shape that often keeps it from going behind the nodes it is plugged into. One possible enhancement for the reroute sockets would be to have a proper swooping curve, so it is easier to arrange them to go in any direction that is needed without needing as many reroutes.

Mapzone was the free precursor to Substance Designer for reference.

5

Maybe something like this (by @Cartesian_Caramel) also could work:

9 Likes