OffsetNormal - different results depending on Loft method

here’s a .3dm showing two different results of using OffsetNormal: (one on a Loft:normal surface and one on a Loft:straight surface)

offsetNormal_Q.3dm (281.2 KB)

when turning on the control points of the two surfaces, i can see they’re different but i don’t understand why offsetNormal is failing to produce the proper result when offsetting a surface line in the normal direction of a straight section loft.

is this a bug (in _OffsetNormal) or just me misunderstanding how/when the command should be used?

[EDIT] similar problem with using _Fin

Hi Jeff, i´ve tried your example but get correct (and identical) results using _OffsetNormal and _Fin. No idea what causes the side shift in your example using straight sections, though.


so you’re getting identical results with OffsetNormal on lofts using the ‘straight’ and ‘normal’ settings?

I guess this could be a mac problem but I don’t think something like this (or haven’t seen) would be different on the different platforms… I’m pretty sure the actual commands use the same code (?)

thanks for trying it out

(for clarity- I get identical results with fin and offset normal as well… it’s just that they’re identically wrong if I use them on a surface created with _Loft using the ‘straight section’ option… if I create the loft using ‘normal’ option (it’s still a straight loft since I’m only using two curves), then the result is as expected.

Yes i see no change depending on the loft type of the example surface. This might be a case for @marlin (Note: you used the Rhino for Windows category).


[quote=“clement, post:4, topic:5826, full:true”](Note: you used the Rhino for Windows category).


right… i thought it was more of a general rhino thing as opposed to mac specific (and i don’t think many of the experts check the mac rhino category :wink: )

for instance, this thread:
this thread

was in the rhinoForWindows category because i assumed it applied to all of rhino… which it did… if this problem i’m seeing now turns out to be a mac specific problem then i’ll be more strict with choice of category next time i encounter something like this.

no problem. I thought Marlin will probably check the mac category more often :blush:


well, yeah…
it’s just that i’m still not convinced this is a mac problem.
maybe i have a weird setting or something (such was the case with the post i linked to earlier…) … marlin has better things to do than to teach me how to use rhino though :wink:

if it turns out it is a mac problem then i’ll quit posting any command specific questions in this category…

I don’t see any difference between Mac Rhino and Windows Rhino on this test. I opened the model in Windows Rhino, deleted the surface and line in the middle section, then created the loft and line again. Then, the OffsetNormal command on Windows Rhino also creates a non-aligned offset line.

I don’t know why this is happening on both platforms, but I bet @pascal will have an idea.

Checkin’ it. But, I am not getting @pascal emails for some reason… I’ll see if I can figure that out as well.

OK, I think this is or was a bug in Rhino that was fixed a while ago- it works as expected here (Windows, SR8 is all I’ve tried so far) but I recall a bug a few weeks ago where offsets to the inside of a tube (degree 1 in one direction) would miss the center- this was fixed and looks like the same thing- the question is why don’t you have the fix…?


in that case, mitch @'d you in this thread. :wink:

accuracy issue with extrusion surfaces

•that one is probably a bigger deal than this thread… this thread just means i have to individually loft straight segments with the ‘normal’ option instead of doing it all in one shot with ‘straight sections’… that thread means i can’t (practically) use extrusion objects

thanks for looking into it.

fwiw, this problem is no longer present in the latest mac build (march 17) which includes all updates/fixes for SR8… i’m now able to use offsetNormal on a straight lofted surface with correct results.

so basically, from a user pov, the issue has magically disappeared :slight_smile: