Another thing to consider is curve or surface complexity. It might not only be a block. But it could be become an even greater problem with blocks and repetition in general. In architecture you often see dwg, dxf imports. Sometimes settings are incorrect and suddenly you get circles, arcs or splines with dozens if not hundreds of redundant control points. It makes a huge difference in terms of performance if you deal with rational single/low-span geometry or (unnecessary) non-rational multi-span geometry of high order. Complexity reduction is not so obvious and easy to do, but it is a skill which also comes with other benefits.
1 Like
Or CPU rendering, for those of us using such archaic technology 
5 Likes
Is that still even legal these days? 
4 Likes
With 32 physical cores, you can also open Rhino 64 times and work truly in parallel. My wife does this all the time. And I did it once either. As soon as you need to cut out holes of any kind, you can divide it into independent geometrical sectors. Without the need to write code, you can then physically perforate anything within the deadline.
1 Like
sounds a bit fancy to me. this must be very heavy calculations if you have time to open 64 instances in a row and give instructions to make calculations that take half an hour each.
I think what makes many operations heavy is the display remeshing after the operation. I often work in wireframe display to cut literally thousands of traversing holes and recreate the rendering mesh afterwards by setting it back to ghosted or whatever. Saves literally days of calculations.
1 Like
itās called moonshine rendering and we do it in our basements at night:)
3 Likes
Marketing idea:
āWe are a classical 3D visualization studio. All our renderings are done on a single-core CPU, because we believe the old ways of renderings and the anticipation that such arcane process builds. Each of our renderings is precious, at a vintage VGA resolution, and we display them in CRT monitorsā
5 Likes
So we use blocks that are embedded and linked to describe repeated parts. We do a lot of panelizing and will have roughly a dozen panels hundreds of times. We donāt use nested blocks, though we do have them as linked and embedded. (This is because we need the ability to work collaboratively; where one person is placing the block, while the other person is making design modifications to the block.)
What else is considered poorly formed blocks?
I also feel I should describe some of the porblems I have.
- I have lots of difficulty with anything that uses Osnap. It will seem to talk dozens of seconds to recognize a snap. Often times, the entire app freezes while trying to find the next snap.
- Selecting objects can be really hard, especially if the little multi menu pops up and I have to be more specific with my selections.
- Moving around is mostly fine. This is a lot of geometry, but changing view modes (even just from shaded to wireframe) can take a long time
- Screen sharing works only 50% of the time. If rhino isnāt running parallel, why would this even be affected.
- any block command takes so long! whether thatās a selblockinstance, or blockmanager, or updatingblocks
In the end, it comes down to time. It costs more in my time to wait for slow/glitchy commands to work than it would in a beefy computer. It would be especially helpful for McNeel to write an article talking about what to upgrade based on your needs, commands, and performance, etc.
I was not so serious in my previous reply. 
But it is true, I had a couple of occasions where I was in need to cut-out geometry on a larger scale. The split command in wireframe mode is the fastest and most reliable functionality in Rhino. I knew this, however when you deal with hundreds of thousands if not millions of curves you can easily let Rhino work for a couple of hours. Then it makes a significant difference if you use multiple Rhino instance in parallel (in case this is doable, everything has to be atomic) or if you let it run on 1 core.
Although I have to say this was some years ago. At Rhino 5 times, a time where no parallism was easy to achieve, and the hardware was significant slower. If you ask what that geometry that could have beenā¦ well there was a time where in concept-cars anything had to perforated (also in data). Seats, Speakers, Dashboards ā¦ At some point they noticed that mass production is a little bit too expensive, so they dropped this idea.
2 Likes
I disagree. Imagine that we have three surfaces called circle, triangle, and square and we make a macro which first makes two holes in the circle, then three holes in the triangle, and finally four holes in the square. Rhino should be able to make the holes at the same time, but it cannot - first it makes holes in the circle, then the triangle, and finally in the square. It would not take huge amount of programming effort to make it possible. It is not too late to implement simple parallelism in Rhino 8.
Well, no. You have no idea what the issues are with parallelization. You could write the code to do your uselessly trival macro example NOW in a variety of languages. Please give it a shot and see how little effort it takes. Also note that figuring out how to do that one task is a lot simpler than your plan for Rhino to ālook aheadā through a macro, figure out what the operations will do, and then determine what can be done in parallel(of course the only way to do all that is to actuallyā¦run it.)
1 Like
Hi Kyle,
Nested blocks being ābadā may explain poor performance I have noticed recently so I did a test.
I have a file with about 12 subatomic blocks assembled into atoms and then molecules. The molecules are recursive so there are a few levels of them. Inside the blocks are mostly very simple curves on different layers. Only one layer has a curve with a fair amount of control points the rest are simple lines and arcs. The file was about 20mb and even with most layers turned off chugs awhile when first loading then gets a little better but still hangs/is sluggish for a bit here and there.
Following your advice I exploded all the nested blocks (not very fun, super sluggish) flattening everything to just the unnested sub atomic blocks. The file ballooned to over 200mb and is still as sluggish as before. To be fair I exported it to a dwg and opened it in the latest autocad and it was only a little better.
A question I have is why if Iām in wireframe mode viewing only simple curves and most layers are turned off should I struggle to move around and do things? (This question is for both nested and unnested blocks.)
Iāve enjoyed using nested blocks since 1998 (first in autocad LT 95 then soon after in Rhino ever since). They are very useful for moving, aligning and placing complex geometry that is hidden on turned off layers and rides along with simple easy to move align and place geometry. I have noticed through the years the ideal of how I thought it would be more efficient has not always matched the reality probably for under the hood display issues you might help me understand.
As an experiment, can you try exploding all blocks to leave just curves? Iām wondering if it isnāt the actual curve drawing routines that are slow when you have many curves, not necessarily the fact that there are blocks.
Okay Iāll try it and let you know how it performs. Iāll have to do it tomorrow at work on a powerful workstation. It was already a chore to explode the nested blocks.
Should be easier to explode all levels, one simple command ExplodeBlock>AllBlocks and let it workā¦
1 Like
Well now the bit of sluggishness with the 19mb nested blocks file seems not too bad as it lets me climb atop and work with what would have been an exploded 57GB. (If I had been patient enough after exploding for almost two hours. I saw the size in the temp autosave file but the lags were intolerable.)
So I will take responsibility for the vector monster I created, be happy with my nested blocks and do some more reorganizing into a collection of smaller files etc. I do agree it is redraw issue just asking a bit much even for a powerful workstation.
1 Like
Wowā¦ that must be a LOT of curvesā¦
1 Like
Yeah I was a bit shocked at how much it inflated. I am not sure if it was the one curve in each subatomic block that had a lot of control points. Not sure if I have the patience to delete it from the blocks to test.