Isotrim surface with UV domains of another

Hey everyone. To be honest couldn’t come up with a proper title for it but hopefully I can explain a bit better below.

I have this torus surface which is being trimmed into a smaller concave elipse like in the picture

After that I would like to isotrim it like so. But as you can see, the isotrim takes the underlying surface as its target, making the resulting grid follow it.

At the end of the script you’ll see I even attempted to make an untrimmed surface with the same shape by projecting lines onto the trimmed version and lofting it, however, whenever I divide it, my grid, as expected, follows the isocurves of this new surface

Tried to extrude the curves I get with the trimmed surface to split the untrimmed version, but that’s crashing rhino cause it’s too much geometry. I wonder if someone knows of a method that could help me achieve a grid like the first one, but rather on the shruken version of the surface, rather than the underlying one

Best regards, folks

Torus Panelled Roof.gh (25.4 KB)

R8 and Pufferfish.

Should I internalise the geometry and send it again then?

or is it a compatibility issue you’re point out? Sorry I didn’t get it

No plugin :bangbang: Hasty, other ways might be simpler?

Oops, that used R8 Area, this version is for R7 (and R8):

SubSrf _2024_Jul11aa.gh (16.5 KB)

Many thanks for that, it worked wonders, and much more optimized, but I’m afraid I won’t have much control over the segments of the final surface, as the torus is the one being isotrimmed, any idea how could I solve that?

Other than performance, why is that a problem? I’ve been working on improving performance, which becomes an issue when the UV counts are high, and avoiding an anomaly I saw sometimes where the Area component turned red and two isotrim surfaces went missing. Better now?


SubSrf _2024_Jul11b.gh (21.7 KB)

oh that’s awesome, much appreciated

Here is something relatively simple in concept but extremely slow by comparison. It creates isocurves explicitly, then trims them with a scaled bounding box to isolate curves that barely cover the curved surface. As you can see by the profiler times in the two cyan groups, total time for the same resolution as version ‘b’ (which took only ~5 seconds) is close to three minutes :bangbang:

I’ve reduced UV slider values (blue groups) so wait time is ~5 seconds opening this file.


SubSrf _2024_Jul11c.gh (26.9 KB)

Maybe someone can speed this up? Right now, version ‘b’ is way better than version ‘c’.

Certainly is a solution worth gold to me for its logic itself, I’ll study it too, thanks for the help!

I’m not sure if this would require another topic, but now, I need to fit that surface edge to a pre-defined curve, completely different subject from this, should I create another topic for it?

I don’t know what you mean?

The boundary elliptic curves are in the geo container, I need to morph this surface in a way its own boundary eliptic curves fit right into the existent ones

I got close but not quite there yet, but using the bounding rectangle component from pufferfish (no idea how to do it without it)

Panelled Roof.gh (1.8 MB)

I still don’t know what you mean and don’t have Pufferfish, so… :man_shrugging:

I have the eliptical edge of the surface you helped me generate, but I need to distort it to make it follow the red line

No pufferfish on this one:
Panelled Roof.gh (1.8 MB)

Why not just increase the diameter of the torus and otherwise manipulate the parameters you have? I can’t follow things that don’t make sense to me.

Distort if you must, perhaps I don’t understand what you want, but I’ve made a few changes to yesterday’s version ‘b’.

  • I construct the torus differently so the result is oriented more like a roof.

  • I added a yellow group slider to position the roof at a fixed distance above the ground, regardless of changes to three parameters (blue groups) that determine its shape.

  • I added a white group that shows the length, width and height of the roof.

The blue group sliders set ‘Torus R(radius), ‘Radius(section radius) and ‘Height’ which indirectly affect the dimensions in the white group. The ‘U Count’ and ‘V Count’ slider values are low for better performance and can be increased after dimensions are satisfactory.


SubSrf _2024_Jul12a.gh (25.6 KB)

1 Like

Belatedly, it occurs to me that instead of deriving dimensions of the Bounding Box, as I did yesterday in the white group, wouldn’t it be better to specify those dimensions?

Splitting a torus was OK to convey the shape but misdirected efforts to write the code. That same shape can be achieved by using one arc as a rail and another arc as the section for Sweep1, as I did in this version. A big bonus is that SubSrf (Isotrim) and related culling is far faster because the surface being split is much smaller than a torus.


SubSrf _2024_Jul13a.gh (25.3 KB)

You might still feel the need to “distort” (morph?) the results, which I don’t understand yet, but this version is WAY BETTER in any case :bangbang: :sunglasses:

1 Like

I still don’t know your reason for “distorting” (morphing?) results but the purple group in this version offers an extremely flexible alternative for creating a roof: NetSurf (Network Surface) instead of Sweep1. This one uses a radiused rectangle but all manner of curves are possible.

A Value List (white group) switches between the two methods.



SubSrf _2024_Jul13b.gh (33.4 KB)

Rectangle radius greater than half width:

Rectangle radius = zero:

1 Like

Damn, thank you so much Joseph, that’s really mindful, and yes the rectangle version will be something I will discuss at work after testing the results, but specially the network surface method, which I will attempt to make it fit in the reference curve I sent earlier.

this one in red:

The reason I want to distort it, honestly is because of the data that was handed to me. I was given the measurements of the torus surface (section radius and revolve radius), which I applied by the book. but the outline of the resultant surface (the green edge below)

needs to follow that red curve, which is where the pillars are located, so the roof will be directly onto said pillars

I saw the images but didn’t find that curve in either of the GH files you posted (which appeared to be the same file?). If it’s only the length, today’s version (‘13a’) should work fine because the surface is defined by ‘Length’, ‘Width’ and ‘Height’.

1 Like