2023-05-02 Nodes & Physics module meeting

Meetings
,
1

Meeting time: 15:00-16 CET (2023-05-02T13:00:00Z)

Links

Present

  • Dalai Felinto
  • Iliya Katueshenock
  • Jacques Lucke
  • Hans Goudey

Since the Last Meeting

  • The core team has mostly been working on polishing the simulation branch, with the goal of committing it to main as soon as possible.
    • Lukas finished adding UI to add, remove, and rename simulation state items in the node sidebar.
    • Lukas and Jacques finished the storage and evaluation of anonymous attributes as simulation states.
    • Hans did some general cleanups, and split off some internal changes for main.
  • Jacques made a prototype of a design for “Checkpoint” nodes, similar to the freeze node but a bit more general.
  • The Index of Nearest node from Iliya landed, with some further performance improvements from Hans.
  • Erik worked on the mesh to volume node, which now generates a proper fog volume instead of a hybrid filled SDF.
  • The use of implicit sharing continued– now the store and capture attribute nodes can avoid duplicating data if their input is an existing attribute, and some other nodes can avoid copying attributes when everything is selected/
  • The units on some fields in the string to curves node, which didn’t make sense, have been removed in a commit from Damien Picard.
  • A few unrelated small optimizations landed, including a small improvement to the mesh to curve node and to the blur attribute node
  • Jacques did some work on the geometry nodes evaluator, mostly as part of merging parts of the simulation branch work.
  • Hans landed more changes to the mesh data structure, which indirectly improve performance with geometry nodes. Loose vertices are now cached, edges are now stored as a generic attribute, marking the end of the mesh struct of arrays refactor, and calculation of face corner normals is now faster.

Topics

  • Simulation Nodes status
    • The goal is to move to main tomorrow
    • Jacques made a list of the changes in the branch Simulation Nodes Changes - HackMD
    • Only evaluate simulations that are connected to the output and not disabled by a switch node. That can simplify things, and eventually we could add a way to selectively turn them on.
    • The calculate to frame operator, subframe mixing, and a way to show that a node isn’t evaluated because its result is baked can be added in main.
  • Ship “Merge by Distance” as a built-in node group, a combination of “Index of Nearest” and “Merge Vertices” nodes.
    • Turns out the index of nearest node doesn’t give the exact mapping we need for the merge by distance node, since it doesn’t merge all close vertices to the same index.
    • We would need a new node that gives group indices from groups of close vertices.
  • #106956: Node Editor: Improve working with frame nodes
    • Simon will check out the design later and test it out. Generally there was agreement that the design looks like a nice improvement.
  • Some discussion about the “Checkpoint” design (Jacques will make a task to describe this soon)
    • How much granular control is necessary? Since this feature for productions, maybe granular control makes sense.
    • Why do people use baking? Because there’s lots of data or because it’s slow.

Pull Requests

Next Meeting

The next meeting will be on Tuesday May 16, 15:00-16 CET (2023-05-16T13: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.

11 Likes
2

I would like to add a bit to this answer, maybe you already know this, but just to share my pov, there are many reasons to bake:

1.- the scene file is lighter, so things like “auto save” is faster

2.- version control of the scene is also easier, since the file is lighter, you can have several versions of the scene that share teh same simulation, but not the same elements in other matters

3.- baking make things faster in general, no need to resim

4.- You can always lock a bake or load it into an scene to avoid an animator to touch it for example, so it gives way more control

5.- baking makes things also mroe granular, for example when doing a network render each node access an specific frame or frames, for example a big simulation can take 1gb per frame per simulation, so imagine having granular, volumes and hair simulation, if the sim is inside the file you have a big problem (obviously, I said you probably knew it already)

6.- in the old times a non.baked simulation could deliver a different result in different pc’s, this is not a proble today (probably) but that teached us that it was a safete measure too.

I could probably think about some more reasones on why do we bake any kind of simulation so in general baking at any stage is a good practice, for all of these reasons IMHO :slight_smile:

7 Likes