Shouldn’t happen anyway - I will have a look tomorrow…
Edit - Found the error and fixed it (hopefully) - @Macuso, @milezee please try the following.
ExportObjBBData2.py (1.7 KB)
–Mitch
Thank you for the fix. Now it is reporting correctly. It is possible to modify the script to display the result without trailing zeros? Instead of “41.0” to have only “41”?
You can try the following - it should strip leading and trailing zeroes plus the decimal point if not necessary. I also set it up to round the returned numbers to the same number of digits as the current Rhino file display precision - I just assumed that if you don’'t display more precision than that, you don’t need it in the cut file either.
ExportObjBBData3.py (1.9 KB)
–Mitch
1 Like
Thank you Mitch. It is working as expected.
It is possible to modify this script to export also the curve type geometry? I’m working on some projects in 2D and will be very handy to export the 2D curves as well.
Hi Mitch, sorry to trouble you, I have been using your script again, it seems to giving the odd inaccurate dimension on some lines of the table, running Version 5 SR14 64-bit
(5.14.522.8390, 22/05/2017)
Commercial
Any ideas ? tia 
edit- it seems to be omitting the ‘0’ before the decimal point too
Sorry @milezee , forgot this was still open. I would need a file to test on to see why it’s giving “funny” results… you can send it to me via PM if you can’t post it here…
no worries Mitch, I’ve created a test Rhino file, gives the same results in the CSV table created using the last script you posted here, “ExportObjBBData3.py” .
All zeros are being left out- e.g, a measurement of 330mm is showing as 33, or 400mm is showing as 4 in the CSV created. Thanks for taking a look 
Cutting List test.3dm (60.6 KB)
Yeah, the function I wrote for removing leading and trailing zeros is pretty dumb, it simply strips all zeros… So if there is a round number like 400, it will end up as 4.
I can try to write something a bit more sophisticated, hang on…
1 Like
thanks Mitch, for these kind of projects which I do a lot of, working to the nearest mm is fine, I have no need for anything after the decimal point. I hope one day to see a native command within Rhino for creating BOM’s, its hugely helpful for estimating and producing cutting lists
OK, try the following on for size… Let me know if it works better.
ExportObjBBData3.py (2.1 KB)
2 Likes
Mitch, all good ,
If I had a wish to make this even better, it would be nice if the numbers descended from highest to lowest, e.g. 425, 300, 18 . I’m guessing at the moment the numbers are ordered from an x,y,z view. I can reorder them in Excel but it’s a bit of a pain.
Anyway, as it is saves me a bunch of time, so much appreciated, cheers
I think that’s doable… Also, if I understood correctly, you don’t care about anything after the decimal point? So we could round the number to the nearest mm and eliminate the decimal, is that it?
Try this one:
ExportObjBBData4.py (2.2 KB)
2 Likes
Hi Mitch, just tried this on my MacBook Pro at home, seems great on Rhino for Mac, will check on the windows machine when I’m in the office tomorrow, many thanks for taking the time to adjust the script
1 Like
works fine too here in the office on the windows machine, many thanks Mitch
It is possible to modify this script to change the output from this:
Side,Carcass,18,760,565
Side,Carcass,18,760,565
Top,Carcass,564,565,18
Panel,Carcass,330,18,400
into this?:
Name,Layer,Length(Veneer oriented),Width,Thickness
Side,Carcass,760,565,18
Side,Carcass,760,565,18
Top,Carcass,564,565,18
Panel,Carcass,330,400,18
I don’t know if it is possible to implement a mechanism to set the “Veneer” orientation per panel.
Hmm, in principle the last version (ExportObjBBData4.py in post #30 above…) should spit out the following:
Side,Carcass,760,565,18
Side,Carcass,760,565,18
Top,Carcass,565,564,18
Panel,Carcass,400,330,18
…as the data is supposed to be sorted by longest length first, then next longest then shortest… If it isn’t doing that, then there is a bug somewhere, if you could post a small example file I can test to see why.
Probably fairly difficult to do as it would require the user to manually set a veneer axis direction for each panel using something like user text, then try to read that data and adjust the results accordingly.
1 Like
Amazing thread, and very useful for something I’ve been working on myself at my end of things. Somebody should have been arranging a bounty for this code, @Helvetosaur; extended functionality such as this is what allows productive use of Rhino instead of relying on uber-expensive suites like SolidWorks…
Apologies for the zombie thread revival. This one is worth it’s weight, and I had to add my thanks.
1 Like
its a great little script, I’d love to see this functionality built into Rhino one day
I can imagine that it is difficult. To be useful, this script requires assumptions be made (and fully understood) about the objects it is exporting the properties from; only their bounding box dimensions aligned along world coordinates are reportable. Orientation beyond that becomes a required property, especially when it comes to real-world materials with grain direction, veneer orientation, edge-banding, etc. This feels like functionality beyond the realms of a “blind” function plugin. As it stands the script is useful if you’re able to use it with white box understanding (is that term PC these days?) rather than black box reliance. At the very least it’s great for reducing manual input typos.