Another bad solid edit result

In the attached, sub-object select the lowest (planar) surface of the object on the “NOK” layer (pink) and move it downward using the Gumball… The result, is, well, unexpected.

Methinks that this sort of simple object should just work… :disappointed:

Obviously it’s the little cutout in the cylinder that causes it to fail, try the same thing with the object on the blue “OK” layer. V6 and WIP - same thing.

BadSolidEdit.3dm (197.3 KB)


I run into this kind of issues all the time.

But, if you extrude the lowest surface of the pink object with the gumball dot, it does sort of work.

Yes, of course it does. The next thing I did. However, because MergeAllFaces does not work (yet) on cylindrical surfaces, you end up with an unwanted seam… that is what I was trying to avoid.

I exploded the pink solid and rebuilt the UV with 3 points instead of 10 in V direction but the result isn’t much better :slight_smile:

Basically the solution is to remove the box from the cylinder, remove the hole (untrim, etc) and then extend both and put everything back together. But at that point you may as well just make a new longer tube and box and BU them together.

Someone at McNeel please fix this…

1 Like

I think SolidEditing should be completely disabled in anything that is not just prismatic shapes with flat (degree 1) parallel/perpendicular faces. Basically Tetris blocks.

The liability of such a careless developed tool is too great in projects these days, you can completely ruin a model or entire project and have no idea about it until the damage has propagated further and then you see it.

It makes little sense to me why McNeel spends a single hour developing new functionality when so many tools are so poorly developed and shipped to customers to basically wreck their work.

In the meantime I’d like to have a plugin that disables solid editing in any situation that these kind of messes could happen. It that something you McNeel devs could develop? It would be the responsible thing to do in the short term.




Please try

1 Like

I got destroyed models in the past too and would be glad if the solid edit tool could be enhanced so that such a kind of model shredding is avoided. Very basic tool, very important to get it perfect run.

I would prefer to have better error checking built in. (But it is a bit of Rhinos nature isn’t it, to leave all responsibility to the designer. There are many tools in Rhino that allow you to produce poor results.)

IMO it should not be that difficult to check for errors caused by solid edit tools. When things go wrong they either fail completely or you get very dense surfaces in the result or the bad edges like in the example posted by Martin.

Thing is, if solid edit tools would be perfect, we would probably also have perfect fillets. It’s beyond the capacity of McNeel to develop something as robust as ParaSolid. So if they have to wait shipping other tools before that is ready you will have to wait until after your retirement for that to happen.

One thing is Rhino allowing me to produce bad results, another is Rhino itself making bad results for me. [quote=“Gijs, post:10, topic:96525”]
IMO it should not be that difficult to check for errors caused by solid edit tools. When things go wrong they either fail completely or you get very dense surfaces in the result or the bad edges like in the example posted by Martin.

Yeah it’s very simple of your model is also very simple. The problem is when you try to edit something like an internal rib/boss height in a fully featured part for molding (made out of tens or hundreds of surfaces). And you are looking/editing at that part with a bunch of other parts visible at the time. Having isoparms visible in that simulation would lot let you see anything.

Most of the bad decisions of McNeel come from “This works fine in my test file of 2 cubes and a cylinder”.

In real production workflows SolidEditing is a model destroyer. I’d love McNeel to address it. Tools like Boolean give you warnings when results are out of tolerance. This tool can make a complete mess and say nothing about it. This is careless work.


I didn’t mean simple for a human, but simple for a computer program:

if the solid edit tool deforms a surface and changes it’s degree (of either the edges or the surface or both) or point density, it should raise a flag. Imo, this is what McNeel should address

1 Like

I agree. That would solve a lot of the problems.

I get it that making a useful solo editing in smithing more complicated that degree-1 surfaces it’s really hard, but at least we should get very clear warnings that things got messy after an edit. Because the weird thing is that this is not even a consistent behavior. Sometimes the tool does work. Sometimes it doesn’t.

Inverting time and effort in error checking (for this solid-editing tools, for filleting, shelling, Boolean, etc) would be a good way to use the fail cases as reports (with opt-in for sharing the input/output geometry) by McNeel to try to get things a big better even before my retirement.


It’s a shame that this super simple example dosn’t work.

But the good thing is for the developer that he can easily retrace it.
And will fix it… hopefully … and hopefully soon…

It is a bit irritating that noone from McNeel has a comment on this all…

I opened an issue for this here.