Developers or artists interested in contributing are welcome to join at the links below.
- Workboard - Plans, ongoing work, and community tasks
- Chat Channel - General development communication
- Video Call - Daily meetings at 14:00 CEST
- Meeting Agendas and Notes - Updated throughout the week
- Named attribute node discussion
- Hans created a document about this: Named Attribute Reasoning - HackMD
- Main use cases:
- A. Setting attributes from the middle of the nodetree.
- B. Object info with object pointer inside the nodetree.
- C. Global namespace (e.g., original_vertex_position or high-level node groups).
- D. Dynamic creation of attributes based on names (e.g., bone weight).
- E. Quicker scene layout/draft
- F. Join geometry
- Even with internal hard-coded attributes, users should be able to inspect the node group (or modifier) to see what it depends on (or outputs).
- Maybe even mappable
- Next steps:
- Mockup for how node groups and modifiers communicate attribute dependencies. (Hans)
- Explore overridable defaults for global attributes. (Simon)
- Categories for field nodes (Hans)
- “Accumulate Field” and “Field at Index” are in the “Utilities” category, which doesn’t do a great job at explaining what they do, since it’s so general.
- A “Field” category might be better? However, that’s not very friendly to new users. There was no consensus on this topic, so it can stay as is for now.
D13757: Geometry Nodes: New Scale Elements node.
- “Local space” input currently uses a forward and up vector. Could it use a rotation input instead?
- The benefit of a rotation data type input is that it’s not overconstrained and there is no strong reason to prefer the X axis.
- However, we don’t have the rotation socket type yet.
- Using Eulers has a significant performance cost as well.
- Jacques will test the patch with a rotation/orientation socket or only a single axis.
- Follow up to D13550: Extending vector math node
- (Hadriscus) Comment on math and interpolation on Devtalk
- (Charlie) I’ve added a design task here with a proposal for a way forward.
T94899: Float Math Functions in GN and Shaders
- In summary:
- In a similar way to recent changes to Map Range and Mix Node, extend existing Math node to support higher dimensions. This remains a common node for GN and Shaders.
- Remove functions that operate on groups of floats from Vector Math node and version these to the Math node.
- Allow Vector Math to diverge on GN and Shader to support addition of new functions.
- Integer Math and Boolean Math remain separate nodes.
- In summary:
- Current opinion of the group: As an end goal this makes sense. Also related is the type inference discussion, which may make the type dropdown on the math node unnecessary. We were a bit divided on this part, but it might make sense to delay this change until proper type inference is available.
- Diverging math nodes in different editors should be avoided though, even if the operations are mostly useful in a “geometry” context.
D13804: Geometry Nodes: Triangulate Node - Add Selection Input
- Keep the minimum vertices input or do full versioning?
- There wasn’t complete agreement about this, but we agreed to keep the minimum vertices input.
- We could possibly go further with versioning later on, for example when it’s easier/better to switch out a node for a node group with versioning.
D13809: Flip Mesh Faces Node
- Sign off on naming-- the name here makes sense because it doesn’t flip the normal, it changes the order of vertices and edges in the face which then has the effect of flipping normals. It’s good to conceptually separate derived and original data.
- Extrude back-face flipping vs. solidify node (Hans)
- Generally it’s nice to have the same behavior as in edit mode. However, there are some drawbacks to it.
- One drawback is code complexity, another is that the behavior doesn’t make as much sense in a procedural situation, where we want to be less “smart” and more predictable.
- For 3.1, maybe forever, it’s okay for the node to not keep back faces like the edit mode operations.
- In the cases where the duplicate back faces option is useful, it does the same thing as a solidify operation, which we want to add separately soon. In other cases the behavior is more confusing, and it would be different from edit mode anyway because it has to handle multiple selected regions
Curve component in the attribute transfer nodes
- The “Nearest” mode should find the closest control point of the curve and copy the value to the result, without any interpolation.
- A new “Nearest Curve Interpolated” interpolates the evaluated attribute value between the two evaluated points of the closest segment.
Order of “Domain” and “Type” options in nodes
- No strong opinions from anyone.
- The type can go on top, since the domain might be exposed as an enum socket eventually.
Operators to convert generic attributes into task specific data (UVLayers, etc)
- The workaround operator isn’t intuitive in some situations because it works on original, not evaluated data.
- We could add some info saying that the attributes on the evaluated geometry are different.
D12792: Geometry Nodes: Add Random value to Object Info node
- Jacques can talk about the “Seed” in Amsterdam next week.
- The seed should be changed in an object copy operator rather than the low-level functions.
- The seed should be exposed in the UI.
- Other than that, there’s nothing really new for us to say on this patch yet.
- Copying and pasting nodes as XML or JSON (Dušan)
- The goal would be to share nodes in a text-based format that’s easier to share than a blend file.
- However, Blender couldn’t run versioning on the loaded nodes, which might end up breaking fairly quickly.
- Generalizing this might be possible, making Blend files into text files, it depends on the use case though.
- Making it easier to create a screenshot of the node group might be helpful.