Hello folks, I found this python Safe Inset (Blender Addon) and tried to replicate the basic logic with Kangaroo, I’m not sure if it’s the right way to go.
The main idea is to work with a HIGH offset distance and keep all edges with a least a minimum length to finally quadmesh it.
I started with a polyline with a ColliderGoal to avoid intersection and AlignGoal to prevent them from being reversed, but too bouncy for now…
It reminds me, all the Medial Axis and Straight skeleton studies @DanielPiker@laurent_delrieu@maje90 Any advice guys or any input are welcome.
regards!
Thomas.
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.
Thank you for the input. Actually, this is what I expect when there are no kinks and all are quad-faces.
When @laurent_delrieu put the comparison just noticed the ngons faces.
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?
Same here.
How/when is this useful?
I understand creating a new rows/loop of quad faces that have the same width… but how letting some quad become wider is acceptable?
I’m trying to put some code, but working blindly for now…
Here an attempt. Iterative while checking for collisions… AggressiveInset V0.11.gh (13.7 KB)
Input points will make a closed polyline
Input points must create a polyline that is flat on XY plane, counterclockwise, with no starting self-intersections.
Gif seems good but it’s actually quite glitchy.
Still no idea when something like this would be useful…
Awesome @maje90 really nice! better imposibble, don’t be modest!
how could it avoid concave quads, a triangle with 4 vertices would be better
(every bisector projection could check if it intersects first with the adjacent bisector projection.)
Thank you again Riccardo this approach could be as quad thicken filling!
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.
See this:
(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.
