Rhino 8 blocks and certain O-snap categories causing Rhino to freeze

Hi there. I’m having an issue with Rhino 8, blocks, and O-snaps. It’s going to take a bit of explaining. It’s very rare for me to have any issues with Rhino worth reporting, but this is driving me to distraction.

Right now I’m working on the concept/schematic design of an architectural project composed of (as opposed to being built using) heavy scaffolding. This kind of structure is a complex assembly of very few sorts of objects. I’ve been modeling the tubes with straight curves that have been assigned a basic thickness using the Curve Piping panel, and that works fairly well for design purposes since I can O-snap the scaffolding connectors to the central curves for precisely positioning them. The simulated tubes are connected, at the most basic level, with pairs of “gate clamps” that can be rotated about a common axis. In this model there are thousands of these gate clamps, which of course I created as blocks in Rhino. To keep design work comprehensible, I have a bunch of curves and point objects on separate layers in the gate clamp blocks, representing the various center lines and common rotation angles. I seriously simplified the surfaces representing the actual metal of the clamps, and further reduced the memory requirements for each block by replacing the NURBS surfaces within each clamp block with low-poly mesh approximations, made using the Mesh command. I’ve also placed clamp-blocks on separate layers based on their position in the model, so that I don’t need to have Rhino calculating the positions of (say) gate clamp pairs in the middle of the thickest part of the scaffolding when I am working on sheathing elements on its outside; I turn off the layers representing the categories of clamp blocks that I don’t need to see at any given moment.

So despite the complexity, the Rhino model is not huge (yet) compared to some that my current Windows 11 workstation has seen (and handled well) in the past. Yet I have been having some recurrent slow-downs, where Rhino just “hangs” for thirty seconds or so before I can move or copy some object; during this sort of “hang-up” I can’t get any response from Rhino, and sometimes Rhino may not recover at all, forcing me to use CTRL-ALT-DLT to bring up the Task Manager in Windows to terminate the frozen application. I have set my Autosave interval to five minutes, just so that if I do have to close a frozen Rhino instance, I can recover most of my previous work.

This hang-up or locking-up issue seems to occur more often the more blocks I have visible and selectable in the model. It is also most likely to happen if I have an O-snap category set to anything other than just “End” (Endpoints).

But sometimes I have to use Midpoints or Near or Intersection or Points or Perpendicular O-snaps, and my modeling just bogs down. I’ve begun to wonder if perhaps Rhino isn’t the proper application here, although it has worked so well for the design of seemingly more complex architectural projects, and I’ve been using it for my design projects over twenty years now.

I’ve attached a Rhino model that is demonstrating the issue for me.

Thanks in advance for your help.

conceptual htndtm 033.3dm (5.3 MB)

Hi Lewis - thanks, I see a significant lag in snapping here as well. I’ll investigate… my half baked guess of the moment is this has to do with transforming the snaps - in BlockEdit, the snaps are normal.

RH-82015 Snap lag with many blocks

@LewisW - the developer suggests, for now, turning on/enabling SnapToOccluded to make this better . He’s going to try to optimize the behavior though from his comments I would not look for snapping to be as good as ‘normal’ with heavily nested blocks.


1 Like

That’s an interesting response from the developer, and I will give it a shot. That conclusion about nested blocks does dishearten me, though. A building, as an architectural design, is in essence a complex arrangement of simple, repeating objects, a situation that generally lends itself to modeling through blocks within blocks within blocks…and that’s not even touching on BIM!

Well, I will just have to see how far I can go with this project in Rhino. It will be a good test case to determine, after all these years, if I need to find some other modeling application for certain types of projects.

Thanks for your help, Pascal!

Hi Lewis - the lag time is taken in digging through the nested blocks to determine visibility/occlusion, so if SnapToOccluded is enabled, that testing is not done. In any case I have a fix from the developer to test.

@LewisW - I’ve tested our new internal build and this appears to be far better even with SnapToOccluded enabled. The fix should appear in the next 8.8 release candidate. Let us know if that is better in real life.

Thanks for the report.


1 Like

Thanks again! I will test it out as soon as I can get the 8.8 RC!

edit: Got the 8.8 RC; I was on the Service Release before. I don’t know if this version is the updated one you described or not but it seems to be working with aplomb, no lagging or freezing with multiple O-snap categories set. I’ll mess around with the SnapToOccluded setting and give it a bit of workout this afternoon, and I’ll let you know if I have any further issues.

RH-82015 is fixed in Rhino 8 Service Release 8 Release Candidate.

1 Like