Strange claims

Hi developers! I just took a look at the “getting started” section and I must say I’m a bit disappointed with some of the statements/claims in the Rhino section.

However, first I’d like to say that I really appreciate all the work you’ve done for bringing 3D-modelling to the iPad. Shapr3d is a nice and intuitive tool and you are obviously listening to your customers. The program is also getting better all the time. This is all great!

Now to the strange part I was referring to. In the mentioned section you claim that “… in most cases models created in Shapr are more accurate than Rhino, thanks to the underlying industry standard modeling engine (Parasolid).” I’m sorry, but this is not true. Perhaps nice advertising, but not true. Rhino is as accurate as your computer and floating point mat is. If you have inaccuracy in the Rhino-model it’s most certainly due to user error (of an inexperienced user) and has nothing to do with the accuracy of the program. It’s true that Rhino allows you to change a lot of parameters witch puts the responsibility to the user. For instance… modelling tolerance is adjustable in Rhino (in Shape it seems to be hardcoded to 0.0001 units). The possibility to change different parameters opens possibilities that you don’t have with other programs, but also means that you need to know what you’re doing. That’s only one example, but you get the picture…

And this… “This means that with Shapr it is much easier to create manufacturable, watertight models.” If we’re talking about simpler, boxy models - then yes - this is true - for a beginner! On the other hand - if you’d like to create some advanced, free form models you might be totally out of luck…

Lastly… This is true, but doesn’t tell the whole story: “… Rhino is a surface modeling tool, Shapr is a solid modeling tool.” Well yes, in principle - but Rhino is actually both!

However, I still like Shapr for what it is - and hopefully will be - but I would have hoped that these inaccuracies in the text (pun intended :wink:) wouldn’t have been there. I still like to be part of the development and make Shapr even better :+1: So, thank you and I’m sorry…

(Rhino-user since 1997)

This is true. Rhino’s only representation is NURBS while Parasolid supports lots of regular canonical geometry types, like cylinder, plane, torus etc. This is one of the reasons why Parasolid is more accurate (and more often much faster) than Rhino. This is not marketing bullshit, but math, @Koko_Shapr3D could tell more about this.

Every modeling tool has it’s strengths and weaknesses. You can’t model everything in shaper, but you can’t model everything in Rhino as well.

And more freeform tutorials to come (and more improvements in freeform modeling in shaper).

Rhino is not a solid modeling tool. This is a technical term, that refers to the underlying technology, and does not mean that you can’t create solid models with Rhino. You can create solid models even with 3DS max. Solid modeling refers to a modeling technique that is mostly based on creating solid bodies, applying modifiers and booleans on them. Solid modeling does not really “compete” with surface modeling - it’s a different technique. It has drawbacks (eg. super-organic, freeform stuff can be hard to create, but not impossible), but just try to move a hole in a body in a surface modeler - it will be very labour intensive. Also, you know that creating a blend on any more complex solid bodies in Rhino will require lots of labour intensive manual work.

That being said, I am a Rhino (and Grasshopper fan), and we are not claiming that shaper is superior or inferior to Rhino, but I believe that the comparison on that page is valid, and I take responsibility for every single word on that page :slight_smile:

Rhino also have special geometry for describing cylinders, toruses, etc. with weighted control points, if that’s what you mean?

So… where is the difference in accuracy? When intersecting free form shapes? Something else? What?
I have personally had geometry from Solidworks that has had to be repaired in Rhino due to inaccuracy, bad trims, etc.


I didn’t use that word… Anyway - I was referring to the phrase “industry standard” which to me sounded a bit like marketing hype without much content, but ok…

That would be nice, because - frankly - I’m not buying it.

I agree. This is a good thing, as a designer doesn’t have to be tied to one tool.

I might almost disagree here, but whatever…

I know those tutorials. They only show that you can create curved models with blobby shapes - and eye-balling all the important stuff. That’s not how I would design a chair - which is my favourite type of product modelling, by the way, and something I have done - and do - for a living. You need specific dimensions, angles, interacting shapes, etc. when designing a chair - starting from the very importing aspects of ergonomics. I understand that these tutorials are perhaps more a proof of concept than real product design tutorials, but I haven’t found an easy way to really try to design a chair from scratch with all the important aspects of ergonomics, materials and, for instance, acoustics considered.

Good, thanks!

I know this, of course, nothing new there. Rhino is a surface modeller and you can very easily create solids in Rhino. That’s what I said in my original post (“This is true, but doesn’t tell the whole story”).

I know that and I agree.

That’s why I have talked about this in other posts. Why not trying to make Shapr a solid modeller with easy-to-use free form modelling tools? I know this might be hard at this stage of product development, but it’s also a matter of developer preferences and ‘user-targeting.’

Yes, it can be frustrating sometimes…

Ok, in that case I really would like you to elaborate, because as I said, I’m not buying it.

Sorry for giving you a hard time, but making a bit negative (and perhaps not so accurate) claims about another modelling program is not the way to go. I think many Rhino users would agree.


There is nothing to buy about this, this is really just about the way how Parasolid was built and Rhino was built. By canonical geometries I mean that in Parasolid a sphere is a sphere (a point + a radius) while in Rhino it is a NURBS surface, that makes it much harder to calculate accurate intersections, that is the basis of a CAD (boundary representation) engine. There is nothing to believe about this, it’s hard core math, well documented in thousands of papers. This, of course, does not mean that you can’t achieve your desired accuracy in Rhino, especially if you know what you are doing. Rhino is a super capable, very powerful tool.
Parasolid is by far the most important CAD engine nowadays, it fuels around 60-75% of the active solid modeling CAD seats. SolidWorks, SolidEdge, NX, Microstation, Vectorworks and many other CAD systems are running on Parasolid. So I believe it is fair to say it is industry standard. If you look around you right now, it is very likely that most of the things you see (and has been designed in a CAD system) went through Parasolid during the design and manufacturing process. Even your iPad Pro and your Apple Pencil.

Ps.: we have never said that we are not planning to add easy to use freeform modeling tools. The edge move feature is a first step in that direction, but it’s really not that easy :slight_smile: Btw, meanwhile using the replace face tool you can use your surfaces created in Rhino to replace faces in shaper :slight_smile:

Also, bad geometry from sw to rhino: this is of course not impossible, but it is much more likely that the issues you have faced were due to the data translation (conversion from Parasolid to Rhino, I suppose over STEP) rather than problematic geometries from Parasolid. Data translation between CAD systems can be often problematic, and if you face an issue like this, it often makes sense to try another format eg. X_T can be a very good choice if STEP fails.

That’s exactly what a default Rhino-sphere also is.

Nope. You can rebuild it to an approximate NURBS surface (“sphere”), if you want it to be deformable, but that’s not the default.

That’s true for mechanical CAD (which actually seems to be your target group), but not for the visual design people. These guys are using CAD programs like, for instance, Alias, ICEM Surf and Rhino. I really hope you’re interested in this group of designers too…?

That’s a one-sided, simplified truth. The product design process almost always start with an idea (a visual idea - and later, technical) and sketching with pencil and paper or/and digitally in, for instance, Concepts (I use both). Then you import the idea (as a pdf-file, for instance) to Alias, Rhino or whatever and the designer (industrial designer, interior architect, architect - depending on the project) makes the final (visual and technical) design in these CAD programs. After that another group of people (engineers, CAD modellers) makes the final technical design in the CAD software you mentioned. During the design process the digital model ‘bounces’ back and fourth many times before the final design is reached.

Yes, I’m aware of that. That’s good.


I am almost 100% sure that Rhino does not store these geometries as canonical geometries, but I asked it on the McNeel forum, and I will post the answer here.

I don’t know what you mean by “canonical” and that was not what I said. I was referring to your statement “a sphere is a sphere (a point + a radius).”


Yes, this is how you create a sphere in Rhino, with a point and the radius. But I am pretty sure that from that data, it will create a NURBS surface. So in the end, the representation under the hood will be a NURBS surface, and not a point and a radius.

As I said earlier it’s a surface with some of the control points weighted (weight less than one in this case) and to my understanding the result is as accurate as it can be and does not justify you to call Rhino ‘less accurate.’ That was the essential claim that first caught my attention.


No, this is not true. Imagine the following two cases:

  1. Your representation is based on 1 point and 1 parameter (radius)

In this case calculating any point of the sphere will be super simple, it will involve only a few floating point operation. Thus the cumulative error will be very very small.

  1. Your representation is based on NURBS (bunch of polynomials)

In this case, calculating any point will involve a lot of floating point operations, multiplications, divisions, and sums. Thus the error will be higher (but still can be very small with a proper implementation), and since much more floating point operations are involved, most of the operations will be significantly slower (but in most cases still acceptable).

Parasolid does the first. Rhino does the second. The benefit of Parasolid’s implementation is that it is super fast, but implementing it was incredibly hard. The benefit of Rhino’s implementation is that it was easier to implement, but in some cases it will be slower, and often less accurate. Does this matter? Sometimes it does not, sometimes it does. If you are designing for example an object that is 10x10x10cm, and you have to design it with 10um accuracy, well, then it can be a problem. If you are doing woodworking, and 0.1mm tolerance is fine, then it does not matter. It depends on your use case and your needs.

Huh, interesting, so the Rhino guys say that they do have canonical representations for some of the geometries (but not as extensively as Parasolid):

So indeed, what I was saying was not entirely correct, and we will update the “accuracy” part of the description.

I just read Pascals reply, yes. I know I haven’t been able to explain the math as thoroughly as I should have, but I think I have understood the essence of the matter - and that was what I have tried to explain. Not very successfully apparently… There should be a page in the McNeel Wiki, where it’s explained, but I didn’t find it.

Good to know that you will update the description. I think it’s essential that you don’t ‘scare away’ potential customers by making a bit negative sounding claims on your website.


The only page that talks about this is this:

Unfortunately this is highly inaccurate (haha), and basically claims that Rhino is entirely NURBS based, that seems to be not true.

There it is. Good find, thanks!


There you go, I fixed it. Thanks for the feedback.