OffsetSubD

The new offsetSubD command seems reliable and I can’t seem to break it no matter what I feed it.

One possible bug: it seems like currently, the offset distance ends up being represented accurately in faceted display mode, across vertices from the original surface to the new one. This happens regardless of choosing solid output or not.

If possible, I think it would be better for the offset distance to be represented accurately in smooth mode. By this I mean that if you input a subD cylinder with one of it’s caps removed, and set a thickness of .250, the command should produce a subD cup that has a wall thickness of .250 in smooth mode, as measured by a line normal to the inner and outer surfaces. Obviously there would be some level of variation for more complex surfaces, but the target should be that distance in smooth mode, not faceted mode. Currently the output in smooth mode seems to be about 10% thinner than specified when I test it with simple objects.

Hi Max. Thanks for the feedback. As you noticed, OffsetSubD just offsets theSubD control net by the distance. I tried offsetting the surface limit point mesh directly and the results were not very nice. Lots of unexpected wiggles. I’ll see if I can come up with something better. Maybe a combination of the two methods.

Totally makes sense that it would be easier to offset the control net.

Also, I just checked and saw that the resulting offset difference in smooth mode for a cylinder with 10 “around” subdivisions is radically different than for a cylinder with only 5 “around” subdivisions.

A workaround for something as simple as a cup or a cylinder is pretty easy:

  1. offset it, not solid.
  2. draw a line across the diameter of the inner subD
  3. draw a radius line from the midpoint of that diameter out, adding the desired thickness to the length.
  4. call _Scale or _Scale2d and use the endpoints of the smaller and larger lines as guides.

For more complex objects there’s probably a way of using surface normals to get to the same result, or close to it. And I just checked and found out that _curve_normal works fine with SubD objects which is yet another advantage of native SubD over some plugins!

For what it’s worth, this is also how TsThicken works. If offsets the accurate distance in box mode. In smooth mode the surfaces are not an exact distance offset from one another.

I used TSplines for some anatomical models that had to be molded and even though the wall thickness was not consistent it worked like a charm.

But I can imagine there will be plenty cases where an accurate offset may be needed.

1 Like

I’m doing CNC wood carving so I don’t need the level of precision an aerospace engineer would. The functionality already there is pretty good for me.

With grasshopper integration, it seems like it’d be possible to just set a slider and a few reference lines normal to the original surface and get a more accurate offset very quickly. Might even be possible to use the reference lines to automatically produce the offset (offset to the maximum distance that still intersects the reference lines).

In this command you should add a preview, always useful in each tool, and an option that allows you to create thicknesses with flat ends (ticken normal and ticken for vertex normal).
For example:

2 Likes

I don’t understand why in several commands, this for example, the preview is not added (a dynamic preview would be appreciated). It seems a trivial aspect, but it is important when modeling, to have a preview of an operation: it is essential! This also applies to other tools, SubDThickenCurves, ArrayCrv … for example.
Wait months and months, version in version to have this feature seems to me an idiocy! I don’t want to be controversial, but sometimes Rhino’s development seems inconsistent and neglects some fundamental aspects.

In this command, still very lacking and coarse, as I said before, you would need an option to Tsplines, which returns an offset for normal and for vertex normal (with dynamic preview, possibly). I hope we will not have to wait for Rhino 8 to have these characteristics … ;-(

Many months have passed, and still nothing …
Rhino’s slowness is proverbial, many times to see improvements in important tools you have to wait for two versions, which translates into years and years… Crazy!
(take some more developers and go a little faster, you will see that users will buy your software with more desire!).

Take these opinions of mine not as negative criticisms, but as a reason to do better … and be faster: time is money!

1 Like