Check the overview thread for more information about the meeting.
Present
- Andy Goralczyk
- Dalai Felinto
- Jacques Lucke
- Hans Goudey
- Simon Thommes
- Lukas Tönne
Meeting Topics
-
Baking
- Jacques showed the current state of his branch. The bake node is pass-through by default, has baking controls, including options for animated and “still” baking.
- The bake data is stored per bake node instance rather than per bake node, even when it’s in a node group, so every bake node instance has a separate bake path. This is different from what usually happens with node groups.
- This is important so that node groups containing bake nodes can be used more than once (with different inputs).
- We couldn’t think of a use case that needed the baked data to be stored by the node itself.
- The modifier has a list of all the bake node’s in its tree.
- Theoretically the bake button and UI could be in many places.
- The bake node
- The modifier
- Node groups with bake nodes inside
- A centralized bake list like “bakes in scene”
- Simulation zones use baking as well
- Options to only bake specific simulation zones would be helpful
- Baking inside the zone rather than requiring a separate bake node means that baked simulation can be resumable when restarting Blender
- The bake frame range should be stored per bake (node instance), but only displayed in a popup for the “bake” operator
- The bake node path is editable per bake node instance as well.
- Currently multiple bake nodes cannot share the same bake path (file directory), since writing different data to the same place is ill-formed. However, every bake can have an internal ID that can be used as an automatically generated subfolder in the bake folder.
- In general it isn’t necessary to specify a path unless it’s necessary to control where the bake data files go.
- The bake node can have a path output that can connect to an “Import Bake” node later.
- The Import Bake node is used for importing any bake, for features like time offsetting or more manual caching
- Has path string and a frame input sockets, and outputs the baked data at that point
- Bakes should be managed by a centralized bake list
- One option is adding a list of all the bakes in the scene to the scene tab in the property editor. However, it’s tricky to tell different nodes apart, a tree view that shows the context of bakes in the scene might be necessary.
- Though it may be more overwhelming, reusing the outliner would avoid creating a duplicate tree UI showing scene data.
- Baking a subset of bakes is important, so filtering would bakes in their context would be useful
- The main question is where the more detailed information and editing would go, since there is no panel to display information about the active item in the outliner
- A list in the scene properties will eventually needing a lot of heirarchy information, and we would really like to avoid reinventing the outliner inside of the property editor
- There was a consensus that given the tradeoffs it makes sense to use the outliner as a way to visualize bakes and their scene context. The main open question is where to show the data for the active (currently selected) bake.
- Some bakes have dependencies on other bakes, so the bake dependency view could be its own tree view, but that might not be better than showing a list
- The bake UI
- Subframes
- Different bakes might need different subframe steps. Many bakes might not need subframes at all though, so it’s important that it’s an option per bake
-
Rotation Socket
- Criteria for splitting nodes is mentioned in the corresponding design task. Mainly the heuristics are: whether input and output sockets still mean the same thing in the different operations, and whether the different operations generally do the same thing.
- It’s important that it’s easy to switch one node for another-- at that point it matters less if there are modes vs. separate nodes.
- Modes can help to group nodes and make it easier to find them too, so the add menu should reflect this organization if nodes are separated.
- Two followups:
- Search should be improved to display the menu path of nodes too.
- A switch operator should allow quick switching between commonly related.
-
Easing Nodes
- There is general agreement that ideally it would make more sense for these to be implemented as asset node groups, since the design is scalable, doesn’t add maintanence burden, and is tweakable by users.
- A design for the node with node group assets would use many easing node groups in the same asset catalog and the “switch node” operator mentioned for rotation nodes.
- The main question is whether the node is important enough that it’s worth adding it with a less long-term design. Though no one had a very strong opinion, there was consensus that since this feature isn’t adding new possibilities, just convenience, that it would make more sense to wait.
- There is general agreement that ideally it would make more sense for these to be implemented as asset node groups, since the design is scalable, doesn’t add maintanence burden, and is tweakable by users.
- Node Tools
- Object or collection level nodes (i.e. adding objects, modifiers, etc) have clear use cases as tools.
- Procedural use cases are less clear, though things like scene compositing are natural use cases for things like procedurally generated collections.
- Open design question is how separated “geometry nodes” would be from the new features.
- A very common case “quick fur”, for example: “add an object”, “add a modifier on the object”, “set some parameters”, “enter an edit mode”.
