Rhino 8 Development

Hey Kyle,

The SpaceMouse configuration of these isn’t bad.

I’ll have a look into what more is configurable/possible. It’s actually a feature of them that I neglect.

You don’t have to click, but make a gesture ‘through’ the pie segment.


I follow you, it’s a neat idea.

But…this can easily be done with GH.

In my decades of design engineering work I’ve always been using combination of half a dozen software tools to get the job done. Point here is I’d hate to see Rhino try to be all things to all people and end up a bloated mess instead of doing more awesome things that nobody else does, like Grasshopper and its many plugins.

For example, drawings. I’ve done a thousand drawings at least, and when I joined the R/GH cult this year it didn’t take long to realize that the drawing tools are not its strong point and I won’t rely on it for that. It would take a lot of McNeel resources to code all of the asme formatting, weld symbols, GD&T, and the multitude of possible variations and options in those and similar realms.

To me Rhino is not a tool to replace some other tools I have, it’s its own awesome set of tools, to be used along with a spreadsheet, word processor, graphics editor, and some crossover with say Solidworks and Blender for me.


I take it all back - it really is easy via Grasshopper!

WISH: Cater for STEP 242 format. Adopt as much of the standard as possible, both in and outbound, including all the linetypes, dimensioning, PLM and other data niceties. Then thoroughly check that the exported/imported file works WYSIWYG when brought into/out of the big-name solid modellers (Solidworks, Solid Edge, Catia, NX, Inventor).

1 Like

To take the workflow further, as I’m not sure what workflow you envision, many ways to do it. It wouldn’t have to be all GH, you could create and move all of the geometry in Rhino, just having the dynamic/parametric boolean operation done in grasshopper.


I like your post very much. I design mostly tuning parts for cars (few years). I’m quite fresh user of Rhino (half year). For sculpting I use Zbrush. For Subd I use Modo. For NURBS creation I’ve bought Rhino license. I use also MoI3d on the side of Rhino for rapid development (I like GUI and snapping tools and Subd->NURBS convertion). There is also free Blender for Subd creation so I don’t care about Subd features inside Rhino.

For me it’s good to have possibility to convert Subd->Nurbs inside Rhino but I will always import ready subd meshes to Rhino because I like to use tools for things where they are best. I don’t like sculpting in Modo and I don`t like polygonal modeling inside Zbrush.

I was quite suprised how many people still use old Rhino versions parallel to newest one only to have VSR plugin installed. I know that there a plenty copyrighted things but I`m sure that is possible to copy idea behind of it. Copying idea behind of product is always free. In my opinion idea VSR is to make surface creation easier with paying attention to surface quality. I think that idea should be digged more in Rhino 8.

I was also surprised that there is still no possibility to check surface continuity between multiple surfaces in VSR style (or other style which finally will show same thing).

I post same things on Modo forum and here. Please add more new and polishing features in places where your soft shine most: polygonal subd modeling in Modo and high-quality surface creation in Rhino.

I hope to see more surface analysis tools inside Rhino 8. I have xnurbs and during surface creation, you can see which continuity is on which edge. I think It should be possible to see in similar fashion inside Rhino 8. Like @TomTom said I hope to see more tools which won’t add more control points to not use rebuild all the time. I hope to see analysis tool like below. I hope it will happen (for now it`s partially possible in v7 but you should add pair of edges. I hope to see that after surfaces or object selection).


In order of merit:

  1. Support for all keyboard shortcut combinations with both modifiers, symbols and all other keys
    (shift + arrow keys, alt + `, alt + shift f1-12, alt + , ctrl + numpad 5, shift s, to name a few non-useable combinations in its current state). This increases useability of shortcuts, which Rhino is in dire need of to be able to function well with Sub-D workflows established elsewhere. It is pure user convenience, priority uno.

  2. Modal transforms for subd and Nurbs CV manipulation:
    I would follow Blender’s example where single hotkeys (without spacebar to confirm an action) do the trick for Sub-d. The advantage is in reducing input and thereby saving time. Moreover, you can intuitively affect geometry with shortcuts inside commands. In Blender, you can change a bevel width or the number of segments by typing “s” or “w”, whereas “w” can also be used to execute the move command outside of any local command environment (modal environment), such as the bevel command.

  3. This would also be beneficial to a dedicated Nurbs CV manipulation, Alias has a dedicated edit CV tool and Rhino should too (with handles and modal hotkeys).

  4. While I never used VSR, I did test Alias, their inspection tools are not even miles ahead, they are outside the solar system compared to Rhino. Please add Lighttunnel and isoangle diagnostic shading, dynamic surface to surface and curve to surface measurement analysis in addition to improving upon the continuity checks (that work in similar fashion to the aforementioned surface/ curve to surface analysis in terms of UI).

  5. There should be a cross-sections option for meshes, that helps in rebuilding scans by aligning surface hulls to the cross-sections. You should be able to specify the number of section lines to display. Yes, you can project curves to do the same thing, but that’s additional manual labour, it should be a display tool too.

  6. Zebra analysis on a per object base to build a surface on top of a mesh (scan). That way, surface flows of a mesh and of a surface can be compared. This also applies to building traditional surfacing based off a Sub-d conceot model to gain accuracy.

At the very least the devs should go over these Alias tutorials and copy whatever is not patented or otherwise prohibited from porting into Rhino. Have someone follow along these using Rhino, note the differences in workflow and especially note where things are lacking. If it cannot be achieved similarly, it’s just not good enough in Rhino. And no skipping over Alias tools that can be created using custom scripts or with a multiple step workaround either.

  1. Ease of history editing, there should be a single tool to edit and access every object’s history, regardless of which tool created the object (fillet/ blend surface or sweeps). There should be no need to use the same command and to type-in the history edit option to edit history. Not only does this require one to remember the tool that created the history, but it’s also a two-step process, which takes time.

  2. Parametric constraints to constrain geometry: being able to create relations between curves to be curvature continuous, perpendicular, parallel, coincident at a point, etc. like the major parametric softwares do allow for quick edits to geometry. Dimension the geometry, apply parameters on the fly, this kind of stuff.
    Rhino is losing out in this regard due to reliance on manual edits rather than having the computer do the work for you by just changing a few parameters. Grasshopper is nice, but limited, complex surfacing requires many geometric relations that will break easily if the curves are flipped it’s much easier to directly pick the relationships than to script them in. Also, when done correctly, they won’t break.

  3. Dynamic blocks that can be constrained to other geometry (like point 8), Grasshopper + Dynamic blocks is the best of both worlds.

  4. A display distinction between U and V hulls on surfaces: whether it’s a change of colour between the two or a dotted line vs a solid line, this helps telling the direction you need to move CV’s in.

  5. Node material trees, mostly to enable a closer 3rd party renderer integration and procedural shader workflows. That way you can, in the ideal world, use the same shader setup in Vray for 3ds Max and for Rhino or for Cycles in Blender and Rhino. This also requires Material X integration, OSL and perhaps some USD (Universal Scene Description).

  6. The UI is very old fashioned, darkmode and cleaner icons would be nice like Autodesk or Siemens have, heck even Dassault is improving on the matter now.

  7. As for drawings, Rhino is years behind on the competition. Is it fair to assume most people export the files over to do documentation elsewhere? Anyways, documentation should be tackled in Revit’s system of live updating views by drawing where a sectional cut, elevation level or 3D view is, it’ll create the 2D views for you in a separate browser. But I wouldn’t want to see any documentation changes as those would redirect resources from Rhino’s core development. Unless there are low hanging fruits so to say.

Imho Rhino should focus on its surface modelling core, that’s what it is used for most (my impression). Both in architecture ans industrial design. Grasshopper is the second or main selling point as it is capable of leveraging the strong OpenNurbs foundation of Rhino. But compared to parametric modeling tools in MCAD Rhino is tediously slow with a lack of a full history compliancy and a lack of constraints. In the mantra time is money, that’s hard to justify. It would be a good user selling point to have automation (of modeling) as main target. The easier and quicker the software the more likely people will prefer using it over the competition.
At the same time, high-end surfacing (class A, to drop the buzzword) it lacks inspection, modeling and precise Nurbs editing as well as the sometimes higher CV count compared to competitors. Nevertheless, for high-end surfacing, it’s mostly a shortcoming of tools to automate workflows to be able to use more history capable tools, to crown surfaces, to inspect them more easily. So please address these weaknesses for Rhino to strengthen Rhino’s core or it’ll be the swiss army knife with blunt knives and tools (i.e. a jack of most trades and master of none).


Marking menu so Great~ :heart_eyes:

All things we’ll never see … or we’ll have to wait for Rhino 15! :wink:
I believe version 8 will be a refinement of Rhino 7, with a few minor additions here and there.
Let’s not expect miracles or hundreds of news…

I think it`s much easier/faster to develop a marking menu or change some small GUI things than to polish/refine surfacing commands and extend surfacing analysis tools.

Thanks @Intuos for your post. Thanks also for pointing out USD format. It’s open scene format which can handle curves and surfaces (together with polygon geometry data and materials info). I’ve seen on some Modo release docs that Modo may have the support of curves and surfaces inside USD import/export. Houdini already supports it. I think Blender may also support NURBS curves and surfaces through USD export/import. I’ve attached USD file exported from Houdini 18 which contains NURBS curve. You may open that file in notepad and change values as you want. It`s easy also to write the external plugin with using that.nurbs_curve_usd_file.zip (780 Bytes)

For me its a big limitation that I can`t use Rhino curves in Modo but it’s Modo fault. I hope USD format will blend those borders between polygon and nurbs software.

I know Nathan Letwory “Jesterking” is working on a plugin and futher exporting options from Rhino to Blender specifically.
It might be nice if Mcneel could contribute to Blender by helping to implement openNurbs in Blender though. And to use Blender to tesselate the geometry.

1 Like

Future in my opinion is a blending borders between software (CAD & polygonal) and use those both worlds seamlessly. Every addition to blend those borders is a BIG plus IMO.

Is there any research to show how many distinct commands can be called by a marking menus scheme?

not sure if there is a limit other than screen size… Autodesk has 3 menus depending on which keys you press keeping the individual menus from getting huge.

In Blender you can map marking menus (pie menus) to hotkeys, that way you’ll never run out. You can have nested pies and pies with buttons (Blender addon Hardops and some pies in Machin3tools, such as the cursor pie have those). I would add a customisation option for users if this gets implemented though.
Alternatively being able to call a command by a letter (preferably first for a specific command and or numbers for each pie section is helpful too (just make sure it’s underscored).
Though it looks nice at first I’m not sure its all that healthy to do so many rapid flicks. There’s a reason some Alias users complain about RSI.

E: Fusion 360 has a right click menu + marking menu in all quadrants except the south where the menu resides.

You can do it with the help of Options command:

These improvements are would be useful and easy to implement. Several years ago I proposed standard icon colors:

Rhino icons are miniature pictures of objects. It seems that colors of the objects are random. I propose a few rules: points are red, lines are green, surfaces are blue, isocurves are yellow, meshes are magenta, imaginary lines are cyan, solid edges and text are black, background is white. Original objects have light colors. Final objects have dark colors.


I hope there is a command in Rhino 8 that can eliminate the rounded corners of stp/step files

Yes, please!! I’d like to be able to use the numpad for shortcuts, as well as shift/alt combinations without ctrl. Any good reason why this shouldn’t work?

1 Like

Regarding Dark Theme :slight_smile:

1 Like

Unless I’m wrong (which is likely) the reason all those other apps and ipad apps (I assume you are talking about Shapr) handle these cases so well is that they are built on a mainstream solid modelling kernel. Rhino’s is primarily a surface kernel.

Wasn’t there a plug in for Rhino at one point that was based on Acis or Parasolid for Solid Modelling functions?

The upshot is McNeel could pull a VectorWorks, who had similar issues using a “non standard” kernel (so solid modelling was crap), and add Parasolid to the mix. Now The Parasolid based Vectorworks imports all the MCAD stuff perfectly, shells and fillets like most systems and exports back perfectly as well.

Of course this will require licensing the kernel from Siemens, and a major overhaul of the app “under the hood”. Is it worth it?

Totally depends what the roadmap is for Rhino. Of course its not that simple. I remember the Ashlar guys back in the early 000s talking about switching from ACIS to Parasolid, or running a dual kernel system for specific tasks. Actually Ashlar is a good example of what a kernel based Rhino might be like and what not to do.

Ashlar tried to compete with Solidworks, introducing D-Cube based sketcher (badly), and always pushing out the latest build of ACIS (buggy). Suffice to say their drafting environment was rubbish (ironically as the 2D Vellum was so good). I do see parallels with Rhino there (the drafting environment). Also maybe look at SolidThinking Evolve. Ashlar Cobalt and Evolve are very similar in toolsets and target market. Does Rhino want to muscle in on that style?

If it was an easy fix, add Parasolid to some commands (booleans, shell, fillet etc). Maybe gradually build up integration over several releases, like Vectorworks did.

But of all the suggestions I’d really like to see variable edge creasing in Sub-D that can actually translate to other systems. In that respect, Creo is your go to example. And I would dearly love to stop paying those subs charges :grinning: