2021-11-8 - 2021-11-12 Geometry Nodes Sub-Module Meetings


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

Week starting 2021-11-08

  • Rotation socket
    • Have to rename “Rotate Euler” node.
      • Maybe “Modify Rotation”
      • “Align Rotation to Vector” is more straightforward.
    • Use quaternions internally in geometry nodes.
      • Still present rotations as Eulers to users.
    • Add a new quaternion attribute data type.
      • Similar to how we use “color” instead of float4.
      • They need special behavior when e.g. interpolating between different values.
    • The implicit conversion from 3D vector to rotation can interpret it as an XYZ Euler.
    • Even if we add matrices, rotation sockets are still useful in many cases like the Instance on Points
      node and creating matrices.’
    • The add menu can get a new “Rotation” category.
    • T92967: Add rotation data type
  • Geometry to Instance
    • Useful for switching between instances in the instance on points node or to optimize combining geometry or transforming it.
    • A node that creates a non-transformed single instance of a geometry is a simple, flexible solution that has no downsides.
      • Geometry or Instance category?
    • T92964: Node to create a single instance from geometry
  • Instance attributes
  • Intermediate Value Naming
  • Simulation
    • A continuation of discussions from last week, trying to make progress on clarifying the design. This time mostly relating to the different times/clocks.
    • Scene time: Corresponds to the final rendered animation.
    • Simulation clock: Corresponds to the time-steps of simulations.
      • Generally the time since the start doesn’t matter.
      • Independent from the scene time.
      • Multiple similation data-blocks attached to the same object for evaluation will run together.
    • Use cases for determining how different “times” interact:
      • Create a stationary basket full of balls with a rigidbody simulation, without running the animation, and without running the simulation when the animation plays.
    • The simulation time and scene time can run concurrently. Combined with auto-keyframing this can provide repeatable results.
    • Without interaction or animation, running the scene time or starting the simulation should have the same effect.
    • It’s hard to scope interactivity features so it isn’t natural to keep adding more, and end up with something like a game engine.
      • However, events and actions are an essential part of simulation workflows.
      • The third component that creates “a game engine” is user interaction. So, by limiting user interaction features, we can avoid increasing the scope.
    • Geometry Checkpoint:
      • Two types of baking:
        • Only the final result
        • All intermediate steps
      • Editing intermediate result of simulations
        • Different types of simulations would require different types of editing.
          • Particle/rigidbody path editing
          • Sculpting cloth or softbody results
      • Does it store the state for one frame or the entire simulation?
  • Johnny’s Patches
    • D13097 | Add Selection output to star node
      • Name could be “Outer Points”
    • D13100 | Add Arc Mode to Circle Node
      • Combining the arc and circle nodes requires adding an option for whether to combine the end points.
      • It also makes the node more complicated when all that’s required is a circle.
      • Sharing the circle’s code makes sense, but in this case a separate node would be preferable.
      • What should happen when the angle is larger than 360?
    • D13041 | 4 Selection Nodes
      • The nodes make sense as they are.
      • However, we may be able to ship node groups with the asset bundle in 3.1.
      • Check with the asset browser team if the asset bundle will make it to 3.1.
      • If so, we can add them as node groups instead of hardcoded nodes.
    • D13035 | Add Relative Offset Input to Curve Handle Position Node
      • Patch name needs updating, but a straightforward change
    • D12947 | Add Relative Mode to Curve Handle Position Input Node
      • A proper use case would be good to see before adding this.
    • D12987 | Asterisk Primitive Mode for Star
      • Both star and asterisk nodes can be built relatively simply with a modulo math node
      • Something like the following group
    • Field nodes
      • D12761 | Index Offset Node
      • D12743 | Accumulate Function Node
      • D12768 | Field Reverse Node
      • It’s not clear for the user how these would interact with the selection from the context.
      • These three nodes also stretch the definition of fields, from something that computes a value per element to a more list-like concept. They also rely on the field being “ordered”, i.e. every element has a next element and a previous element, which isn’t necessarily something we want to rely on.
      • Lists will be necessary eventually for things like neighboring vertex positions-- it’s probably better to consider these nodes in the contex of lists.
  • Materials on curve geometry
    • Two options:
      • Add an easy way to assign a list of materials to a geometry and add a way to pass the material list to geometry nodes
      • Implicitly store a list of materials on the geometry component or CurveEval.
    • The former would require a lot of design changes to allow using the list of materials in the property editor as an input to geometry nodes. So storing a list of materials on the curve is much simpler.
  • Cylinder node
    • Change order of outputs: Top, Side, Bottom
  • Single Point node
    • One node with a dropdown to choose the component type (curve vs mesh vs point cloud)? Or separate nodes?
    • Which category in the menu?
      • Point might make sense, but it technically not correct if it creates other data types.
    • Conclusion:
      • Only create a point cloud point for now.
        • Maybe add an option to create points of other types if there is actually a use case.
      • Call it “Single Point”, because “Point” has other meanings.
      • Vector input, Geometry output.
      • Create a design task, since it’s not clear if there really is a use case or not:

Will quaternions be completely hidden in the UI or will it be a choice? Sometimes it is ueful to be able to use quaternions directly so I think there should be a choice

1 Like

Yeah, theoretically on every exposed (not linked) rotation socket could have a rotation mode drop-down, like we do for object transforms.


Great stuff as always, great job.

Any update on the status of some modelling nodes?
I’d like to move towards using geometry nodes more often for speeding up modelling tasks and keenly awaiting certain nodes to make that a possibility.

For example:

  • Bevel
  • Extrude
  • Inset
  • Solidify
  • Screw
  • Weighted Normal
  • Decimate
  • Weld
  • Mirror
  • Bisect
  • Shear

Regarding this part of the meeting notes, there is a relevant RCS proposal on how to implement lists worth checking out:

Blender’s Fracture has been relatively weak, I wonder if the geometry node has a plan to improve the Fracture