Layout Publishing & BOM Tables Wishes

Hi Miles -

“Some better publishing” is rather broad and there are 18 related YT items targeting Rhino 8.0, and 17 related YT items that are currently being considered for Rhino 8.x.

As for a native table generator, RH-35934 is not currently on the table for v8, no.
-wim

Hi Wim,

Exactly, not much has progressed in recent years, so hence ‘broad’ words !
No native table generator is bad, really bad :unamused:
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

This is in the list of Rhino 8 related issues that Wim provided.

1 Like

Hi Miles -

The Rhino WIP Features topic has an overview of what’s on the table for Rhino 8. That list is subject to change.
-wim

1 Like

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 :+1:t3:

1 Like

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.

  1. In Excel or Google Docs, format your table, including borders.
  2. Print to PDF file.
  3. Import PDT to Rhino or drag & drop on to the Rhino application and pick Import.
  4. 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.
  5. 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

Sincerely,
Mary Ann Fugier

2 Likes

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 :rofl:

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.

the Tabl is a 3rd party plugin, tried it, works sometimes, other times not, this kind of functionality needs to be inside Rhino :man_shrugging:t3:

1 Like

Its stored somewhere, highlight an object with BoxEdit open and there’s a world of information there.

I would imagine its not simple, nor do I think its super difficult either

yep it is badly needed, wanted for years, along with better publishing of multiple layout sheets :+1:t3:

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’ :man_shrugging:t3:
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.

This is the Vectorworks method.
http://app-help.vectorworks.net/2016/eng/VW2016_Guide/Annotation/Creating_Detail_Bubbles.htm#XREF_29579_Creating_Detail
http://app-help.vectorworks.net/2016/eng/VW2016_Guide/Annotation/Creating_a_Bill_of_Materials.htm

N

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.

Maybe I’m being a little closed minded. I tried Tabl_ through the package manager. It seems alright at first glance. It would be great if it could include all userdata in separate columns.

hi @Ncik not at all, in fact maybe you’re overthinking it, it should be really quite simple. The user should be able to assign whatever data the object requires., choose column names in the table, Name, Finish, Material, Size, Quantity etc, comletely customisable, but a simple table. I’m a previous user of Vectorworks, and the way tables work inside VW was great.

If you have no use for it thats fine, many others will put this functionality to great use

1 Like

Some of my clients have very prescriptive demands for the way that notes and parts tables are portrayed in drawings. Those demands also differ from one client to another. Fonts, text heights, row and column spacing, line weights are all defined. A generic ‘Here’s a table, go stick it in your drawing’ just doesn’t work for me.

As a result, the control of the table appearance would have to be very granular if it’s to be usable. Where the content is concerned, I think Rhino is getting close to having things covered with the way that user defined information/text assignment is going. It’s not quite there yet, but it’s not far off. The user interface for the control of that information and auditing the assignment to geometry could be improved.

Although it’s not specifically related to BOM, Rhino really needs to get on board with supporting STEP AP242. It has the tools to port PMI to other CAD, which is where it crosses paths with BOM. The only STEP formats Rhino currently supports were deprecated in 2014. That’s EIGHT years ago. And counting.