The top and bottom surfaces are built on that single surface on the side. Extract those and delete them.
Not sure how much of the following is necessary…
MergeAllEdges, ShrinkTrimmedSrf, DupBorder, PlanarSrf, Join, FilletSrf, et voilà:
FWIW, FilletSrf produces a surface on the rounded sides that only partially intersects the side surface and cannot be used to trim those sides. Also, unlikeFilletEdge, FilletSrf hasn’t been upgraded in the RH6 WIP to produce nice revolved surfaces when filliting cylindrical objects. I have had no problems using FilletEdge on this one:
Thank you all for the input! I am getting closer, but still no luck. After performing the recommended commands, I can’t seem to select the entire vertical surface when performing FilletSrf:
Why is that, and is that the root of the problem here?
Can you please elaborate on why these surfaces are degenerate and how to recognize it? I generated this with Grasshopper, didn’t have this problem when I built it in traditional Rhino. I suspect Grasshopper, and more specifically my use of it, is the cause.
Degenerate means lacking some property, order, or structure that’s normally supposed to be present. In this case it lacks the usually required property that the U and V directions cross and not flow in the same direction. This property is needed so that the surface normals can be calculated everywhere on the surface.
As for recognizing degenerate surfaces you shouldn’t have to - the software should do that for you. But since the software doesn’t make the effort the way you find out is when commands fail. For instance if you extract the surface and try the offset command on it that command will fail. Even if you manage to avoid the pitfalls during modeling you may run into problems when you try to export the geometry.
Just a few hours ago Dale Lear said " It is our intent that presenting and managing the Rhino SubD object as a surface object with a clear and mathematically precise surface location and surface normal vectors" It’s nice that he is concerned that new forms of creating geometry are precise and robust, but it would be nicer if the same concern was extended to existing geometry creation tools.
No clue on the simplicity or complexity of delivering such, however, as is obvious, should an implementation lean towards the relatively simplistic, then significant value could be added, as one of of the key drivers of user frustration, and productivity loss, is when something fails, and one either does not know what to do, or when one does, and has to backtrack.
Its not that all surface normals are absent, Its only in the immediate vicinity of the 4 corners of the surface that the problem of calculating normal vectors occur. Or to be more clear the undefined normals are where there are supposed to be corners but there aren’t any corners there because the U and V direction is the same at that point where a surface usually would have a corner.