2023-04-04 Nodes & Physics module meeting

Meetings
,
1

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

Links

Present

  • Lukas Tönne
  • Miro Horvath
  • Falk David
  • Iliya Katueshenock
  • Hans Goudey
  • Jacques Lucke
  • Dalai Felinto

Since the Last Meeting

  • The team spent most of its time in the final phase of bug fixing for Blender 3.5, and working on simulation nodes.
  • Lukas implemented a prototype of the realtime clock, and made a particle system demo
  • Hans worked on more mesh performance improvements, mostly by skipping the unnecessary loose geometry and bounds computations.
    • The storage of mesh face corners has been made generic too, giving slight improvements in performance across the board.
    • Alexander Revkov also contributed an improvement to skip computing bounding boxes for primitive meshes.
  • Leon has been prototyping a UX change to simplify the process of working with frame nodes. That is being discussed in a thread here.
  • Erik has been making progress on the SDF volume implementation in a branch, and recently looked at making the existing “Mesh to Volume” node more consistent.
  • Looking farther into the future, Jacques and Hans continued improvements to the index mask data structure, and Jacques has continued working on large memory usage improvements for geometry.
  • There is now a dropdown that makes it possible to select the UI subtype for built in socket types.
  • Iliya finished a UX improvement for link-drag-search to move data-block default values
  • Thanks to Daniel Salazar, “Color Ramp” is now two words in the UI.

General Discussion

  • GDC report from Dalai
    • Lots of positivity and ideas about integration with geometry nodes
    • It might be good to have a more official presence there next year
  • #106497: Geometry Nodes: Freeze Node
    • The difficulties of developing the freeze node (checkpoint/edit mode node in the past) overlap with the development of simulation caching
    • Developing them separately would even be easier, and allow users to separate the concerns too.
    • Can the freeze node be inside the simulation loop?
      • Technically yes, but the behavior might not be useful
    • The animation frame range should be separate from the scene frame range, or at least that should be an option.
    • A downside is that the freeze node would be required for most simulations. Keeping them separate for now simplifies the design too though.
    • How would this transition to become the “Edit Geometry” node that allows manual edits in edit/sculpt mode
      • The node would have to be renamed and some features would be added
      • On the data-block level this would be trickier, but eventually the node might have pointers to various geometry data-blocks in the main database.
      • For animated bakes, there would be a mesh/point cloud data-block per frame in the .blend file.
    • Eventually the automatic cache should be able to replace some uses of this node. People will “un-learn” using the freeze node in the future.
    • The node has a float input for the frame to support substeps for motion blur. The baking/freezing operation should have options for how many substeps you want to bake.
    • Storing the cache per original node vs. per modifier is an important design consideration, that should be addresssed with some sort of pros/cons list.
    • How does the node deal with anonymous attributes? Which anonymous attributes should be baked?
      • When the geometry is frozen, all anonymous attributes might not be included. We would have to tell the user that not all anonymous attributes are included in the bake.
      • It would be nice to bake used anonymous attributes implicitly, rather than requiring connecting all anonymous attributes to the freeze node manually.
    • How to transition to Edit Geometry when using animation bake
      • Is it a single data-block or one data-block per (sub-)frame?
    • Edit Geometry (local) vs Simulation Baking (global)
      • This may be the solution that address both scenarios.
      • But we do need to make sure the difference in the use-cases are considered, where the data is stored, and which high-level UI is exposed for the users (to bake either individual nodes or a series of objects interacting with each other).

Pull Requests

Next Meeting

The next meeting will be on Tuesday April 18, 15:00-16 CET (Your local time: 2023-04-18T13: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.

14 Likes