2023-04-18 Nodes & Physics module meeting

Meeting time: 15:00-16 CET (Your local time: 2023-04-18T13:00:00Z)



  • Dalai Felinto
  • Hans Goudey
  • Iliya Katueshenock
  • Lukas Tonne
  • Jacques Lucke
  • John Koszarek

Since the Last Meeting

  • Work continues on the simulation nodes branch, with Lukas working on the addition, removal, and duplication of the input and output node, and Jacques working on baking support.
  • Improvements to share attribute arrays instead of copying them give a significant performance improvement to geometry nodes too.
  • The mesh struct of arrays refactor is finished, with the final step adding a 2D integer vector type attribute that’s supported across geometry nodes.
  • Leon opened a design document about improvements for using frames in the node editor.
  • Design discussions
    • Zones
      • Use a dimmed (but opaque) background color.
      • Only have the borders colored of the input and output nodes.
      • Use the same theme color for all the zones (or revisit this once we have loops).
      • Pablo will propose a final hue of blue.
    • Node based Operator
      • No “Selection” node for now.
      • Use a flag in the input/output to set “Selection”.
      • By default when creating new Node Groups add the Selection input.
    • Not clear whether for output we should have a “Set Selection” node or also a selection flag. We can move this decision for after 3.6 (supporting only input first).

General Discussion

  • Demo of simulation nodes baking
    • The timeline shows the currently cached frames and whether they are invalid (any data has changed since they were cached or the cache wasn’t started at the beginning)
    • Skipping a bunch of frames and continuing the bake doesn’t do anything, it just continues to use the last cached frame
    • Using the “Bake Simulation” button does the caching for the entire scene frame range and stores it in the “blendcache” folder, so the baked data still exists when the file is reloaded
    • The bake can be deleted which removes the folder
    • The “Bake” and “Delete” buttons work on all selected objects
    • Only changed data is updated, if topology isn’t changed, it will only be written once.
    • Hans mentions that there should be a way to avoid caching every single frame and just store the last frame. The question is whether we want to support some basic version of the realtime clock use case.
      • Adding an option in the baking panel to avoid caching would be a simple way to address this.
    • A button to free the cached data in the baking panel would make sense. It might be nice to show information about how much memory the cache uses too.
    • A memory limit will be necessary eventually, to take unused cached frames out of memory.
  • Node group operators
    • The redo panel changes are a bigger problem than originally thought.
    • Efforts are mainly directed to simulation nodes instead.
    • If any part of node group operators makes it into 3.6 (which isn’t clear now), it would land as experimental (not visible in the UI in the released version)
  • Bevel weight as a generic attribute? (bug report)
    • Now that all the other edge attributes are interpolated by geometry nodes, it seems weird that bevel weights aren’t.
    • It was agreed that bevel weight could be stored as a regular float attribute, and Blender can just use the bevel_weight name convention, which can be removed whenever bevel becomes a geometry node and the edit mode experience is improved. A similar change was done for face sets already.

Pull Requests

  • #106970: Geometry Nodes: Is Edit Mode Node
    • How should it relate to paint modes and sculpt mode?
    • The use cases could be addressed by a boolean input for the modifier, though that would be less automatic.
    • One downside is that you can’t opt out of it, e.g. if your computer is fast enough. Edit mode doesn’t capture the fundamental intent of a toggle for “making things fast”. A more generic option that could be controlled automatically or manually might be a better long term solution.
    • This sounds very similar to the larger (though more vague) node tools topic, about adding high-level tools that interact with node groups.
    • Dalai would like to hear Simon Thommes’ opinion on it as well.
  • #106997: Geometry Nodes: Object and Collection Input
    • Yes!
  • #107007: WIP: Geometry Nodes: Scene Sound Input Node
    • The results are usually more compelling when the frequencies are available rather than the single “volume” value. That would make the node lower-level.
    • It’s probably important where the sound comes from, so a specific choice of sound data-block would probably be an improvement, even though that’s less automatic.
    • Jacques worked on a prototype for a sound sampling node ago that’s probably more aligned with the direction described above.
  • #104619: Geometry Node: Index of Nearest
    • This has important use cases with simulation
    • It’s not really the best solution for fluid simulations, since it only allows interacting with one neighboring particle, but it makes compelling things possible.
    • Maybe “Valid” could be named “Has Neighbor” instead.
    • This will be a 3.6 target.

Next Meeting

The next meeting will be on Tuesday May 2, 15:00-16 CET (Your local time: 2023-05-02T13:00:00Z ), which is 2 weeks from this meeting. The provisional meeting agenda will be linked in the #nodes-physics-module channel before the meeting.


Hey @HooglyBoogly thanks for mentioning my PR :slight_smile:
I have another PR ready to go for the missing Collection and Object inputs P106997

I had a few ideas of node designs that I could work on (good for learning) for example giving users access to the scene sound P107007, some were already discussed and rejected, I am available if the dev team change their minds

1 Like