Info
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 - dailies at 14:00 CEST
- Meeting Agendas and Notes - updated throughout the week
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
- Have to rename “Rotate Euler” node.
- 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
- Can be committed in parts, so the first commit just storing attributes can be committed after a round of review
- T92926: Support dynamic attributes on instances
- Intermediate Value Naming
- Revive https://developer.blender.org/D8286 and add support for linking to labeled reroutes.
- 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
- Different types of simulations would require different types of editing.
- Does it store the state for one frame or the entire simulation?
- Two types of baking:
- 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.
- D13097 | Add Selection output to star node
- 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.
- Two options:
- 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:
- Only create a point cloud point for now.