2023-09-05 Nodes & Physics Module Meeting

Check the overview thread for more information about the meeting.

Present

  • Dalai Felinto
  • Hans Goudey
  • Jacques Lucke
  • Lukas Tönne
  • Nikolaos Stroubos
  • Octave Crespel

Since the Last Meeting

  • Lukas committed the main node panels pull request to main, adding support for creating panels in node groups and significantly improving the node group interface.
  • Iliya finished the Points to Curves node, which allows grouping and sorting a point cloud to form curves.
    • Hans added a check to avoid copying attributes when the point order doesn’t change.
  • Hans committed a small set of rotation socket nodes, and moved the feature out of experimental. The socket color was slightly changed too.
  • The performance of working with meshes has been generally improved.
    • Hans finished rewriting the split edges node, this time with an observed 5x performance improvement (at least 15 times faster than the initial BMesh version).
    • Topology maps are now cached, so they don’t need to rebuilt whenever they’re used or because a mesh is copied.
    • Iliya made the construction of topology maps (from vertex to edge and edge to corner) parallelized, giving a 3-4.5x improvement.
    • Mesh normals caches are now shared between meshes, so they don’t need to be recalculated as often.
  • The node editor interface was generally improved too, particularly the add menus.
    • Pablo Vazquez refactored the node editor add menus so that node group assets are populated in shader nodes and the compositor.
    • New contributor “Daybreak” added support for dragging materials into the node editor, inspired by a comment on Blender Today.
    • The location and names of node group operators in the editor menus has been tweaked by Sun Kim.
    • Tool specific nodes are now organized properly in the add menu.
    • A pull request from Ludvik Koutny moved the “Auto Offset” toggle from the node editor header to user preferences.
    • Philipp Oeser made the auto attach status display in the status bar.
  • Hans changed the “Add Modifier” button and menu to be extended with geometry node group assets. Jacques worked on some related features for adding search and recent items to such menus.
  • Jacques has continued work on the internal baking API, improving the code for both simulation and the upcoming bake node.

Meeting Topics

  • Bake node targets 4.0 vs. 4.1
    • The complexity comes from the “bake overview” user interface and the need to refactor simulations and add new features at the same time. It’s also already fairly late in the 4.0 release schedule.
    • Jacques proposes to add the overview features, baking individual simulations, and choosing a bake path per simulation in 4.0. Then the bake node itself would be added in 4.1.
    • There was general agreement with that proposal.
  • Node tool priorities
    • Hans will separate “main-ready”, polishing, and new features into separate lists.
    • Main-ready is blocking to move out of experimental, polishing may happen for 4.0, the new features should come later.
  • Subframes
    • Simulation quality and low quality motion blur are impacted by lack of subframes.
    • There are three places to control subframes
      • Scene-wide settings
        • Simple and easy, but some simulations shouldn’t use subframes and there are performance implications.
      • Per-simulation or bake
        • Subframes might not match up between objects, which could give severe performance problems.
        • It may be possible to guide users to choose common subframes or show that the choices are suboptimal.
      • In the bake operator
        • This probably doesn’t give enough control for every use case, but may be useful in some cases.
    • Adaptive subframes are a large open question
      • Outputing a “potential next delta time” might be a solution
    • The number of subframes might need to depend on the framerate
    • Having higher level control of subframes will be important, so users can think about “Quality” rather than controlling subframes and other properties individually.
11 Likes

From the user’s perspective, I am firmly up to per-simulation control for subframes. Some simulations are quite performant and give plausible results with lower subframes, the other needs a very high number. But in production, those different simulations could work perfectly together in one scene.

Having one unified subframe setting per scene is not flexible.

7 Likes