Offset SubD - deviation

I was wondering where I did the mistake. Searching for the cause found the offset value of the SubD has some tolerance.
Here an example. SubD was converted to nurbs for the thickness analysis.

Version 7 WIP (7.0.20154.16016, 2020-06-02) on Mac

The current method that OffsetSubD uses is to offset the extracted control polygon and then make a new SubD from that. It’s a loose way to get a solid while still having SubD control. This isn’t as precise as OffsetSrf which has a tolerance option. You can however use OffsetSrf on a SubD directly and you’ll get a PolySrf with the same precision as the NURBS version.

Are you looking for more precision in OffsetSubD by having a tolerance option? I can file a request if so.

This was the same for TSplines, it never bothered me. Question though, would it be possible to have SubD default to file tolerance and stay SubD?

I think there’s some complex math there so I won’t make a guess. I did file though for the devs to look at it. I personally like the loose offset you get now so that I can easily edit and smooth the inner SubD wall.

Yes, I would prefer the loos offset over something that’s difficult or impossible to edit.

We used the TSplines loose offset on molded parts. And while the wall thickness wasn’t 100% accurate, it never caused any problems

It was unexpected. When I enter a value, there is a reason for this value. There was no indication of any deviation. I like SubD. If SubD can be controlled more precisely in the future, I will love SubD.

Now I know there is a deviation. If there was a hint like ≈ maybe I was not surprised.

Bildschirmfoto 2020-06-08 um 18.35.25

I may be wrong about this, but I believe this will be the expected behavior. As far as I understand it offsets the SubD control cage points 3mm in their normal direction, the offset SubD surface is recalculated in relation to the new control point locations.

In most cases this was fine for the work I was doing, but I believe there were a few cases where we used offset after it was converted to NURBS because we needed more precise control over the offset distance. This was a long time ago, so I’m not 100% sure on this.