We so need some better publishing of layouts, it’s been requested so often for years.
We also need a native table generator inside of Rhino, again been requested by many, for many years.
There are a few scripts & 3rd party plugins users have knocked together themselves over the years, which is great, but none fully do what we need for documentation, organisation, quantifying etc. User scripts are never kept up tp date, 3rd party plugins fall behind. These should by now be basic tools inside of native Rhino.
Are there any plans for these in V8 ? If they are not even on the radar, please let us know.
The requests and discussions for these tools are endless on the Discourse forum, and have been for many years, c’mon McNeel, make these things happen, it will elevate your product to an even more user friendly design driven piece of software.
Please please make these part of Rhino 8.
can anyone from McNeel shed some light here ? @mary@stevebaer@dan@pascal, anyone from the development side involved in documentation etc @bobmcneel , what is in the pipeline for V8 regarding the above ?
Exactly, not much has progressed in recent years, so hence ‘broad’ words !
No native table generator is bad, really bad
For publishing layout sheets, we need to be able to publish each sheet and keep its own layout name, I sometimes have 30+ sheets in one file, each has its own sheet name, this is important for issuing documentation and keeping track of progress etc. So a better publishing manager is important. I could go on and on, these requests are littered all over the forum, and have been for years, some links below
Just a few threads which stretch back many years, I’m sure there’s much more in the forum. I love using Rhino, my favourite design software by far. I hope the powers that be above my rank don’t force us down the route of revit (yuk). @wim where can we see whats being implemented in V8 so I can get some solid info when asked about the improvents for future versions of Rhino ? cheers
thanks @stevebaer & @wim , I’ll load up with info for next time we have a software review, those links above are the tip of the iceberg for tables & publishing requests, many many users workflows would be made much nicer when they are implemented
This is in no way intended to replace the need for a table object or table generator in Rhino. However, you may not know that there is a work around to get tables on the Rhino model or layout. This is for you.
Importing a PDF of a formatted table actually works well in Rhino 7 & 8 WIP.
In Excel or Google Docs, format your table, including borders.
Print to PDF file.
Import PDT to Rhino or drag & drop on to the Rhino application and pick Import.
Set PDF unit = to Rhino unit or scale after importing with Gumball or scale command
Uniform Gumball Scale: Hold down the Shift key and drag one of the scale markers.
Miscellaneous clean up as required.
Need Changes: Update in Excel or Google sheets and repeat.
Give it a try if you need a schedule on your layout.
If you use Rhino 7 Block Attributes, try the new Rhino 7 test command TestExportBlockAttributes. This will generate a CSV that you can import and format in a spreadsheet program. (Rhino 8 WIP the command is ExportBlockAttributes)
See previous post here: New Block Attribute Export command
Hi @mary thanks for chipping in. Yes I have used the same method as above for years. It’s not really the way we should be doing things like this in 2022. We need the ability to create tables inside of Rhino, live dynamic tables, and then be able to export to csv/xlsx etc. My drawings are used for fabrication, procurement, and installation, so the documentation aspect is really important. I’ll keep my fingers crossed, and hope the powers that be don’t force us to start using revit at the next software review
Also, not sure this is on this thread somewhere, but someone made a plugin called TABL or something like that - food for rhino… I did try it and was very impressed at the time, would love to know any improvements/integrations…
How would an automatic BOM/table generator work? What information should it display? What objects should it work on?
Most of my models are a combination of lines, curves, surfaces, open and closed polysurfaces, all spread over various layers. How would all the varied information contained in and about these objects be dealt with by a BOM/table generator?
I have created my own BOM generator for job specific tasks. As an example, one issue encountered, which I think would be useful to many, is getting the extrusion length of an object. As far as I’m aware, this information isn’t stored anywhere for the extrusion, and as soon as you trim the end of an extrusion it becomes a polysurface. The length may or may not have changed, but the object certainly has. A polysurface certainly has no intrinsic “length”.
I don’t believe it is as simple as people believe it is to create a universally useful BOM/table generator.
A generic manually editable table object, yes, universally useful and needed.
If you know where the length of a sweep1 is stored, please share it. It looks like extrusion objects have start and end point coords, so that is something. But all my extrusions get modified, reverting to polysurfaces in the process, so this end point data is expunged.
I’m not sure which part of your sweep you need the length of, if its an edge, sub object select the edge, type ‘length’
For me I would assign custom info to objects, material, finish, name etc etc and create a bill of quants
For some of my sweeps, the longest polysurface “edge” that could define the length of the extrusion is not a single curve, so sub-object selection does not work.
This is exactly what I have done, created some scripts that add and use input data into the created object for later use in developing deliverables, including BOMs. For example, the length of the sweep rail is added to the polysurface as user data. There’s a family of scripts that allow me to modify and use that polysurface without destroying that original length user data.
I use open surfaces and open polysurfaces to represent solid objects because using closed polysurfaces, that are truer representations of the built product, ruins other steps of the process of developing production output. So the scripts keep track of the plate thickness, rather than modelling the thickness.
So having been through the process of creating a custom set of tools, I don’t think a generic BOM tool will be useful to everyone. Each industry/process could have a generic set of BOM tools, but I don’t think a one size fits all approach will work.
Well thats where we’ll agree to disagree, it works fine in other softwares (think Vectorworks, Revit, other softwares are available too). It was needed by many in Rhino like yesterday, forum is littered with requests for it over many years
Maybe I haven’t explained my argument sufficiently.
Perhaps my imagination isn’t broad enough, but I can’t see one, generic automated BOM being a solution to every users desires. If someone can explain how this would work I am all ears/eyes.
Custom BOM generators for each use case is the way to go.
As an example, someone who designs moulds for plastic parts with steel slabs (closed polysurfaces) and bolt quantities (blocks) would need a different BOM generator than someone who designs boats (open surfaces and open polysurfaces, the length of extruded metal as polysurfaces, and that’s just dealing with the structures).
And then there’s all the messy geometry used to create the final model. How is that dealt with except to use custom processes.
I dont think so, and i hope rhino will not go in this direction.
Comparing rhino with revit features is like comparing freedom with endless options but no premade structure and premade structure without much freedom.