It would be helpful to make clear which attributes and functionalities will be considered under the development by the VisualArc team and which we can expect to be part of native Rhino when it comes to this grey area of layout and drafting.
A few years back, I had a meeting in Barcelona with the VisualArq team.
I made a little demo of what could be achieved with SolidWorks and they were surprised.
And I’m sure it would have shocked McNeel devs too .
All these folks seem to be living in their little nerdy programming bubble and don’t realize what’s going on outside…
Anyway, at the time, they promised to try and achieve some of the features I showed them, and to be honnest, they tried.
The problem is that they are bound to the OpenNurbs SDK, and can’t really achieve miracles.
As I understand it, smaller CAD companies license tech from larger ones, like SIEMENS
And since Bob was never willing to go that path, and never invested in the workforce to create similar tech., well, we’re stuck with “Make 2D” or funny so-called “technical” views which are really useless hacks.
My main gripe is that they always dodge the subject and never admit that it was a terrible mistake which forces them into a silly, submissive “Rhino inside” scheme to remain relevant.
If it wasn’t for Grasshopper …
It is not really that clear cut. A simple way to look at it is if we don’t supply a function, then visual arq tries to add it.
Another way to think about it is if the object thinks it is a wall or roof and acts accordingly, then it is a VisualArq thing. If it is more generic like a layout, dimension or block, then it is a rhino thing.
But while we talk about this like it is simple, it is not only one or the other process. There are bunches of plugins and workflows that people use to get drawings, fabrication data and BIM out of Rhino.
And now Archicad, Revit, Tekla and Bricscad can be part of the toolchain too it gets quite interesting.
There are many ways people are doing drawings with Rhino. The question of can rhino be part of your process? Are there other products that you work with that help get that work done too? How can we help smooth out that process?
@scottd I agree completely that layout and drafting is one of the weaker links in Rhino. I am doing product design mainly but I think type of industry doesn’t really matter. It makes no sense to have to rely on other applications for drafting. It means extra costs and maintenance. I own a copy of solid works but hardly ever use it. I have in fact exported parts to SW in the past for 2D drawings. But it takes extra time, and extra exported files etc. Much cleaner to have everything in one (Rhino) file.
But the lack of relation between 3D and 2D makes it cumbersome.
Is McNeel willing to evaluate such 3D party tech in Rhino as suggested by @osuire?
We are always looking at stuff. We always are considering how to push things forward and we continue to push drawings and drafting for each release.
It is interesting how everyone points toward the tools that support the types of associations that relate to the work that they do. Of course the two main areas are:
- Solidworks, Inventor, Pro-E, Catia for products and mechanical.
- Revit, Archicad for Architecture.
Each platform supports the type of relationships that inform the generation of the 2d drawings.
VisualARq can automate a lot of the work for creating drawings in Architecture because it handles those associations. Orca3D does much of the work for Marine because of the associations.
In Solidworks, many of the 2d views are almost hand drawn while constraining many profiles as things are being modeled.
This is not a simple plug and play kind of solution. The generation of the drawings is deeply embedded in the rigorous modeling process and object model of each solution. It is the same reason people do not use Solidworks for Architecture drawings and do not use Revit for product design. And these two are so far apart I do not know many people that would ask for that.
Rhino kind of sits in the middle of all of these industries, trying to solve problems that none of the others do within a reasonable price. Essentially trying to fill in where other products have gaps. Sometimes those gaps can be quite large.
It is always clear that everyone would like on application to do all their work.
So we will continue to add and push forward where we can. Hopefully with each release we can deliver something useful for everyone, not only for drawings, but for modeling in general, visualization and everywhere else people use Rhino.
@scottd although every designer and every industry is different, there is still a lot of common ground for making improvements to drafting and layout that everyone would benefit from. To name a few industry independent ones:
Dimensions that stick to the objects in layout space and that keep their associations with the object and move with the detail and scale with the detail.
History for Make2d so that drawings will update when the model changes (when idle -otherwise its too slow)
Hatched sections and different per object.
A more easy way for details to keep a correct (page) scale
There are way more and I am sure they have been listed earlier.
I’m completely on board. This is why we are Rhino users. We are watching unfold, in real time, what happened when other software companies don’t listen to their customers. I believe in the ethos of development at McNeel and feel privlaeged to be a part of this conversation.
This sounds about right. However, I’ve come across a handful of threads, other than this one, that make me question what is under Asuni’s development scope and what is not. Take this clipping plane thread for example. According to the YT, enhanced clipping was requested as early as 2009, but now it exists to some extent for BIM users in VisualArc. This enhancement is essential for workflows across disciplines. Why is it locked inside the BIM package?
The same can be asked for the items @osuire has cited above concerning layouts and drafting. Not only BIM users need these.
The first thing I say to new students when covering Rhino is that it’s “the Swiss Army Knife of 3D software.” I don’t expect it to do everything. On many fronts Rhino already does, on others, is gets SO CLOSE to crushing the competition but doesn’t quite get there.
It is also important to remember the usual reason for wanting to create a 2D representation of a 3D design, no matter what field of design one is working in.
In all of the cases that are being put forward both here and in other related discussions (I think!), that reason and destination is to a human, not a machine. In my experience, Rhino is very, very good at providing 2D output that is destined for e.g. a CNC router or laser. Whilst the vectors that those types of work require could be buried in a conventional, drafted drawing complete with title block, border, parts table etc, a lot of the time the CNC programmer getting their information in that way will give a dismissive sigh and a look to the heavens, before deleting all of the ‘crap’. So very often there’ll be a derivative set of 2D files that aren’t “drawings”, made solely for the purposes of porting information to a machine, not a human.
Anyone who has imported a cross-platform export of a 2D drawing created by the top tier solid modellers like Solidworks, Solid Edge, Catia etc will know that the dumb (by which I mean all of the inferred intelligence of the proprietary format has been lost), pure vector detail contained in them is about as far as one could want to be from a CNC-friendly file. Hundreds / thousands of disconnect, overlapping lines that would cause any CAM package to have a quivering fit. But that doesn’t matter, because it is humans that are the intended destination. Their associative, slick method of making a 2D drawing of 3D objects is alluring and addictive, even if the nuts and bolts of the underlying construction are a mess. But us humans aren’t astute enough to spot that, so that doesn’t matter.
Make2D is an accurate though one-way method of porting 3D to 2D (that also happens to display a few of the traits of the solid modeller’s 2D vector work on occasions ) but I’m not sure it’s necessarily the right way to solve Rhino’s associativity problem. Something needs to be done to address this core issue though as it is a major obstacle, no matter what the design sphere. It may need to be done ‘wrong’ in order to get it ‘right’. Conceptually, perhaps something along the lines of the old Section Tools add-on, at least as a WIP?
So let’s talk specifics. Sectiontools. So, with sectiontools, what worked right that we need to add to rhino? And what needs to be improved?
And do we have rhino files to show the specifics in each case?
What I don’t understand is the argument that some tools already exist as plugins or as Rhino Outside. If this is a leading argument, then why has McNeel developed numerous rendering plugins? Some of which were clearly wasted resources as they were abandoned quickly.
Yet I feel some essential tools are kept underdeveloped. You say we keep pushing things forward but in terms of page layout and drafting very little has changed in the last decade or so. Or do you perhaps mean by ‘pushing forward’, putting it on the ‘future’ list?
And now you ask what is wrong with section tools. Did you search the forum already on this topic and on clipping hatches? There are many lengthy threads on the subject already that discuss the shortcomings in detail. With numerous people including myself that have tried to make workarounds for these shortcomings, eventually to no avail because there aren’t enough tools exposed in rhino common to make it happen. In all those threads I haven’t seen a developer jump in and say: “thanks for all the efforts and attempts. I now clearly understand what’s missing. I’ll start working on it right away!”
At best it these have been added to youtrack and put on a future list.
The risks of relying on a third party’s plugin to provide powerful (and for many, essential) functionality should be painfully clear to McNeel by now. Many of us are marooned at V5 as a result. They either get bought out by the competition or get left behind over time as the developer doesn’t maintain compatibility with subsequent updates to Rhino.
My example of the old Sectiontools plugin was used in this case solely as an example of McNeel‘s producing of it’s own outlyer plugin to provide additional functionality to the core product, in a way that could be used as a sandbox to develop features (mostly in response to dialogue on this ‘ere forum).
Other examples - Fabfont (a little gem that’s been abandoned), Neon (which served it’s purpose well). There are others that don’t come to mind immediately.
So I chose Sectiontools as an example of the development method rather than the product specifics. However, as has been picked up on, many of the features of that particular product happen to be very relevant to this 3D-to-2D Bridge tool discussion.
A first step forward, would be to make Make2d handling clipping planes better:
- make curves behind clipped surfaces looks like hidden curves
- fill closed cut sections with hatches
- integrate these features in the SDK & Grashopper by the same occasion
Without these, producing technical drawings remains a real pain.
These features have been requested many times during the last years:
- https://mcneel.myjetbrains.com/youtrack/issue/RH-14679 (8 years old BTW…)
- WISH - Make2D and ClippingPlanes: output internal edges as 'Hidden' curves
- Make 2D & clipping Plane
- Make2D from Clipped geometry
…but there seem to be no big improvement on that topic (from what I’m aware of…).
I my opinion, this is real basic and useful stuff and should be implemented in the core features of Rhino, and also not rely on some third party plugin, SectionTools, VisualARQ or whatever.
Attached is an example of typical output, aimed at humans rather than machines. NDA’s get in the way of other, perhaps better, examples but we’ll live with it.
Within the working space of the drawing.
(i.e. everything you see that’s inside the innermost line of the drawing border)
Everything here was produced entirely within Rhino and didn’t use Layouts. The reason for that was (at the time) getting output in PDF and a cross-platform CAD standard (usually dwg or dxf) is a must for almost all of the clients I do work for and Layout couldn’t do that, along with (sometimes) a 3D model in STEP or whatever. Perhaps things have moved on, but from recent offline discussions with Pascal about parts balloons there is still a lot of work to do. V6 has more problems than V5, from what I’m seeing and reading.
My work is very varied: Bespoke helical staircases for the building trade, vehicles like the attached PDF, train interiors,livery drawings, Point of Sale, injection mouldings - all kinds of stuff. The above are the universal deliverables and are a core requirement, irrespective of the industry. Please get those sorted before you start on the industry-specific niceties.
Imagine that I’ve sat here for a few minutes waiting for Make2D to trot out the views you see in the PDF. Fine; apart from some parts where it has (literally) lost the plot, I can live with that - perhaps half an hour spent retouching and I’m good to go. Layer control of the results largely works and it’s fairly manageable. I model in the assembly arrows as lines or surfaces prior to Make2D. Exploded views are a pain and have to be manually pulled apart, which means a separate model which then needs to be kept in sync. with the master model. There’s work that’s been done on that more recently and things have improved in that area. I’m not sure if they are fully developed.
Callouts (the parts balloons) are universal. In Rhino, they have to be done manually and are extremely time consuming, especially if you’ve got lots of them and need to move them around to get everything to fit without the leaders overlapping. If you have to move one, the easiest way is to delete the leader, reposition the balloon and text and draw a new leader because it can’t maintain it’s perpendicularity to the balloon. Do that a few hundred times and the novelty soon wears off. A tool to treat the balloon, text and leader as one editable item that maintains alignment would be a massive help. Making it intelligent, populating the balloon text by pulling pre-defined user function off of the item that the leader tip touches would be a step forward. Options to: Have the balloon auto-resize (as an obround) to suit the text; have different shapes of balloons - round, rectangle, hexagon etc - to enable use as a means of identifying types of parts classes; assign these preference to layers. Layers are old school but much maligned in my view. They are extremely flexible and can be used and abused in many ways. They can be all things to all men with a bit of lateral thinking.
Display order: Again, provide the ability to link to Layers. Add a column to the Layers panel where one can assign numerical order to display. A radio button at the top of the column to invert the order, should the need arise. Don’t make it dependent upon their order in the Layer panel. There’s too much other functionality that people rely on in other areas where that is concerned.
Section Tools: Assign sections to sublayers of the objects they section by default. Sublayer for the fill/hatch; another for the section outline. Move the linetype and fill definitions for anything that’s ‘Section’ to a distinct column in the Layers panel, then allow Select All or whatever at the top of the column so that their collective line type, colour and and weight can be set at a stroke, or even turned off. Individual Section layers can still be tampered with to suit the user’s need. Yes, this will make the Layers panel grow considerably, but it would make perception and control of what’s going on a lot easier for us Humans. Make sure that whatever Sectiontools does produces the same appearance in both PDF and dxf/dwg exports. This is critical. Maybe svg too for a little bit of future proofing.
Associativity of the 2D to the master 3D model: The elephant in the room, as @osuire puts it. Imagine I have to change the trailer hitch in that PDF, two months after first issue. And update all of the affected 2D 2D drawings downstream of the GA. Resetting viewpoints (you did save all of the viewpoints, right?), calling Make2D, retouching the missing lines, scaling it and trying to align it with the original, erasing the old item and trimming/extending/reconstructing the surrounding line work to make it all good. If that isn’t enough to make you break into a cold sweat, then you haven’t understood the problem. Then the supplier calls a week later and tells you that hitch is no longer available…
Then there’s the stuff outside of the model space: Parts tables, title blocks (work on that is coming along well), export of BoM to Excel. I’ll have to come back to those as I have (paid) work to do.
Chassis 17Feb11a.pdf (992.8 KB)
Slight tangent, but apart from basic hull lines, does orca3d provide other drafting capabilities?
All this should be obvious to devs working on a modern CAD tool, but I still read the occasional “could you be more specific about your needs with regard to drafting ? We will do our best to bla… bla… bla…”.
The problem is that Make 2D is just not the proper direction. It can be polished at it wants, it will never reach the reactivity and robustness of hidden line view computation as has become standard for the past 20 years.
When I saw the “Technical” display mode arrive in Rhino a few years ago, I suddenly had a glimpse of hope as it seems to be the same the approach used elsewhere.
But it just falls short :
- Many missing edges
- No way to print to PDF as vectors, or export to DWG for that matter
- No useful hatching of sections (no need for gradient hatches, the run of-the-mill ones will do !)
My guess is that the others manage to leverage the mesh edges and silhouettes computed by the algorithm in a smart way, projecting them instantly on a virtual plane, and converting them in into simple entities when relevant (circles in particular).
This makes it possible to snap to silhouettes, (and even to section edges !) and to export the views as vectors.
My understanding is that the parametric modellers do not work this way. They cheat by using the feature sketches for the drafting results, hence why they are far more developed than Rhino can produce from a “dumb” model with no sketch based feautures. I might be wrong though.
This is obviously wrong, the simple proof being that many people export “dumb” geometry from Rhino to these tools, expressly for them to make projected views.
By chance, all the workshop drawings for our steelwork are done by our sub-contractor this way : we send them STEP models (which get imported as parts /assemblies since we use nested blocks), and they do all the drafting with Inventor or similar.
reminds me of the old Autocad command ViewBase hardly anyone knows about. Great for quick hidden line perspectives and hatched sections.