Too many geometrical entities

Replies to This Discussion

Permalink Reply by mark zirinsky on March 23, 2016 at 8:54pm

run it in stages if you can. divide it by, say, quadrants, tenths, whatever so that you are removing some of the load. usually the magic number is 65,564 elements, so you might try less than that number. after all, this is supercomputer stuff working on personal computers, at some point you do need a cray.

Permalink Reply by David Rutten on March 24, 2016 at 2:48am

I've been running into crashes with baking large amounts of geometry myself lately. Trying to put a couple thousand polylines and points from an OpenStreetMap download into a 3DM file just crashes all the time (Rhino6). I don't know exactly the problem is, or how to circumvent it. But since all your shapes are boxes, maybe try baking blocks? There's a script on discourse.mcneel.com for inserting blocks in rhino from GH.

Permalink Reply by Nik Willmore on March 24, 2016 at 6:34am

Use a plug-in or script to export it as a file directly to disk?

TTToolbox is one:

Also, formally joining the separate meshes into a single defined mesh may help.

Various mesh modeling programs should be much better than Rhino at huge mesh collections. I'd personally try free Autodesk Meshmixer and ZBrush first but most designers are more familiar with rendering programs like Maya or 3DS Max. I'm not familiar enough with architecture to suggest a list as only Revit and Sketchup come to mind.

Looking more closely, CAD Exporter is only for 2D curves and points, how silly, and it requires baked geometry in a Rhino layer:

I could write a Python script to export an STL but that would be a large ascii format file instead of binary. Better to use OBJ to retain quad faces, too.

Ah, well, OBJ files are also ascii format when exported from Rhino, so it would be quite easy to make a script to export those directly to disk from Grasshopper. Here is one box, 10X10X20 in size, with quad faces:

# Rhino

o object_1
v 10 10 20
v 10 10 0
v 10 0 20
v 10 0 0
v 0 10 20
v 0 10 0
v 0 0 20
v 0 0 0
f 5 7 3 1
f 5 6 8 7
f 3 7 8 4
f 2 4 8 6
f 5 1 2 6
f 3 4 2 1

If I have time I'll make a little script to write such OBJ files unless you can find a native Grasshopper plugin for direct OBJ export in full 3D for meshes.

Permalink Reply by Anders Holden Deleuran on March 24, 2016 at 6:51am

For visualizing, outputting and saving to file: Joining all meshes into one mesh will definitely speed up thing a lot. Depending on your algorithm, you might implement this from the get go (i.e. make an empty mesh first, then append to this mesh when you create your meshes), especially if you're scripting this.

Permalink Reply by Nik Willmore on March 24, 2016 at 7:43am

Here is a direct OBJ exporter Python script that leaves out vertex normals for a smallest file size:

Change the file path and name on line 3 as desired. Push the button to export the file.

Meshmixer actually re-triangulates it so maybe that's not as good as a quad mesh modeler like ZBrush.

Setting my array size to 316X316 to afford 100K boxes takes a couple minutes for Grasshopper to output, then the script export takes under a minute for a 28MB file that Meshmixer opens right up:

However, with the mesh *joined* as one formal mesh, Grasshopper can bake it to Rhino in a split second, so maybe the problem is solved? If I bake before joining, it still works in only a few seconds but Rhino slows way down even though I have a thousand dollar graphics card made for CAD. Rhino can also open the OBJ file relatively quickly and then the interface is quite fast, but the missing vertex normals may give less uniform shading?

For smallest file size and slow down, ensure you are not getting triangulated meshes for your simple box forms. Get them to be quads. I grabbed vertex points and used Convex Hull to do that. That won't work on your L shaped beams though.

Attachments:

• OBJ Mesh Exporter A.gh, 9 KB