Fillet and chamfer

Hello all-

I would like to execute some simple fillet and chamfer commands on the attached model as per the following screen cap:

FilletSrf and ChamferSrf both fail.

Please let me know what you think.

Thank you!


fillet and chamfer.3dm (3.4 MB)

I don’t see the ChamferSrf failure on this one (Windows RH5 and RH6 WIP). Make sure that the distances are not too big.

As for FilletSrf. When you see a single surface like this:

… you basically know right away that something is wrong. These should be 4 single surfaces.

Run the DivideAlongCreases command and make sure that the SplitAtTangents option is set to Yes. Then select your object.

That surface should look like this after doing that:

Notice the isocurve at the arrow position.

Now FilletSrf should work correctly.

Please check the status of Crease Splitting on your system.
Run the CreaseSplitting command and make sure it is set to Enabled. There’s really no reason to have this set to disabled…

1 Like

FilletEdge may help, but its still not a smooth ride. @wim i did not get FilletSrf to work on any of the surfaces, i used DivideAlongCreases.

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:

The top and bottom surface of your object are degenerate surfaces. You need to replace these 2 surfaces with trimmed planar surfaces if you don’t want commands to fail.

Rhino should identify those surfaces as bad objects. That type of surface will cause many problems.

Yes first extract the bad surfaces then use DupBorder and PlanarSrf to create good replacement surfaces

1 Like

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 use use the command FilletEdge? and select each of the edges?

works for me

Hi Revel - that is because it is multiple surfaces. Looks like for that one, Join and FilletEdge will get it done, or multiple FilletSrf, with Extend=No and some trimming after,


1 Like

Thanks all!

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.

I thought this statement was worth highlighting…

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.

Very interesting. I think the fault in this case lies with my Grasshopper script, and I should have recognized the absence of surface normals.

Consider running “CheckNewObjects” so when bad objects are added to the Rhino file, you’ll be notified right then and can do something about it as they occur instead of being blindsided by them later.

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.

1 Like