How do we parametrically adjust the width if this geometry?

Geometry to adjust width.gh (43.2 KB)

Do you have to do this in Grasshopper? You can’t offset those surfaces directly in Rhino?

@ftzuk that would be a quick fix, but I’d like to be able to do it parametrically so I can explore multiple widths quickly.

After the fact, you don’t. Best way is to create all the geometry parametically in the first place.

@Joseph_Oster … the answer to both is the geometry was imported (not created in Rhino) and that’s where it was located.

Another way is to bake the geometry and join the necessary surfaces. Then reference them back in and offset. Saves you having to create an elaborate script just to select the correct faces. Or select the outline of each wall as a curve (in rhino, not gh) and use that to drive the offset.

You can approximate the result using Scale NU but of course that affects wall thickness.

By the way, you can calculate the scale factor(s) from a linear dimension.

I suppose you could cut the shape in half and move half of it, but I’m not sure how you fill the gap?

This looks like it may be a good use case for the “Stretch” component in Grasshopper @Joseph_Oster , not sure if you’ve played with that one much?

Provide a plane at that cut location you are showing and input that plane to the Stretch Component and the Geometry of course and then you’ll get a dynamic adjustment

P.S. Later… I’ve tried it now but completely failed to understand it or see any useful results.

While I retract my previous statement, I thought this “worked better” than I remember for geometry in general but it mostly just works best for geometry being scaled in 1 Direction like being stretched “along a wall” rather than a T intersection of a wall.

So actually what you started with the “splitting” logic is better.

Here’s the stretching logic anyways for what it’s worth:
20240610_GH_Stretch_Logic_01a.gh (49.1 KB)

Graph Space:

Model Space:

I have an idea based on what you shared that will be more accurate. I’ll share that soon hopefully

Thanks. I find your code very difficult to read… Gray wires on top of (useless?) gray groups.

However, I gained some insight about the expected values of the Stretch ‘X’ and ‘L’ inputs. But the behavior is very strange, with some anomalies apparent on the long wall. Not at all "user-friendly’. And works only to increase the ‘width’, not decrease it?

Sorry about that, to me personally I find it useful and legible. I guess it’s subjective styling.

Like all things that seem simple this ended up getting more complicated than I thought.

Anyways, I expanded on the original slicing logic you created and figured out a way to handle slicing in X, Y, or Z and you can input negative or positive values as well and that influences which portion of the sliced brep gets moved.

The script is a bit bloated and messy but I’m out of time.

Feel free to let me know your thoughts or modify as you’d like. I think it can be simplified greatly but the basic idea is there at least.

Also the Merge Coplanar Faces component is bugged in 8.7 and 8.8 but when that’s fixed it should return a dimensionally accurate “sliced and stretched brep”.

Though I have not tested it, the logic should work to be able to move the plane wherever you want it (offset from the middle of the bounding box to wherever).

This only works with orthogonal geometry. Well… it might work with other geometry but the result will look… well you’ll see haha

Graph Space:

Model Space Video:

Cheers, hope it helps!

Thank you @michaelvollrath, this is very useful for other applications … what I’m looking to do is be able to adjust the wall widths, not stretch the entire building.

2 Likes

@MJD Gotchya,

Here’s a start, isolating the vertical faces, offsetting, extruding and remerging.
Annoyingly the Merge Faces is bugged but once that works it will give you a clean Brep result again.

Likely someone can come up with a better code solution but is this helpful for your purposes?

Graph Space:

Model Space:

1 Like