I’m currently working on a project where I need to create surfaces to represent the bases of walls. To achieve this, I’m offsetting lines by specific distances. However, I’ve encountered an issue where the offset lines end up overlapping each other.
To tackle this problem, I’ve been trying to develop a logical algorithm. The idea is to extend the lines when they encounter convex corners and trim them when they encounter concave corners. This approach works well for polylines, but I’m struggling to find a solution when three walls share a common point, as depicted in the image below.
In the image, the red lines represent the lines I have in Grasshopper, and the brown surfaces are the desired outcomes.
I’m reaching out to see if anyone has encountered a similar challenge or has suggestions for an algorithm that could address these scenarios. Your insights would be invaluable @DanielPiker@Quan_Li@Joseph_Oster
how do you define the offset direction of each line?
would be acceptable for your workflow to offset half distance on each side of each line?
the final output you want is a unique surface for all the curves which have an end in common, or you want to have all the single surfaces from each line?
The offset is a positive value following the direction of the creation of the lines (from the initial point to the end point, the positive values go to the right side). The lines are created following that criteria so when applying the offset, the result is what I want. What I would like to solve is the overlapping problem. (Green lines in the picture are the offsets and red lines the initial lines)
I’m think to a completely different approach, which is based on overlapping areas at intersections, and missing overlapping areas at corners
and I’m thinking at this because sometimes you have to extend a curve, sometimes you have to shorten a curve, and you need a reliable and repeatable system to make choices
for instance, these numbers indicate how many end-points coming from different lines are accumulating at a given point:
and this sort of leads me to think:
whenever you have just 1 point, then things are ok as they are
whenever you have 2 end-points together, one of the two lines should contract/expand by a full width
whenever you have 3 end points together, one of the two colinear lines should for sure contract by full width, and the non-colinear one may contract or not
then it’s more a matter of deciding which of the candidate lines receives which treatment and why
I did a very fast sketch of the idea, full of repetitions, bad practices and stuff like those in the form of a loop, but it should be corrected using MANY more sample-lines because there are many cases not covered in the simple file you attached
could you please provide some more sample lines?
be aware: opening the file will send you to hell without dying ._____.
[and it needs the plugin Anemone for looping]
I have no idea
for sure you can code the whole thing and run it inside the Script component itself… but that’s something much more complicated
regarding the behaviors, I think the most important points are, given a point P where lines are meeting:
how many lines meet at P
the angles between them
their direction (because the direction of the curve defines the direction of the offset)
in the cases you have provided, only a relatively small subset of all possible cases are present: I think it’s important to define if the missing cases are never present, or if they might be present but are just not in those samples
for instance:
this short sentence defines a whole new group of possible cases
and the thing of having the curve direction to determine in which side the curve is offset generates many more possible cases
I’m starting to believe a simpler approach likealways extending any meeting curve by its thickness, create its surface, make some booleans (solely with Clipper2 plugin, so it’s another no-go ) and see the result might be a better approach
) and see the result might be a better approach