It’s an interesting idea. Thanks for sharing.
I’m not sure physics based is the easiest way to approach this.
An iterative approach where edges are moving in gradually while preventing them crossing over makes some sense though.
It seems a key and tricky part of it is handling the topological changes such as segments reaching zero length and straight edges developing kinks when hit by a point from the other side.
I imagine that with finite steps there’s also some challenge in making sure the step is never so big it misses a crossing.
Here’s a screen capture from 2021… It shows a Kangaroo based optimization of self intersections on mesh offsets inside a climbing hold mold. I cannot share the model and definition.
It is possible with Kangaroo but I’d say it’s complicated
Anyway, thank you @DanielPiker for making Kangaroo. I’ve been fascinated from the very beginning over a decade ago. Thank you for all these tools and improvements over the years. I’m still very excited when my geometry is optimized with the solver and everything looks perfect.
I’ll give it chance to the ClampAngleGoal to add a bisector restriction…
I noticed that DirectionGoal takes the “input Direction” as a straight line and aligns to the closest angle without respecting the proposed direction.
Please @DanielPiker could help me force the “input Line” to the right direction of the “input Direction” with a CustomDirectionGoal?
Concave quads are expected. Or, at least, it’s how I interpreted the “rules” by just looking at the videos you posted. Watching them again, actually it never happens, but maybe because the used shape are “lucky”…
I don’t know how that would resolve.
(to achieve more accurate solutions like here I decreased multiplier at row 89 and increased max iteration count at row 92…)
White and Black bisectors would meet at the blue dot.
But, because of the yellow bisector early reaching the magenta line, the magenta line (and yellow bisector) have to stop expanding.
This mean also white bisector have to stop!
But, black bisector can freely continue expanding, lately creating a concave quad.
Are those “rules” not as you imagined?
How to fix/change them?
I imagined someone could suggest that the magenta line should “pivot”, rotate around yellow tip after touching (without splitting into two, because that would create a pentagon…)… but that seems would create a excessively complex solver with the final shape probably leading to a more randomic equilibrium. But I can’t know this for sure…
Btw. In this first solution I exploited the polyline parametrization. (t parameter tells you in which segment of the polyline the intersection happens, rounding floor and ceiling tells you the indexes of the vertices to stop, like the magenta line up here ^).
Now that I made a solution, I can see how making a scratch new one would be much simpler and maybe even faster: further exploiting polyline parametrization. Just doing CurveSelf intersection checks and working around that…
All these rules make sense, Just to finish the idea of pure constraint bisectors, each bisector should stop when it collides with the closest of these 3 lines (temporary perpendicular lines in the interesctions or with itself)
-Yellow bisector only works with itself (magenta) because it is the closest and also the temp perpendicular lines are outside.
-Black Bisector needs to work until the temp line, which is the closest evaluation line.
Anyway, doing all this in the bisector constraint version to avoid concave quads with doesn’t convince me at all
In fact, I see that he uses the bisector constraint up to a certain point, then adjusts some bisecs to avoid concave quads, and in some cases prioritizes offsetting lines with the minimum parallel length. With these adjustments, acceptable offset filling is achieved.
For me, adjusting some bisectors seems more reasonable for filling. Aditionally it helps keep the small inner segments parallel.
Thanks again @maje90 for your time, I’m still trying to dig into your code.