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 - Daily meetings at 14:00 CEST
- Meeting Agendas and Notes - Updated throughout the week
Week of 2022-03-14
- No real design discussions, mostly continued work on curves sculpt mode, curves evaluation, and porting geometry nodes to the new data structure.
Week of 2022-03-07
- Hair sculpting tools naming and behavior (Jacques)
- Should grow and shrink be the same tool with a toggle?
- Grow has a directional input, so it’s not really the opposite of shrinking.
- So there can be a tool for extrapolation and shrinking called “length”.
- The tools should work on all control points, not just the tips. Then we can rely on more masking tools for further selection.
- How to set the initial length of the hair when adding more.
- Interpolation should be optional eventually anyway, so adding a length option might be fine.
- Cutting vs. deleting vs. shrinking
- Cutting is for precise control over the silhouette
- Smooth control
- Adding length
- Growing (snake hook)
- The old system simply scaled up each hair from the base.
- The opposite of shrink is “extrapolate”
- Extrapolate
- Growing (snake hook)
- Increasing and decreasing the curve density on the surface could be a single tool.
- Could be called a “Density” brush.
- Painting on the surface vs. somewhere on the curves to change the density.
- The latter seems useful, even essential, but doesn’t necessarily cover all use cases. Both should be possible.
- Adding the draw tool from curve edit mode could be useful.
- How is comb working?
- It has the same behavior as the old particle system comb tool, basically.
- A 3D brush option should be possible.
- 2D projection vs. 3D brush
- Both should be possible where they make sense.
- “Front Faces Only” should be an option too.
- The hit area for determining the depth could be smaller than the brush size.
- Proper behavior might need some iteration.
- Interpolation in the add/density brushes
- Interpolate length and interpolate shape should be separate options.
- Interpolating attributes should be another option.
- “Final” set of tools and naming
- Comb
- Cut
- Add:
- Add fixed number of curves.
- Delete:
- Remove all curves in the brush radius.
- Density:
- Adds and removes curves at the root.
- Length:
- Grow + Shrink
- Snake Hook:
- The current behavior of the grow bush
- Should grow and shrink be the same tool with a toggle?
- When to start changing naming from “Spline” to “Curve” in the UI.
- When the data-block is called “Curves”, a single element should be called a “Curve”. The word “spline” was always an arbitrary way to distinguish a single element that never really made sense.
- Internal code-naming changes can start earlier.
- We can create list of places that we have to rename.
- 7 nodes that have “spline” in the name.
- Some tooltips.
- First we should implement searching for a node by the old name, which drags in T92825: Refactor node editor add menu and search.
- Don’t rename “spline” in the context of the old curve object.
- The spreadsheet attribute domain. “Curve” to “Curves” too.
- Code discussion: implementation details for
CurveRefconcept.- An abstraction for immutable convenience methods for a single curve.
- Conclusion: Don’t have
CurveRefat all. - Try to write functions that they take spans of the actual data they need. If we notice that we’re passing around the same spans all the time we can group them later if necessary.
- First step for named attribute nodes (Hans)
- Necessary visualization
- Attribute names used “internally” to a node group don’t matter if they aren’t used as inputs or outputs
- Possible implementation order
- Add “Remove Attribute”, “Named Attribute”, “Store Named Attribute”
- Add initial visualization in modifier
- Add visualization in node group headers
- An experimental feature flag could allow adding the nodes first without any design controversy while the visualization is implemented.
- Design task: T91742: Named Attribute Nodes
- Necessary visualization
- Removing legacy nodes
- It would be useful to have less dead code, and to avoid the need to change those files when refactoring.
- Hans and Jacques are fine with it, but want to check with Dalai when he is back.
- We’ve had two releases with them now (3.1), so people have had plenty of time to update.
Week of 2022-02-28
- Not much discussion this week, work involved bug fixing for 3.1 and initial work on the new curves type.
Week of 2022-02-21
- Self Object node
- Another option is a “Self” item in the object info node list, but Blender doesn’t do that elsewhere.
- One option that’s often proposed is having a “Self” boolean input to the object info node, or outputting the self object when the object field is empty. The former specializes the node in a way that isn’t desireable, and the latter just isn’t intuitive.
- Curves “Knots Mode” design
- Non-uniform rational B-spline - Wikipedia
- The knot vector of a NURB spline is used to control which control points influence chunks of evaluated points.
- The number of knots and the number of points are not the same.
-
Curvesdoesn’t store the data yet. There are two options that we could think of:- Create a new attribute domain “Knots” with a size that depends on whether curves are cyclic and their order.
- Just store it as a separate array, not an attribute.
- The second option is preferrable now, since we don’t want to get into designing another attribute domain, and it’s not clear how that would work.
- In Blender, knots have this quasi-derived data status. They can be imported and exported, but not changed directly. Other applications have ways to edit the knots vector.