Why is 'Offset Crv on Srf ' failing?

Grasshopper
1

image
image2556Ă—1200 133 KB

offset crv on srf fails.gh (6.5 KB)
I have two surfaces whose borders I want to offset on the surface. One works while the other fails. What is the reason for this?

2

How did you create the smaller of the two surfaces?

3

image
image1846Ă—481 76.3 KB

surface creation.gh (20.1 KB)
I shatter a set of curves and then extrude them.

image
image1446Ă—1228 43 KB

As you can see, most of the smaller pieces fail to offset.

The workflow before this is a User Attribute Text workflow to get the shatter parameters and extrusion vectors - it should not matter (I hope)

4

the surfaces have very bad parametrization / narrow domains in v.

            {0;0}
0. u:{0 To 600} v:{0.352189 To 0.353408}
            {0;1}
0. u:{0 To 600} v:{0.348129 To 0.352189}

and are a bit far from origin as well.

bake them, _makeuniform,
reassign them to the surface parameter - will solve the issue.
for sure this can be done with gh-components. of course with scripting.

Screenshot 2025-12-03 at 11.39.07
Screenshot 2025-12-03 at 11.39.072360Ă—1568 1.13 MB

EDIT (twice)

reparameterize

or normalization 0..1 ?
… functionality is hidden in the right mouse menu of the surface parameter itself:

Screenshot 2025-12-03 at 11.58.50
Screenshot 2025-12-03 at 11.58.50272Ă—148 21 KB

fast and easy way to solve the issue.

via script

my initial approach … let s keep it as scripting-info:
this will set new Domains from 0..1 and solve the issue:
(i thought there was a gh component to do it, but i do not find it)

    private void RunScript(Surface srf, ref object a)
    {
        srf.SetDomain(0,new Interval(0,1));
        srf.SetDomain(1,new Interval(0,1));
        // Write your logic here
        a = srf;
    }

offset_crvOnSrf_setDomain_tp.gh (10.5 KB)

kind regards and happy spaghetti - tom

3 Likes
5

Oh woah I just reparameterized in the surface parameter it in grasshopper itself and now its working fine. Thanks a lot! Didn’t realize that splitting up a curve in many surfaces will give me messy surface uvs.

The surface parameter has a reparametrize operation

image
image2286Ă—1123 295 KB

1 Like
6

Good to know that this can be a problem.

But why?

7

i can only do some alchemistic guessing:

U-V coordinates 

corner minimum UV =   0.00000000, 0.35218870
corner maximum UV = 600.00000000, 0.35340832
newpt offset50 UV = 550.00000000, 0.35327337
......................................^^^^

the u domain looks healthy. the v’s domain does not.

the u,v coordinate of the required offset by 50 units point is on the 3rd or higher digit. The document at least requires another 3 or 4 digits of precision.
one of the corner points is already close to a “far from origin” issue.
(moving surfaces to 0 does not solve the problem)
(7 digtis 2031330)

2031330.32393551,-53414.24645145,14200.00000001

for sure somewhere in the underlaying math / algorithm there is some tolerance applied to find the offset corner points - and this tolerance somehow conflicts with finding the correct v-coordinate

But i totally agree that it feels like it should be possible to set up a more robust algorithm … taking care on the domains size or similar… who knows… (just guessing)

2 Likes