2021-10-04 - 2021-10-15 Geometry Nodes Sub-Module Meetings

Meetings
,
1

Info

Developers or artists interested in contributing are welcome to join at the links below.

Week starting 2021-10-04

Week starting 2021-10-11

  • Undo issue
    • Hans will add his questions to the patch.
    • Dalai will talk to Bastien about that.
  • 3.0 Targets
    • Built-in Attributes nodes.
    • Stable ID changes (T92005).
    • Viewer Node fields input (T92167).
    • Image texture node (D12734).
      • The image can be a socket if we can add a new socket type.
      • That means using a different node than shader nodes
        • So we can also not add all of the options from the shader node, and approach it in the future with a use-case-based design.
    • Volume to Mesh (T92168)
      • Remove the density input.
        • This can be done by using all grids, or just one of them, depending on the implementation.
    • Edge split (T91764)
      • Make a quick version that works with BMesh (and a selection input)
    • Attribute search in the modifier (D12788)
    • Object Info as Realized by default. (T91890)
      • Same for collection. Note from Hans afterwards: I don’t think this makes sense actually, people expect the collection info node output to be instances, unlike the object info node.
    • [design] Named attributes for collection and object info.
      • Related to the named attribute input node design
    • [design] Store Named Attribute node with mapping (D12685)
      • Although this could wait, this conversation should happen soon.
    • UI low hanging fruits (T91880 / T91881)
    • All the previous nodes (Field Conversions - HackMD)
  • Float to boolean (e.g., for selection) - Dalai
    • What if we use 0.5 as the cut to allow more easily to connect maps to selection inputs.
    • This was already discussed here: D10685: Implicit conversion change for float/int to bool - Hans
    • The current alternative is to have a “Compare Floats > Larger Than 0.5” node.
    • Conclusion is that 0.5 is much more arbitrary than 0 as a cut-off, so it is not better.
  • UV as fallback for Image nodes - Dalai
    • Does it make sense to talk about an active UV for a geometry?
    • Right now in the texture nodes patches the Position is the fallback input.
    • We can try to have the active (render) UV as the fallback.
    • No consensus on whether this is a better input, but it was agreed that it was still worth trying.
  • Node categories discussion based on Geometry Node Naming and Placement - HackMD - Hans
    • Use “From” as the category (e.g., Mesh to Curve goes to Mesh category, and Mesh to Curve goes in the Curve category).
    • This means all the nodes that work on curves end up in the same category, etc.
  • Named attribute nodes: Mapping or “expose” operator? - Hans
    • No discussion on this topic, the discussion moved to the next topic
  • Object and Collection Info pointers should be communicated in the modifier (and parent node groups).
    • So users know which data is being used.
  • Object Info node attributes
    • Hans proposed using the named attribute input node as a solution
    • Dalai still wants to see if there is a good solution to objects defined inside the node group, and have their attributes exposed, though it’s not clear what such a solution would be.
    • If there is no solution, we can leave the nodes as they are for 3.0. Then users will have to retrieve attribute from other objects with the object info node, which was viewed as a workable limitation for the time being.
  • Nodes order rename
    • bpy.types.GeometryNode* are out to date. (Johnny to tackle that)
    • User manual as well. (Dalai to tackle that)
  • D12721: Geometry Nodes: “Replace in String” node
    • Addresses the new-line need in a much better way.
    • Without regular expressions this can go in 3.0.
    • For regular expressions we should check how the c++ regex library compares to other regular expression libraries (e.g. the one in Python).
    • For now we can add the node without regular expressions, and add them when there is a clearer use case and more information presented in a patch.
  • String Fields - Jacques
    • Strings are already implemented as fields internally.
    • On the user level there is no use for string fields currently.
    • Proposal: Hide the fact that strings can be fields in 3.0.
    • Example where string fields leak to the UI currently:
  • Socket tooltip future - Dalai
    • They can go away once we have tooltip for the node buttons themselves.
  • Value to String (name / category) - Dalai
    • Should its name change to “String from Value”?
    • The convention for the converter nodes applies only to geometry types.
    • Conclusion was not to rename this node and to keep it in the string menu.
  • Small thing: wording of tooltip in D12858 (We didn’t write down the results of the discussion, and I forgot - Hans)
    • It can say “The node only supports realized mesh or point cloud data, but instances were provided”
    • This sort of tooltip can be automated in the future.
      • Could even be added to the socket declaration in the future.
    • Since people should be familiar with the realize instance node, mentioning “Realized” in the tooltip should be enough of a hint, rather than explicitly telling the user, which is inconsistent with the language the Blender UI usually uses.
  • First sentence when describing what a “field” is to users. - Jacques)
    • Can be used in release notes, documentation, videos, …
    • Typically, more explanation and examples are needed, but it’s good to have a single short sentence that captures the essence.
    • Examples:
      • A field is a rule for value generation within a context.
      • A field is a rule for how to generate a value in a context.
        • +1!
      • A field computes a value in a context.
      • A field is a function that computes a value in a context.
  • Product Demo
6 Likes