A new version of Rhino is a rare and unpredictable occurrence and therefore always welcomed by its broad, devoted user base. Rhino 7 is probably the most feature rich update in its history. AEC Magazine talks with company CEO Bob McNeel and Scott Davidson, business development
Rhino occupies a very special place in most AEC firms’ armouries. Despite the success of the multi-purpose 3D CAD tool, its developer, Robert McNeel and Associates, doesn’t operate like an American corporation. In fact, it is the very antithesis of how most CAD software firms function.
McNeel is employee owned, privately held, and these things combined are probably the reasons why the company is so loved by its customers. Of course, it’s also low cost and an absolute monster when it comes to defining complex geometry.
At the heart of the development ethos is the concept that Rhino is a generic modelling tool, neither skewed towards manufacturing nor architecture, and equally applicable to both. While new features may provide core functionality, such as mould design, it’s not essentially a full or dedicated feature set, and other developers or customers are welcome to develop on top.
Rhino is just as at home in sneaker development, jewellery design, auto body, CAM, as it is in ZHD or Foster + Partners – the only rule being that the geometry it defines can be manufactured.
As the AEC market moves towards digital workflows, and digital fabrication starts to become more common, Rhino’s importance is becoming even more apparent.
In addition, there is Grasshopper, which sits inside Rhino and has become the single most used generative design platform, driving everything from simple Python scripts to defining the surfaces of the most complicated curved buildings being manufactured today.
However, defining geometry isn’t Rhino’s only superpower. With broad support for industry formats and the unique ‘Rhino.Inside’ development platform, the power of Grasshopper and Rhino geometry can actually be used as a glue to link BIM systems and drive geometry creation in popular BIM modellers that lack the generative ‘chops’ or are notoriously unfriendly in OpenBIM environments.
Rhino Inside has been in development for some time and Rhino 7 sees the official release of Rhino.Inside.Revit, which brings Rhino and Grasshopper into the Autodesk Revit environment.
Rhino.Inside also works with ArchiCAD, Unreal Engine, Unity, Blender, BricsCAD BIM, ACCA Edificious and many others. It’s a potential invisible wire harness for all data between BIM and / or viz systems.
Rhino 7 includes a host of other new features and is arguably the biggest release in the product’s history. These include SubD (SubDivision) surfaces, which look to be great for exploring organic, manufacturable shapes in architecture, a new display pipeline, enhanced drawing creation, better rendering and easier access to Grasshopper scripts. More details can be found in the box out at the end of this article.
With such an epic release, AEC Magazine caught up with company CEO Bob McNeel and Scott Davidson (business development) to dig a little deeper into the feature set of Rhino 7, together with some exploration as to how Rhino is developing into a collaboration and data sharing tool within the broader AEC space.
AEC Magazine: We’re finding that architects are getting increasingly frustrated with BIM tools because they want to get back to designing, as opposed to getting bogged down in detail documentation. They want design fluidity through applications from various providers. Rhino.Inside is already making a mark here.
Scott Davidson: If you look at the philosophical BIM process, what we’re seeing is very much a move toward wanting the freedom to design and not to worry so much about the details of Level 300. I know it’s important at some point in the project, but it’s not important now.
And we’re also seeing where part of the model might be at a LoD 300 already, but a different part might still be an LoD 200 because not the whole project gets done at once. The only reason this became clear to us is because of Rhino.Inside.Revit. We are starting to see how people are using the two applications. Customers want to be able to use Rhino longer in the process, get more analysis, more data, more freedom to design, and then they want to get it over to Revit quicker.
Now, what’s also interesting is I’m finding many times, they want to take parts of the building out of Revit and they want to put it back into LoD 200.
It’s beautiful. People can now literally, with Grasshopper, wire that system up and as the project moves forward, they can wire the relationships – those relationships are dynamic.
A stupid, but good example would be that the floors are pretty set, you’re in design development, but you’re still kind of messing with facade. In this case, we’re feeding floors into Revit. And they’re real floors, they’re super hard coded. The floors may live in Revit and we can pull those floors into Rhino dynamically.
If we are just doing the façade in Rhino – here’s my maximum span and my material – I can embed that in the Rhino model and have that automatically fill into the Revit model. When I’m ready I can have it fill in. As I’m messing with the façade in Rhino, the Revit model is updating, and the drawings are getting done.
Bob McNeel: Yeah, once we move into the same memory space, we share the two SDKs (Rhino and Revit). It’s possible to write lines of code in Python, where one call is using a Rhino geometry function and the next call is writing something to the Revit SDK library. We’re deeper core with Rhino.Inside than Dynamo is.
It’s almost too hard to get your head around what’s possible. I mean, we’ve even gone as far as writing a widget in Grasshopper that runs a Dynamo cluster.
SD: Yes, you can actually drive a Dynamo definition as a component in Grasshopper. A whole Dynamo one dimension is a single component Grasshopper. But its integration is crazy. I mean, the workflows that are possible are just nuts.
You do have to understand both. That’s part of the problem. There are only a few people that understand Rhino, Grasshopper and Revit to the extent in Revit API where this is possible.
BM: Of course, we’ve had this in the field for a while, but what we’re basically finding is those internal teams are the ones actually using this. What they’re doing is they’re actually just rolling out new tools to their user community of Revit users. And these Revit users may know nothing about what’s happening underneath. A user may think they’re working in Rhino and another one may think they’re working in Revit. But they’re actually working in this combined product.
Another thing that may not be obvious is that basically all plug-ins to Rhino and Grasshopper now run in Revit. And every Rhino plug-in, including CAM products and our development partners’ applications, they can all run in Revit.
SD: Also, the 49 file formats that Rhino reads and writes…. now Revit reads and writes those file formats too. It’s the biggest new version of Revit they’ve ever had!
AEC: We are amazed by how many features you’ve crammed into this new release. It’s like three releases in one! What were you thinking about when you decided on this feature list? Is it just a case of a whole load of things that didn’t make the previous release overlapping?
BM: It was a timing thing. Part of it was that we needed to get the SubD stuff up to par. A lot of that was core work that had to be done by very small group of people just because of the type of work it is. And so basically, it allowed other people to work on all the other stuff, which just needed to be hooked up. It wasn’t inventing stuff from scratch, like the SubD project was, which was really going on for about three years.
This is core geometry. What that means is that you touch every Import/Export function, display pipeline, the picking engine, plus, then you’ve got to do all the core geometry work. And, the SubD stuff is a classic problem.
The classic SubD implementation is basically just a mesh or refined mesh at various levels. For the Rhino community, where everything’s got to be at manufacturable precision, we had to develop the core technology to have the limit surface be a spline surface, not a mesh. That was the first bit of work, doing the robust math for that. While there are many (research) papers on how to do it, it turned out most of them had a lot of errors and actually didn’t work. I mean, they were just proof of concept.
But then the other piece of it, once you got that calculation to work reliably, was that it had to be fast as we needed to build a system that allowed push / pull on a SubD object. That was actually a spline surface that would change and update as quickly as a mesh-based version.
AEC: So how much better is this than T splines?
BM: Well, it’s better and it’s different in a couple ways. There’s no patents involved, so that means that we can publish this, we can let people play with it, we can expose it in SDKs [Sofware Development Kits], we can put it in open source projects that we support.
In terms of data structures and stuff, our SubD is actually compatible with Pixar’s open SubD. So, if you use the same control net from our SubD, and hand off to another open SubD project, they’ll get the same limit surface with their calculations.
Now, the other system’s output may be a mesh, but for downstream applications like rendering, STL printing and, of course, animation and all of that stuff in the movie industry, they are identical, so there isn’t a loss going that way.
But on the same hand, it can go the other way as a spline surface, so you can export it as a STEP file or whatever, and it’ll come in as ordinary B-rep.
AEC: But then you can also turn it back into a SubD on demand?
BM: You can in certain cases. It depends on what somebody does with it later. If you take a trimmed B-rep, something with round holes, a typical mechanical part, there’s not an obvious way to always go back. SD: Every SubD has a NURBS equivalent, but not every NURBS model has a SubD equivalent, because they’re two different geometry types. But going back the other way, you know, that’s where QuadRemesher comes in. We can QuadRemesh and go back to SubD. Now it’s a different SubD, but it’s close to the NURBS.
While you can take a mesh and QuadRemesh it and go to SubD, and therefore go to NURBS, there is a limit to how damaged the mesh can be. We don’t have all the tools to do mesh repair in all cases.
BM: We’re not dealing with crap scans. I mean, that’s a whole another ballpark.
SD: If you have a mesh, and the mesh is somewhat well defined, we can get it to SubD, therefore we can get it to NURBS. That makes sense. The whole idea that you can repair a mesh is not exactly how we would put it. It would be more like, ‘we can take a mesh and get it to a SubD using the QuadRemesh technology’.
And QuadRemesh is really the glue that allows us to go from mesh to SubD to NURBS. And in fact, many times from NURBS back to SubDs, if you need to do that.
AEC: Rhino 7 was the first time the Windows and Mac versions were released on the same day. What’s changed?
SD: I think part of getting a shorter timeline between multi-platform releases is that we’ve gotten to the point where we’re not writing the Windows version, and then releasing it, then turning around and having to essentially write the Mac version again.
BM: Yeah, we build from the same source code now. And a lot of that work went on with Rhino 6.
AEC: What about Apple’s new M1 processor? Will you be supporting that in Rhino 7?
BM: There’s two parts to it. There’s support for Apple’s Rosetta 2, which is actually pretty impressive, in that they actually convert Intel code into native M1 code. The problem with it, of course, is it’s new, and they don’t have all the edge-cases covered.
Another part of this, for us, are things like we use OpenGL on both platforms and Apple has basically abandoned that now, for their own ‘Metal’. So, for us to really support that, we need to re-engineer our Mac display pipeline for Metal, which is something we’ve had on the burner for a while. But that’s a big project; it’s not trivial. So that’s one piece of it.
Then the other one for us, is to build our own native version, which means we can do a better job of fine tuning the code. The problem is, like a lot of software, we’re reliant on a lot of people, for example, all of the .NET support. We use that on both platforms and that means we have to wait for Microsoft to release their whole ecosystem. And who knows how quick that’s gonna show up? And when it shows up it’s not going to be 100% on the first day.
I’m guessing we’re a year out on a full-blown Metal build of our own. Hopefully, we’ll have a Rosetta compatible version in the next six months, but we still have some things we’re not sure about, but we’re working on it!
As we have been working through it, we run into things, and we talk to Apple about it and it’s nice to work with Apple, because they’re actually great. I mean, first of all, they’re big Rhino users, so that helps! And then the other one is they actually understand supporting people going through this, they’ve done it before, they’ve got the infrastructure and they put smart people on it. They don’t put bullshit barriers in the way. While sometimes they’re a lot slower than you hope, it’s fine.
I can see why they did it but, timing wise, it was kind of a pain in the butt for us because we got our first pre-release boxes just as we were starting to wrap up Rhino 7. So these machines basically sat on the shelf. We’ve only got a couple of people that have had time to look at it.
Everybody is excited about it right now, of course, because, you know, Apple’s curated hype, but the pain for us are people buying M1 boxes right now and expecting Rhino to work.
AEC: You’re not even approving it for use with the Rosetta emulation, you’re saying it is not supported?
BM: We’re just telling people it’s not supported. I mean, we’re hopeful that we can have something more exacting to tell people in the next few weeks, so sometime in January [Ed this interview was done in December 2020], we’ll be able to actually say what the limitations are and what issues we are having to deal with. We may have to do what we did with the early Mac versions, which is say, ‘hey, this is Rhino but these features are missing’.
AEC: You’ve added some additional 2D drafting features to Rhino 7? I thought you were leaving 2D to other applications?
BM: My view is we need to let people stay in Rhino as long as long as they can. It’s not that we feel like we need to replace something else that people are using. If people already have a solution out there, I mean, as long as AutoCAD or AutoCAD clones are out there, I don’t think we need to do drafting.
Some of those things are cheap, some of them are basically free, and they are great drafting tools. That said, of course, you know it’s a time consuming bump in the process for customers.
The one place that we can get away with doing drafting, I think, is what I would call shop drawings – put enough stuff on a piece of paper so you can hand it to the guy in the shop, and maybe he understands what you’re talking about, even if you’re also sending him the G code. He’s still got a picture he can look at, as maybe he’s not able to look at the 3D model. You’ve got to give the people those tools. Consequently, we’re continually moving the bar up with each version.
One of the things which is not really a drafting tool, but sort of fits in that category of toolsets, is single stroke fonts. Yeah, these are used everywhere, all the laser guys don’t want to burn the hell out of things, and welding robots that do bead welding. There are all kinds of applications downstream that aren’t really 2D drafting tools, but they’re 2D, right?
We’re always kind of bumping into those corner cases and we try to remove them because somebody’s exporting this stuff out of Rhino, they’re putting it into some kind of illustration or drafting programme, and then they’re trying to figure out how to get it off to a machine, or out to the shop.
AEC: For Rhino, is injection moulded parts and toolmaking an important market?
BM: Yeah, that’s another use case. The essential geometry calculation to figure out where those mould lines go, so parts will come out. It’s a heavy-duty math problem and to hand that off to some other product, especially when the shape is freeform, is not something that that, you know, anybody but a bunch of math geeks can figure out.
We’ve actually had the math in there to do that for a while and finally one of our guys pointed out that they keep having to help people figure out how to use this stuff. We’ve just wrapped it up within a user-friendly interface.
We’ve got customers in shoe companies and toy companies building these little plastic parts. And they have hundreds of people just working on the mould. The shoe folks tell me that for every designer they have in Germany or Portland, Oregon, they’ve got somewhere between 60 and 600 people developing the moulds!
Just think about shoes for a minute. Shoes are the worst for a number of reasons. The fact that you’ve got to do the left and the right shoe and then you’ve got to do all the different sizes. And what most people don’t realise is shoes don’t scale. You can’t go from a size six to a size nine. They aren’t even on a linear scale and even.
And then another layer of complexity on top of that, is these things are made from multiple materials. What people don’t realise is that some of the materials expand when they come out of the mould while some of them contract.
AEC: Laser scanning is now much more in focus and you’re enhancing point cloud support. But you’re targeting large point clouds, which I’m guessing is for architects?
BM: That’s another area where we just tweaked things a little bit. Luckily for us, there’s also still some third parties out there that are working in that area. I just saw some new stuff from EPFL (The Rhino plugin Cockroach). They had a big research project going on and they just released a whole suite of tools in a Rhino plug-in to deal with this kind of stuff. The great part about the universities – they get a ton of money from the EU, research funding, and then they release most of it to the public. So, somebody can build products on top of Rhino, or use pieces of it. I would avoid promising anybody anything in that area.
AEC: How about rendering tools?
BM: That whole area is such a rat’s nest of stuff. We’ve always had a rich environment for plug-in rendering in Rhino. The first thing with Rhino 7 was to replace the rendering tools that we had in Rhino and replace the core rendering technology with Cycles, which is what’s in blender. And that just opens up a whole bunch of capability.
One of our guys is on the core team for Cycles in the blender project, so he’s going back and forth between what he’s implementing for us plus, making sure its compatible with a bunch of stuff, particularly on the material side, which is looking pretty good.
SD: This is good to talk about because it’s a pretty sophisticated advancement and not just as to what we have in Rhino. We have Cycles and Cycles is modern and supports a bunch of modern technologies like denoisers, right? Everybody has come out with denoisers lately – Nvidia, AMD and Intel all have their own denoisers, and we support all three. It takes renderings from 20 minutes down to two! Kind of crazy numbers.
Then you’ve got the materials. One of the things that people have asked for, for decades, is can I have compatible materials across multiple rendering tools? PBR (physically based rendering) done by Disney and Pixar and whoever else, is a step in that direction. We support PBR materials.
Now, PBR is really great, because you can do a lot of sophisticated maps and we can take the bitmaps and textures from another product and use those in ours. But, there’s some kind of unspoken advantages here such as Adobe Substance Designer outputs PBR materials.
So now you can use Substance and read Substance materials into Rhino and use them in your renders. You can also use Substance as a kind of a 3D painter. But if you want to talk about AR and VR, and virtual worlds, and all those things, if you look at Unity, or Unreal, or Nvidia’s Omniverse – they use PBR materials too!
Now, we’re pushing out to those, and have ongoing work to be compatible with Enscape, TwinMotion (which is free for Rhino users) and all of those type of tools. Rhino 7 is very much a play into all of this but it’s also a lot of the foundation work that’s going to play into AR/VR virtual worlds. We want to play, and we want to play well with all these tools. We want to be able to store their information and to be able to write their information out. Enscape is a great example; it’s very important and very popular.
AEC: So what is the AMD ProRender play for you then?
SD: ProRender is there. It’s AMD’s play into using their GPUs and we can support all that stuff. It’s one of our strategies and you’ll see this throughout Rhino 7, is that we are really trying to be compatible with the SubD engines, PBR materials, the way we can get in and out of other products. We are trying to be a better player on the world stage of CAD information. The possibilities are crazy, whether you’re a movie artist, a jeweller, or an architect, all have different platforms to work with.
As renderings change from the static image to the virtual, AR, and then at some point totally immersed, different universe (you know, aka the Unreal, Omniverse etc.), we’re working with all those partners to try to push forward and let people play.
Rhino 7 – technology highlights
SubD surfaces SubDivision surfaces are nothing new to the world of CAD, but the Rhino implementation, new for Rhino 7, is incredible, dynamic and totally interactive. This is great for exploring organic shapes quickly and removes the faceted nature of complex geometry meshes. McNeel’s SubD surfaces (pictured above) can be converted directly to manufacturable solids, derived from scans or meshes, as well as translated into NURBS.
Rhino – QuadRemesh
Following on from SubDs, Rhino now has a very powerful command called QuadRemesh, which can generate quad meshes from pretty much any group of surfaces, solids, meshes, or SubD surfaces.
Display pipeline
GPU development is the one constant in the computer world that continues to drive acceleration of 3D software. Rhino’s OpenGL display pipeline has evolved to make use of the latest GPUs, shaders and graphics memory. The 3D display is now even more silky smooth and handles larger models, shaded working views, unlimited viewports, draw order support, clipping and full screen. Both Windows and Mac versions of Rhino 7 are significantly faster. McNeel claims up to 10x performance improvement in wireframe and shaded modes.
Documentation
Rhino is predominantly a 3D modelling package but McNeel occasionally enhances the drawing capabilities as the company recognises that there is still a need to provide drawings for fabrication. Rhino 7 has a Layouts panel, which simplifies many of the tasks associated with layout management, which was perhaps not as easy to use before. Gradient and transparent hatches have been added to enhance 2D drawing layouts and can be accessed from the horizontal tab below the viewports.
Rhino – Grasshopper
A new GrasshopperPlayer command lets the authors of scripts distribute their Grasshopper files to run directly from the Rhino command prompt. The concept here builds on the idea that many firms have tool makers for projects and design teams, and this is easy way to include non-Grasshopper users in computational design.
Clash is a Grasshopper component that can search through any selected objects to find objects that touch each other. One wonders whether, that if this was combined with Rhino.Inside.Revit, it would be a quick way of clash detecting without ever really leaving Revit.
Rendering
Rhino has always had a range of options when it comes to rendering, either out of the box, or through the broad developer community. With this release, McNeel has sought to take the latest technologies for collaborative working with photorealistic modelling. Rhino 7 natively supports PBR (Physically Based Rendering) photorealistic materials, with emerging standards being backed by Pixar and Adobe, they are becoming the standard for material libraries, content authoring and scanning applications.
Similarly, McNeel has added support for the latest swathe of denoisers in Rhino 7, improving the quality of images and rapidly decreasing render times.
