The problem is that Rhino does not make correctly ‘Zoom extents’: the staircase itself becomes no longer visible. Also there are problems with units change, moving/scaling geometry etc:
But the actual problem is that I need to work with this model from Rhinocommon and I can’t add this geometry to the document. The method
doc.Objects.Add(geometry, attributes)
just never returns. The same behavior I encounter for
RhinoDoc.ActiveDoc.Views.Redraw()
method.
I’ve tried to select bad objects - none, also the models seems to be not far away from the origin.
Does anybody has any ideas about why this can be happening?
Or maybe is there some way to check if geometry is ‘too heavy to correctly work with’ so I could skip it and prevent Rhino from hanging out?
I’m running Rhino 5 SR14 64-bit.
Also I’m attaching the original model.
No, this is a ready test model from grabcad as part of test data for Rhino plugin I’m working on.
And I need some how to find out why this polysurface is wrong so I could skip processing it. Otherwise Rhino just hangs out.
Please note, while opening this file Rhino says that the file has corrupted geometry table.
So before asking the question I tried to save the geometry that Rhino managed to read as new Rhino doc without plugin data. But this didn’t help.
Hi Julia - somehow that staircase - the steps -has been created as a single disjoint polysurface. The problem surface seems to be the top fillet on the second step from the bottom - I’ll see if replacing that helps - there may be others.
Hi Clement - the original file, right, not my ‘fixed’ one? if mine, which object are you exploding? @BrianJ has already logged a bug about how badly the original file behaves…
I see the under part of the steps is another disjoint polysurface. Extracting a surface and then rejoining fixes that.
Hi Julia - I think there is still a weird object in my file - the undersides of the steps is also one disjoint polysurface - use ExtractSrf to pull one surface out, then rejoin it - the steps will be separate as expected.
Btw, if I’m understanding correctly this model is not a normal situation: Rhino does not allow to create polysurface from disjoint surfaces. But somehow this staircase was created and it contains such polysurface. Moreover, Rhino says it is valid.
So, if I run into one more such model in future how can I check that underlying object is polysurface with disjoint surfaces via Rhinocommon?
Or maybe such polysurface itself is not a problem? Then how can I identify the bad surface using Rhinocommon?
Hi Julia - I don’t see anything in RhinoCommon that can tell you directly if a brep is disjoint - these are legal, and can be created in Rhino using NonManifoldMerge but they are unusual and could be confusing to encounter. BTW, I don’t think the problems you encountered with the staircase model had to so with the disjoint brep - there was one bad surface in one of these that, as far as I can see, caused the problem.
Nope - nothing was selected in SelBadObjects - just poking and prodding at things until it became clear which object was causing trouble - I think I noticed that ShrinkTrimmedSrf never ended on the step brep, so I picked through the individual surfaces until I found one that, by itself, caused ShrinkTrimmedSrf to baulk.
