Wish for Rhino 8: "Shell" improved

We need a more robust shell that works similar to the offset curves command.
Currently the shell works up to a certain point, beyond which self-intersections often occur, and the command fails.
(If we look at the Offset crv command, it manages to do “thickness”, whatever the distance from the edge. The shell should do the same!).
Furthermore, it would be convenient to have a more interactive shell, less rigid in its operation, for example, how the “offset” command behaves with the option “through the point”, and thus have an interactive preview.

with thickness 1 it works. if you increase, for example, 2 or 3, it fails. This kind of situation should be improved:
shell failed.3dm (180.7 KB)
(I would like to keep all these problems detected, no words in the wind … otherwise Rhino cannot grow well!). :wink:


I wish it could work the same way as in Solidworks. SW warns about self-intersections and after that gives you proper output.

I know that Rhino has the best tools to manually repair that kind of errors, but I hope self-intersections during shelling/hollowing will be solved in the same way as in Solidworks. Rhino deserves that.

You can notice that SW made it properly even with bigger thickness than Rhino. Rhino was set to 3mm and SW to 5mm thickness. Other thing is that interior surfaces were more clean in Solidworks.


Solidworks is a certainty in this kind of operations.
I hope that this command does not always remain the same from version to version.
Not much has improved since Rhino 5 … little little …

He problem is precisely the self-intersections that are generated when the thicknesses increase, in certain cases.
If the command worked with the logic “offset curve” it would be much better!


If I remember correctly, about 10 years ago solidThinking had a very smart way of dealing with self-intersections. It offered to replace every self-intersection with user-set radius fillet, thus making it possible to have shell thicknesses that even SolidWorks was incapable to achieve.


I don’t want to exaggerate, but if such shells can be executed correctly by less “professional” software, such as MOI, so to speak, then McNeel should think more about developing his cad.

I want to be confident: there are about twenty (between bugs and features) of files to the attention of developers regarding the “shell”.
Maybe in Rhino 8 there will be these limits … who knows, we hope!


MOI was made by a programmer who previously worked at “McNeel”, so the many similarities with Rhino are not coincident. :slight_smile:

Yes, but IIRC the “geometric kernel” used by MoI and that used by Rhino are not the same. MoI uses the Rhino file format (OpenNURBS), but not its geometric inner workings.

Moi and Rhino have different similarities, but they have different geometric kernel: the first is more efficient (see fillet, boolean, etc.), the second has many more commands, not least the SubDs.
The first costs 295 $, the second, triple.

With Moi you can develop 90% of the modeling of those feasible with Rhino, while having far fewer tools.

1 Like

I like use MoI3d v4 together with Rhino 7. It’s possible to move geo and curves with ctrl-c ctrl-v between apps. I like its simple GUI, snapping settings, polygonal exporter and mesh->nurbs conversion (which gives me better results than Rhino). I think in simple modelling it’s faster to learn and use than Rhino. I use both together but in simple models I choose MoI3d always. I use Rhino when MoI3d has problems with something and Rhino is best for fast solving surface errors. IT`s had to beat it with so many useful Rhino commands…

…but with shell command I`ve got the same bad result (it does not fix self-intersections) on both Rhino3d and MoI3d:

I write about it as about error but I know it’s only a lack of feature handling of self-intersections. I can understand why MoI3d doesn’t have it but I can’t understand why so good surfacing software as Rhino doesn`t have it yet. I hope that Rhino v8 will change it and we will see many improvements with existing surfacing commands, checking surface quality and with the shell/offset command (self intersection detection and solving problems with that area).

1 Like

Rhino and Moi are two nurbs modelers, they can’t have the performance of a solid/parametric modeler, so in operations like shell, offset srf, fillet and boolean they are not foolproof.

1 Like

If you are a legit software user you can always wish about some improvements. Software developer can simply not follow your wishes :wink: I think that wish won’t happen during 8 cycle but it`s always worth to dream :wink:

Rhino urgently needs:

  1. Better direct surface control point editing tools with UV arrows (one with a “Drag strength” of 100%, the other one with a “Drag strength” of 5%), straighten control point row based on the current view, etc… Alias is very much the benchmark to take inspiration from.
  2. Better “Blend surface”.
  3. Ability to build Bezier surfaces and “Rebuild surface” as a native part of its surfacing tools (Blend surface, Sweep 1 rail, Sweep 2 rails, Loft, Network surface…). Again, Alias with its “explicit control” option has a huge advantage in that regard.
  4. Better fillets.
  5. “Sweep 3 rails”.
  6. Better “Patch” (XNurbs is a very good patch tool).

And many others, but I don’t want to hijack the thread. :slight_smile:


It’s not that solid/parametric cad software somehow magically can do shells better than surface modeling software like rhino.
The offset surfaces of solidworks models are nurbs surfaces like in Rhino and need to be calculated mathematically - no difference in principle here.
It’s just that the big cats in MCAD solid modeling have very sophisticated modeling kernels that have been developed and heavily invested in over decades that do a better job in these areas.


The big Parasolid! :face_with_hand_over_mouth: :relieved:

I would add “better surface matching” to this list, even though great steps foreward have been made in Rhino 7.
Still what is mainly missing imho is control over endpoint matching conditions and blending the match.
(And explicit control over degree/spans)


Yes, several people started dedicated threads with requests about that over the years, myself included. “Match surface” still has lots of room for improvement, along with “Blend surface” that share many similarities with it.


I’ve found that free Design Spark Mechanical allows for better inner thickness than Rhino/MoI3d aka “pull inside” button. It is basically SpaceClaim engine. If you will search you will find also how to import and export geo with the free version cause in the official that feature is disabled (it’s needed to pay for that feature but that price is very low so it`s worth supporting that free project). To be fair it not allows for 5mm but thickness more than 4mm is ok.

When I created a curve in DSM from scratch that inner thickness with self-intersection detection was even better than on imported STEP. It`s almost without limits. I would like to see the same in Rhino 8.


So in DSM on imported curve with many CP that self-intersection feature is better than Rhino/MoI but with lower density of CP and curves created inside DSM that feature works awesome.

1 Like

Spaceclaim is based on the ACIS kernel if I’m not mistaken.
Not a surprise it is handling offsets better.

a voxel based shell tool is more in my personal line of thinking… they never fail…with quadremesh and subd to nurbs, we’d have a neat workflow.


Every feature polished, improved or added as new one to Rhino and related with thickening/hollowing /shell which is needed for prototypes production: mould creation, CNC, 3d printing is a good direction IMHO.


1 Like