Check the overview thread for more information about the meeting.
Present
- Iliya Katueshenock
- Jacques Lucke
- Hans Goudey
- Dalai Felinto
Since the Last Meeting
- Hans continued work on node group operators, with some initial code doing the very basics in main now.
- The next steps are in progress, with operator-specific input nodes and support for other object types and modes with asset traits on the schedule for this week.
- Jacques is close to merging the Repeat Zone, which is the name for what we previously called “serial loop”.
- Lukas continued to work on the internals of panels for nodes and the modifier.
- Using stable identifiers makes it possible to move simulation zones into and out of node groups without losing the cache or bake.
- Jacques started work on data-block mapping for the modifier simulation cache, so simulation caching and baking can support materials (and other data-block references like other objects, eventually).
- As part of exploring the “node tools” project, we investigated the first step of a “context switch” button for editing attributes. The prototype adds a button in the modifier that can switch the active object and mode.
- The extrude node and a few other nodes are slightly faster with multithreading in part of the process.
Meeting Topics
- Will it be possible to use node group operators on data-blocks that aren’t assets?
- Not requiring groups to be assets is theoretically possible now that the asset traits are stored on the node tree itself. But it’s not clear where they would be added in the menus, without catalogs.
- Without that solved, we will require assets for now.
-
#109610: WIP: Geometry Nodes: Points to Curves node
- This node converts a point cloud to curves, sorting points and grouping them into curves.
- Should this also do point sorting within each curve?
- Yes, that doesn’t hurt, and it’s intuitive and should be faster to do that at once rather than separately.
- How does this relate to a more general “Sort Elements” node?
- Sorting generally makes sense, and there isn’t much of an argument against it.
- Sorting by Group ID would be good, so different chunks of the geometry can be sorted separately.
- Hans can make a design task for a general sorting node.
- Should mesh inputs be considered points too?
- Theoretically this could work, arguments could be made in either direction.
- However, since the “Mesh to Points” node first is “free” performance wise, we could avoid the code complexity of supporting mesh inputs for now.
-
#109965: Rotation Nodes Design / Splitting Nodes
- To move forward with the rotation nodes we need to consider how adding a node for each operation affect’s the design of other nodes.
- Generally we have focused on adding atomic nodes that only do one thing, since they are more flexible, composable, and generally intuitive when building a node system. Then we rely on node groups for abstraction.
- Improving the operator to switch nodes and making it built into Blender removes some of the downsides of using separate modes rather than nodes.
- We have been talking about changing math nodes for a while, to make them more atomic. It’s not clear how far we would go, but generally nodes that do one or a few operations on multiple types would be preferred. We won’t have time to do that for 4.0 though, unless a community member has the time to help.
- The design task has heuristics for choosing between nodes and modes should go to the wiki. They are purposely a bit vague, since they have to be considered case by case.
- Consistency for nodes between other editors
- Over time, inconsistencies between node editors have accumulated, partially due to lack of developer time, and partially to avoid breaking changes.
- Repeat zone in shaders
- Rendering developers would know better how hard this would be. The high level code for the UI can be shared relatively easily.
- High level inputs for materials
- Materials should have a design more similar to geometry nodes, with a list of exposed parameters rather than the current node-editing list in the property editor.
- Fields in materials
- The fields concept maps well to materials, to separate values that are constant for a shader like attribute names or image sockets and varying values
- Simulation in the compositor
- This one is a long shot for now, though some of the recently added UI code would be helpful. Maybe it makes more sense to combine the node tree types instead.
- Node panels is an example of a new feature that’s added equally to all node types.
- Simulation nodes feedback
- People want a way to force an input to not be a single value rather than an attribute field.
- The option could be shared with node groups, where this need for “single value only” has come up before.
- Another option would be an “Allow Attribute” checkbox in the simulation input options, but we agreed a “Single Value” option for node groups and simulation items would be most intuitive.
