Should the normal for each fill group be automatic? Erik proposed this. Or a single “projection direction” per node. A “Split” or equivalent could be used when more than one directions are necessary.
(note from Hans writing notes: I’m not sure we had a conclusion about this, but I think the preference was a single direction input for the whole node)
“group_index” input attribute for limiting fill
Potentially an important piece for optimization, though it also may be a useful option.
For optimization, an alternative is limiting with bounding boxes, though that may be more expensive.
In the patch it is hardcoded input, which is useful when other nodes generate lots of curve groups (separate characters text nodes).
If it was not hard coded, users would have to manually pass the attribute for what is in most cases and optimization.
Other options:
Filling the string field with a default (only works with string workflows).
Making “group_index” an optional built-in attribute on the spline domain.
Conclusion: Bounding box buckets should be used as an optimization at first. If that is too slow or doesn’t work out, then we can consider the “group_index” solution.
Yes, we want it, it seems useful as a building block, and there were no concerns about it being two specific
Should the use case be handled in a more general way?
There were no concerns about it being too specific.
The direction should be adjustible, and there should be a choice to vary the direction per-segment, just like the tension.
If it is possible mathematically to represent the shape with bezier splines and handles, that would be preferrable. Maybe with a control point in the middle if that is necessary.
These are nice to have, but they shouldn’t appear in the terminal or the modifier, since often it is valid, at least temporarily, to have inputs outside of the standard range.
They should use the “Info” node warning type, and it should be verified that the info warnings only appear in the node header.