Yes, this would be a great help. I also do a lot of work for clients that have to be manufactured. The shop people are accustomed to styles of instructions that closely resemble 2 D drawings done in Auto Cad, Solidworks, etc. I can get there with Rhino, but the time consumed is way to much.
I know a lot of people love grasshopper and other new tools in Rhino, but for those of us who make a living working with clients who want projects actually manufactured, these additions would be fantastic.
I also love Rhino. It is very intuitive and fast. Thanks
Rhino is a lot of things, to a lot of different professions, with some of the more particular development left to users to drive. Unfortunately many of these great workflows have remained proprietary to the businesses that developed them, which is fine, but we can more.
A great example of this is Elefront, which has provided their workflow to everyone to use.
If you think about what a view is; a plane, some user text, cut geometries, it’s not that difficult to ‘roll your own’. And i agree, these workflows need to be more accessible for new users without using grasshopper.
From my perspective if this is only about creating section views on sheets from other views then the approach used by most vendors works fine - and it is certainly something that should be added to Rhino anyway.
But taking it a step further, if you wanted a “super section” tool then creating it in the model is the way to go - and this is in fact what the mainstream vendors do - from Solidworks to PTC. Someone above mentioned Spaceclaim, and Spaceclaim has a fantastic set of sectioning tools in the model that can be taken forward to drawings if desired.
Most of these in model sectioning tools were created for the purposes of model based definition. To be honest I don’t think MBD has taken off quite as quickly as some vendors wanted but it is growing in use, and certainly when you get into cloud based model sharing it is really useful.
Is this a core Rhino requirement though? Maybe for some, but not for us. TBH we’d continue to use Solidworks for that and do live screenshare sessions. But, for those drawings where you want to maintain the link to the model and do a section on the view, yes, this is a core tool in my view, especially for design for manufacture - checking clearances/offsets/assembly details etc.
Hello!
Why not get inspired by the VisualArq section tools? You can draw section lines with jogs (don’t even need to be right angles), then either
A) turn this section on in a 2d or 3d viewport (inlcuding details), or
B) create a section view from it, similar to Make2D. In this case, a ‘parametric’ block is created that can be updated should anything change, or be exploded, to work on the curves.
Works with any watertight brep btw., not just VA objects.
Sectioning functionality should definitely be a built-in Rhino feature, but I’m wondering, why re-invent the wheel, when something similar already exists? What else did you have in mind basically?
For those unfamiliar with VA: to make a section active in a layout detail, it needs to be turned on there. This is done in some extra panel where all sections are listed. In every detail, any section can be active, but only one at a time. Nice and logical.
However, VA sections cannot sit on an arbitrary construction plane, just on xy, because that’s the usual case in architecture. Sectioning with arbitrary planes would be desirable though, especially for non-architectural use cases (but also there).
Anyway, if you create an implementation that is very different from VA’s, their users (me included) will wonder which one to use then, and why there are even two different ones.
Since AsuniCAD is obviously closely related to McNeel (is it not?), couldn’t there be some sort of synergy, in the form of a shared codebase? Will McNeel develop something that Asuni can use, or the other way around?
Great post. I would add that not only jogged sections are essential for reallife work but also section-views along curve. In civil engineering maybe 50% of the sections and views are along curve. No software has this capability to create sectionviews along curve. Rhino could be a pioneer in this The method is to flow/warp objects from curve to straingt line and then create a basic “make2d”. Right now the state of this is very very unreliable. Make2D leaves out way too many lines in any scenarios.
Question with curved sections is: should a pattern be displayed on the section surfaces?
If yes, it can’t be hatches, because they have to be flat in Rhino (can be rotated freely in 3d, though).
But let’s think about it for a moment.
Either a hatch pattern could be simulated with a bitmap/texture on these ‘free’ section surfaces, or some way of distributing a ‘real’ hatch pattern on warped surfaces would be needed.
Rhino hatches can be exploded (If the hatch contained a pattern, lots of lines are created. If it was a solid fill, a surface is created). Should this work with these hypothetical warped hatches, too?
Sounds pretty tricky.
my method for creating such views is that firstly i flow geometry from a source curved curve to a straight line. objects get distorted this way but then subsequent “make2d” is on straightened geometry so resulting geometry is already unrolled and planar.
Yes, objects and layers will have hatch pattern attributes that help define what types of hatches will be created when clipping planes cut through solid objects. We don’t have attributes for a separate fill color yet, but that is being considered.
Thank you @felttippen for this post!
It is not long and points out one of the main feature I think rhino should definitively have.
I talked already about this, among other feature requests here but your points, together with all other suggestions, show what is missing. I fully agree with most of them.
Please @stevebaer, @wim and @Japhy work through this to have it implemented into Rhino 8, thanks!
My experience is with Microstation and Spaceclaim.
Microstation: anything can be done but is far from straightforward, reliable and intuitive: you can define for each view front/back clipping plane together with Section plane, define visualization style for every volume/section but it is quite complicated and you need to keep track of links to model, layer local/global display, level symbology…
You can have dynamic / cached contours and hide some of them but at the end any little detail can just break your drawing or make you wait minutes for an update.
In short: it is powerful but so old, slow and painful.
On the other hand Spaceclaim drafting is super easy and intuitive but unfortunately lacks some basic tools (like sheets reordering) to be really effective. Copy/Paste worked great from Rhino 5 to SC but is not working anymore. Here a video showing SC workflow.
Where I get lost sometime is dimensioning which I think is oversimplified.
→ Please look at 1:20 of this video as well which shows the interesting way SC place 3D geometry on sheet.
Closing this post, I think we don’ t need to go too much far from what is already around on Mechanical software maybe with some more freedom in display from Architectural software but let’s keep it simple!
Last point: drawing output of all displayed contours has to be Vector!
Spaceclaim for instance creates a PDF which couples vector contours with a background of rendered view to keep together display intent with lines crispiness.
Hi @Steve, this is great. I discussed already with @rajaa about SectionTools here.
Given that ST is not a dynamic tool but can be refreshed it is very important that it keep track of objects to be updated beyond current layer state.
Thanks
If you get the latest Rhino 8 WIP which was made available yesterday, there are a few things that you can try:
Curves drawn where clipping planes intersect objects can be snapped to
You can run the TestSectionsV8 command to set hatch attributes on objects or layers. This test command exists only because we don’t have our object properties and layers user interface updated yet to include them. Once these are in the user interface, we’ll remove the test command.
@stevebaer, Nice, this is super exciting. I just tried this out and noticed it doesn’t seem to work with Make2D. Will this be an end-goal? Also, the behavior of an exploded object that’s being cut through is a bit odd, you loose the hatch. It might be helpful to have a mechanism to extract the hatch if needed. Even though I’m using “SetByObject”, I don’t seem to be able to exclude objects. Am I doing something wrong?
The method is to flow/warp objects from curve to straingt line and then create a basic “make2d”. Right now the state of this is very very unreliable. Make2D leaves out way too many lines in any scenarios.
