Rhino as a viable candidate for replacing Solidworks

Hi everyone,

I’m currently researching other software packages to replace our solidworks environment.
I’ll spare you the details as to why we want to make the switch and what it is we’re developing, but I’ll will tell you what it is we’re looking for in Rhino.

I know from personal experience that Rhino gives you amazing flexibility with organic shapes and user defined buttons and scripts. I don’t know however Rhino’s capability’s when it comes to making assembly and part drawings. I’ve seen the list of ‘new in Rhino 5’ drafting and this made me curious.

When making assemblies in Solidworks, we give a part no. and description to every individual part so that when we make an assembly drawing we can click the button autoballoon and Solidworks automatically annotates all parts in an assembly. From there we will rearrange the balloons nice and tidy and finish up the BOM.

Is it possible in Rhino to autoballoon all parts in an assembly and have them display certain user defined information?

Thanks,

Rick

1 Like

With some scripting that could be done, sure. Of course Rhino isn’t built on a part/assembly paradigm, to get a similar structure you would separate parts in different files and assemble them as linked blocks, I’ve made a bunch of scripting related to such issues. It would depend on what you’re doing if it really makes a ton of sense to try to switch from Solidworks… As a Rhino salesman, trying to get a whole shop to totally switch from Solidworks to Rhino instead of adding it to their toolset, I would consider that a tough sell, unless the geometry was especially suited to Rhino and/or there was an opportunity with Rhino’s incredible customization to utterly reinvent your production processes.

SolidWorks and Rhino are really intended for different uses. They have a little overlap but not a lot. The combination of both is a far better and wide reaching set of tools and capabilities.

1 Like

Hi Jim,

Thank you for your quick reply. Let me elaborate a little. We do a lot of surface modelling in Solidworks and whenever something needs to be changed or tweaked, there’s a big chance that we’ll lose a lot of time fixing all the failed associated features. So we want to figure out if getting rid of the feature tree will save us time.

Well, with the caveat that you need to know what you’re doing in Rhino and certainly not guaranteeing 100% of the time, but it definitely can.

its probably not very hard to make such an autobubble but i am not a scripter

here some basics which can help creating dynamic text fields.
https://docs.mcneel.com/rhino/5/help/en-us/information/text_fields.htm

maybe @Helvetosaur has or knows some hack for this.

What about exporting a dumb solid from SolidWorks to lose the feature tree … import back into SolidWorks and continue to work on it?

The Power Surfacing plugin works well for organic modeling. I’m not trying to steer you away from Rhino, just suggesting that you may not need to change the work flow drastically introducing another application or replacing the current application.

Of course, Rhino would be a lot cheaper to maintain, so that might be a reason to switch if you are not getting any benefit from the other SolidWorks functions like assemblies or a well integrated drafting environment.

Sounds like a reasonable request to me :smiley:

What you ask about in Rhino features, is the same thing I have been asking for awhile now, to be able to create, BOM’s. assembly and exploded view drawings that can be sent to the factory floor with out a lot of messing around. Glad to know others beside myself consider it important.

My advice, switch to Rhino and start bugging McNeel for these feature so there is more then me asking for it. (Seems to be just me) It sounds like you need just a little better documentation ability like what I need. I have SOLIDWORKS as well but use Rhino for 99% percent of what I do. I keep SOLIDWORKS just for that last 1%

As others have replied, while this is not Rhino’s main focus, with some custom tools you can certainly do many things.

I would add that if you throw Grasshopper into the equation, you could also have some parametric design capabilities, which could be quite interesting.

The great thing of Grasshopper in this regard is that the “parametric tree” is completely exposed, so, provided that you know how to handle it, that gives you complete control over the various relationships. Obviously it is not feature-based, but for many not too complex cases it may be a solution.

If you can share an example of the type of component(s) you need to manage I can try to give you more details.

In any case I agree that the most appropriate solution would be to try to work within Rhino in parallel and develop some custom tools and workflows before considering a complete switch.

Here’s another thought…

If the goal is to get rid is SW, but retain certain aspects while gaining what Rhino can do, consider pairing Rhino with Fusion 360. They complement each other well, and native Rhino files import into Fusion for assemblies, etc.

Not knowing what you do, I’d fear you’d find yourself wanting something SW or Fusion can do that Rhino, as great at it is at what it does, simply can’t do.

Plus, a Rhino Fusion combo should still cost you less than SW.

I’m happy to have found a companion because I haven’t found a topic on this subject yet. I also thought I was the only one who required BOM’s etc from Rhino (which I find hard to believe).

As far as switching to Rhino; I’ve basically convinced my company to make the switch, the only caveat that’s stopping them is the ability to quickly make BOM’s etc. At the moment it’s just too much of a hassle.

I might try some scripting, but it should be easy to add some functionality for McNeel right? Where can we bug him? :stuck_out_tongue:

Thanks for the thought, definitely something to consider. However Rhino already has the ability to balloon parts (we use the annotation leader) and paste a command with the ID of the part included so it extracts the required information. We just need it to be automated so we don’t have to manually add each and every leader and look up every part ID.

Right here is the correct place for that :wink:

A quick search in their tracking system shows that there are two issues logged for this feature. RH-29290 and RH-35934. The release target for both is set to “Future”. Just remember there are thousands of other wishes and bugs logged in the system.

From my point of view enough people use Rhino for mechanical design because it really does offer a lot features that really are quite easy to use. And part of mechanical design includes BOM’s, assembly and part drawings. I would think some additions in Blockmanager and incorporating tables would not be that difficult for some one at McNeel to come up with to make a real BOM feature.

“Rhino Piping” has a good free plug in for tables, and I use that in my layouts in manually piecing together a BOM. For assembly drawing I can do those as well but manually and in a separate file. It would be nice to be able to sew all those up together in one file of the main model.

There are more then those two examples wim. I have made the request for a BOM feature (and others) and bring it up from time to time just to keep the conversation going. :smiley:

And then there is this request for the Assembly drawings

Well… you need to differentiate between the YT system and threads here on Discourse. Ideally, you only have 1 single entry on YT and lots and lots of posts here on Discourse - from different people.

Honestly, as a user of both SolidWorks and Rhino, you would need to think very carefully before ditching SolidWorks and moving all over to Rhino.

Rhino is a great tool and sure you can create virtually any shape (in very skilled hands)m and you can draft…but…if I was used to SolidWorks drafting and modelling tools and forced to drop it for Rhino I would seriously doubt the sanity of my boss.

You mention that the tree fails in SolidWorks? That you want no history? You can do that in SW already. Just use freeze, or export as a parasolid and import the dumb part. We can argue all day about modelling in this app or that app but in our business we use Rhino with TSplines for concept work, take these to SW for final surfacing and parts…and drafting.

Drafting in Rhino is, well…if you want to go back 20 years, lose all manner of automated drafting tools, e drawings, associative (that works) drawing views, reliable sectioning, call outs, hole tables, etc etc.

Keep SolidWorks. Use it in tandem with Rhino. It actually partners up well. Someone suggested PowerSurfacing for SolidWorks. We have it but stopped using it as it was buggy, slow and unreliable compared to Rhinowith TSplines. I see use continuing to use v5 for some time until McNeel implement a native sub d workflow to match T Splines (either that or we switch to Fusion360 for this kind of work).

3 Likes

This really sums up our findings too. We are a small company with a small crew so it’s relatively easy to make a switch. Ideally we would use a single software package to save some costs and don’t have to “export-import-convert-etc.” all the time.

Couldn’t have said it any better :joy:. I really hope McNeel improves this functionality. [quote=“Kevin_Quigley, post:17, topic:43361”]
Drafting in Rhino is, well…if you want to go back 20 years, lose all manner of automated drafting tools, e drawings, associative (that works) drawing views, reliable sectioning, call outs, hole tables, etc etc.
[/quote]

Yes, I agree it

Thats too bad, I wonder if the issues are with the SolidWorks plugin or if the stand alone package is any better. I admit I used the the trial only for a short time, and it seemed very encouraging.