When making a scene that has many repeated shapes Rhino gets super bogged down. There are two examples that are both similar… surfaces with lots of holes in them. I have a student who is making a rendering of a supermarket. The backs of the shelves are basically like pegboard, so they have an array of holes that he Boolean’d out.
Another example is that I was making a rendering of a pool with lane lines. I made a single lane line disk and then repeated it. The disks have holes in them so they suppress waves in the water better. When I repeat the disks enough to make a lane line that is 25 meters long Rhino starts to really lag. (See the attached screen capture. Each disk is an inch wide, so the sections of lane line there are 13 inches long. This would be repeated about 75 times to make a 25 yard lane line.)
Are these just unreasonable things to try to do? Would it be better to make an array of holes rather than an array of cylinders that are boolean’d out? Are there other techniques we should use? Is there anything that can help other than more computing power?
It would be interesting to make 2 identical files - one with the object repeated 75 times and the other with the object made into a block and then instanced 75 times - to compare the file size.
You might need to consider if you need this much detail for renderings.
Each hole adds a lot of faces to the Rendermesh, regardless of it being a Block or not it needs to be rendered onscreen as a mesh.
So in you example of the perforated shelve backs, I would try and use an image texture to suggest the holes. Eeither by applying a texture with black/drak dorts or by using a dotted pattern as transparency map.
As for the lane disks; you could use texturing as well or remove the inner holes, as they are hardly visible anyway. There is no difference in creating an array of holes or booleans. However, in the example of the disk I would suggest to create separate geometry for the disk, rim and fins. I would not boolean them into one polysurface but rather group them (the fins could be a single fin for both sides crossing through the disk). If you would boolean them into one polysurface, it would add a lot of extra mesh faces to define the intersecting edges)
Last but not least I suggest to try and see how low of a custom mesh settings you can create for objects.
This is done at the object properties panel:
I would suggest doing the holes in a material as shown here. This is in line with what Willem mentioned. The challenge is one of texture mapping in this case so I’ll touch a bit on that in explaining how I set up the file.
On a separate layer I created some trimmed planar srfs for the circles and arranged them in the Front view over one of the pie wedge srfs for the pattern. Then I used a custom display mode also attached here which I named Alpha. This mode has a white background with the grid and world axis display hidden. The hole srfs are given a black material and then the viewport is saved to a file. The trick is then to set up a planar texture map for the surface in the area you arranged the holes without changing the view that you just captured. Assign the planar map for the surface in object props and use the viewport borders for guides when drawing out the planar mapping widget. The black and white viewport capture is used in the transparency channel of the material.
Fence objects are a problem for Rhino. I avoid problems if I create a mesh from the fence and only use this for viz. The original NURBS object can be stored at a disabled layer. If you use this pre-meshed object as block, than you can fill the room.
In projects like this it could be preferable to create two models for the same objects:
For close-ups of a single disc or a group of discs, a detailed model as the one shown would be used.
But when the view if from a few meters away, when you see more than on group of discs, a much simpler object, preferably even just an optimized mesh, would be used.
I would think rather than blocking them, joining all the similar meshes you can would help speed, so an entire lane divider is 1 joined mesh object, not a couple of hundred blocks. There is some overhead on blocks which makes them slower to display than a single large mesh.
