Not sure which to select these days… V5 or Serengeti as the tag…
I’m going to be using square pyramids make a sound proof wall all around, and I was just testing
and just arraying it would freeze Rhino. (which I seem to have done after applying materials)
I can do all the arraying at a later time once I’m finished with other things, but…
is there a way to shrink the load? Is this like more Ram the better?
Should I boolean it then create like a mesh instead?
I would say meshes - a pyramid with 5/6 mesh faces should be pretty light, plus you can join the arrayed meshes into one large “disjoint” mesh which should speed up the display… --Mitch
Create first a block out of your pyramid. Then array the block. Especially for Raytraced that will help a lot, as only one mesh will be pushed (but for each instance an object container will be pushed, so startup still may take some time if you do tens of thousands or hundreds of thousands of instances).
I tried here locally with 10,000 block pyramids and 10,000 mesh pyramids. The shaded or rendered display in V6 is pretty fluid here (GTX 1080Ti), can’t really tell the difference between meshes and blocks. In raytraced, when you spin the objects in any case it’s just a bunch of random pixels, the time for it to “settle down” to a readable image when you stop rotation looks about the same for both to me…
@I’ll try it out. Thanks for the advice! I’ll try with
meshing and see how that goes.
Thanks for the tip, I’ll also try out blocks. I haven’t usd block command that much but a good
time to learn it.
yes, having lots of triangles will still take a long time to converge. Using block instances is meant to decrease memory usage. One mesh with three triangles (simplest convex mesh) is a whole less memory than 100000 times the same mesh actualized as actual meshes, i.e. not instanced. Unfortunately it won’t magically speed up raytracing 100000 times (:
Well, in a test here:
10K discrete pyramid meshes (5 faces, 4 tris and one quad) - 10.4Mb.
10K blocks (from same mesh pyramid) - 3.4Mb
10K pyramids from first example joined into 1 mesh - 1.3Mb
I am talking about mesh data being pushed to the render engine (: your right that for this case it is definitely cheapest to join into one big mesh, and ensure double vertices and edges are removed.
The moment the mesh data exceeds the size of the memory footprint of an object (still talking Cycles here, but I guess the same holds true for a block instance) it’ll be cheaper to use block instances.