Check the video. For some reason, when I offset the surface with History recording, then create another offset (this time as a solid), Rhino decides to create and offset of the offset, resulting in a 3 times thicker model than the intended shape, plus fillets. If I delete the history of the initial offset surface (the top one), then the solid model created afterwards is proper.
OffsetSrf fails.3dm (167.6 KB)
I wonder if “McNeel” will fix this bug in Rhino 7… I turn on the warning for breaking the History of children objects, however, in this case Rhino fails to do so. This leads to losing the offset surface, because Rhino repeats the offset command on it automatically.
I can reproduce the bug @Rhino_Bulgaria reported in both V7 and V8.
RecordHistory on
OffsetSrf a surface with Solid=No
OffsetSrf the original surface with Solid=Yes
Result is the first surface is offset correctly with Solid=Yes; followed immediately by the new solid is offset as with Solid=Yes. The unintended additional result is put on the layer which was was the current layer when the initial offset surface was created.
Consecutive OffsetSrf with Solid=No works correctly in both V7 and V8.
As far as I can tell, this works as it should.
Create a plane in the XY plane.
Run OffsetSrf with Solid=No and distance 5.
Run OffsetSrf with Solid=Yes and distance 1 on the original surface.
This last command changes the input for the history-based first child and you get a box whose sides are offset 5 units from the sides of the new parent.
If this didn’t happen, then history would need exceptions for some modifications to the parent to not trigger an history update?
-wim
The main issue is that the solid offset surface (C) of the parent original surface (A) deletes the non-solid offset surface (B) created prior that moment. The letters A, B, C show the sequence in which those surfaces were create, i.e. A is first, B is next, C is last. With other words:
A is the original surface
B is an offset surface created from surface A
C is a solid offset created from surface A
If the original surface A is turned into a solid offset C while the Command line option to delete the input geometry is active, then the existing offset surface B with enabled History must remain as is, with no further modifications. However, in this case a warning message may appear to notify the user that the History for offset surface B was broken in the process.
No.
The case you are describing is no different than: with history enabled, create a plane, offset the plane with Solid=No, and then move the original surface. If things worked the way you describe, the original surface would be moved, the first offset would stay in place, and a second offset surface would be created.
To have things work as you need with the OffsetSrf command, you need to use the DeleteInput=No option.
-wim
I wrote about the solid offset that DELETES an earlier offset surface, not moving the input followed by the child offset copy. 
These are two totally different operations in Rhino. One is converting an input geometry into a closed solid (hence it no longer serves as a parent input geometry for the history-enabled offset copy), the other one is simply moving the input geometry somewhere else in the 3d space.
Think about it as joining the input surface with another surface or polysurface. An offset copy of that surface will remain in the scene and a warning will be shown, informing the user that the parent object was converted into another type of geometry (a polysurface), thus it no longer could be used to drive the history of the child object.
That’s where the wheels fall off. Why wouldn’t the modified parent be considered as a valid parent? Moving, scaling, rotating, etc are simply other examples of modifying a parent.
-wim
Because the modifications are too severe, basically converting the input geometry into a different type of geometry. This is not a basic modifications such like moving, rotating, scaling, extending of edge or control point editing. The resulting offset solid model is basically a closed polysurface, which is a totally different, no longer editable (by its control points) type of geometry than the original surface.
The warning that shows up upon joining the parent surface to another surface is happening, because this also changes the type of geometry and also makes it non-editable by its control points.
Commands don’t get history-enabled by themselves. Apparently, at least one user out there wanted OffsetSrf to be history-aware. You don’t, and that’s fine. You can use the DeleteInput=No version of the command to have it your way.
-wim
I wonder who is that user who wanted the History-enabled offset copy to be silently deleted automatically upon converting the parent original surface into a solid object.
The main issue is that this happens secretly from the user, with no warning message, even though the setting for showing it was turned on from the Rhino options.