Hi, I wonder is there a way to keep the last surface(s) of the filled edges non-trimmed (or extended), so that they will automatically cut the adjacent surfaces that were there before the “Filled edges” command was triggered? I attach an image here to visually explain what I mean. Notice the tiny area of the upper surface that contains a left-over that the user have to cut additionally. I understand that Rhino tries to split the latest filled edge surfaces perpendicular to the edge, but in this case both original surfaces were totally flat and it’s more natural to expect that they would be fully trimmed by the former. The resulting filled edge already has extra geometry that was auto-trimmed by Rhino, so trimming the upper surface in this image should be possible.
It is easier to answer a question when a .3dm file is provided in addition to images and text.
Sure, here is an example. The left model consists two totally flat surfaces joined together (each of them is 100 mm long, but the upper one is shifted by 2 mm for the sake of this example), while on the right side is a copy of the same model where I already applied a 20 mm fillet edge radius. The resulting fillet surface will not trim the two original ones, despite the fact that it’s longer than them (by 20 mm on each side) and that’s clearly visible when it’s eventually extracted and untrimmed. It would be more natural if the fillet surface was trimmed where both original surfaces end, so that the former is 102 mm long instead of just 98 mm long that leaves two left-overs at either side of the original surfaces.
Extend and trim.3dm (61.0 KB)
Use Surface fillet with extend yes in the command line.
I’m aware what the “Fillet surface” does, but it’s none of what I originally meant in my original post. “Fillet surface” is limited to work with only two adjacent surfaces at a time, as well as using a constant radius, while I asked if there is a way to have an extended perpendicular trim for the end surfaces built by the “Fillet edges” command where we can both chain multiple edges and apply variable radius wherever we want. Even in models like box with multiple walls.
Here is another example where I put 3 models as follows:
- The white model shows what the “Fillet surface” does.
- The yellow model shows what the “Fillet edges” does currently (a shorter trim of the end surfaces).
- The red model shows what the “Fillet edges” should do as a more logical solution (an extended trim of the end surfaces).
Extend and trim 2.3dm (244.7 KB)
The answer is no then. Not sure why it would be needed, considering the work around is so easy.
I agree that it’s easy when there is only one edge between two surfaces that needs to be filleted. However, in models with multiple edges and surfaces the “Fillet edges” command is much, much more useful, especially if some of the edges must have variable radius. As I mentioned above, neither of this is possible with the “Fillet surface” command. It’s just pity that “Fillet edges” will not extend the resulting filled surface until the end of the original walls.
There’s always exporting Rhino files as stp. into another Cad package for fillets. I do it all the time.
I don’t have other CAD software except Rhino 6 evaluation that I intend to buy in the coming months when money situation is better, because I’m really happy with its capabilities most of the time and want to make it my primary CAD modeler for the future years. But I don’t see a solution in having to spend extra (huge) amount of money for another CAD program just for the fillets. Not to mention the errors that could happen when transferring the NURBS models between different CAD programs (such like re-trim of the surface edges, unwanted divide of revolved G2 surfaces or G2/G3 ones along creases, etc). I know that SolidWorks is widely used for fillets, offset solid models and other “engineering detailing”, but its $5000 cost for annual subscription for the basic package is above my range of purchase. Months ago I also tried Fusion360 and while it handled some fillets better than Rhino, it failed to make some others. Rhino’s pricing is at the sweet spot and it’s one of the many reasons why I prefer it over other CAD products on the market. IMHO, it has the most intuitive interface and short learning curve.
The very fact that Rhino is capable of creating an extended fillet surface from star to end with the “Fillet surface” tool (like shown with the white model in my picture above) is proof that its “Fillet edges” also could handle such solution (the red model in the same picture) if the programmers decide to add this functionality to the latter.
Why do you need this?
I already explained that in my posts above and it’s clearly seen in the example 3dm files as well. It saves time, mouse clicks and prevents the following inaccuracy:
- The extracted yellow surface from this file Extend and trim 2.3dm . The mid point is where it’s supposed to be.
- Using “Extend by line” to create a line to trim the surface.
- The trimmed surface.
- After running the “Merge edge” command, the mid point is still in its old location, even though this is not accurate middle point since the edge is longer on the right side.
On theory, the “Rebuild edges” will revert the middle of the edge in the proper location, but it often brings other problems with slightly deviated edges on trimmed surfaces. I’m aware that “Rebuild edges” restores the true border of a trimmed surface, however, sometimes that makes certain fillet edges no longer able to be joined to the surface whose edges were rebuilt. The length of the bottom edge before “Rebuild edges” was 600.9794513 millimeters, but after that it’s changed to 600.9783738 millimeters. You can check this by yourself using the 3dm file that I posted yesterday.
How are you determining the “mid-point” of the edge? Are you duplicating the edge as a curve and then finding the mid-point of the edge? Why are you concerned about the mid-point location?
Rhino determines the mid point of an edge with the “Mid” selected in its Osnap bar. In the aforementioned case, Rhino fails to properly determine the middle point of the edge, resulting into inaccurate information to the user. Your last question is self-explanatory and I already answered the reason in my previous posts. No need to explain why people need to trust Rhino for finding a middle point (a point that’s in the exact half-way of the total length of a curve or surface edge). That’s why it was added as a functionality in Rhino in the first place since Rhino 1.
This inaccurate finding of the middle point also happens when two or more surfaces or solids are being combined with “Join” or “Boolean union”. Here is another example where I did the following steps:
- Here we have two separate solid boxes.
- Using “Boolean union” to join them into a single box.
- After “Merge all coplanar faces” Rhino fails to recalculate the new position of the middle point and instead every horizontal edge now has TWO middle points and an extra end point.
- Using “Duplicate edge” to extract a curve from the upper edge results into a curve made out of 2 segments with 3 control points total. It has to be a single segment with 2 end points instead.
You can try it by yourself creating two or more boxes like that and following the same steps. Combining solid models to build architectural or engineering shapes is often used in Rhino and it’s pity that there is no functionality to reset the middle point where it should be - at the exact middle of an edge. This leads to inaccurate snapping of other objects to the wrong “middle”.
I’m aware of what the “Divide” command does by creating 3 point objects when “Number of segments: 2” is being used, but that does not solve the problem with the inaccurate representation of the middle point. and on top of that it requires extra mouse clicks and use of the keyboard.
Here is another example where a solid model is used to extract curves to make a 2d drawing for laser cutting. The upper line also contains two segments and an extra control point (the latter must be manually deleted to make the line appear as it should be.
One way to reset the middle point of the upper edge is to use “Turn on solid control points”, select two of those that belong to the upper horizontal wall (either the left or right points) and move them somewhere, then move them back to their original position. Now Rhino is finally able to find the proper middle point. However, this requires an extensive amount of time with solids that were originally created by multiple solids united together. Not to mention the risk of moving some control points in a wrong location.
that’s because the mergeAllFaces only modify that, planar surfaces regardless of its boundary edges. Then you have to use MergeEdge or MergeAllEdges to solve this.
One thing to care about is the file tolerance and model precision, I often fall in troubles using MergeAllFaces because it generates bad objects forcing each edge and damaging the surface. The alternative I use is MergeFace ( doing it by pairs) or extract the involved surfaces and then using Cap.
The mid-point Osnap is not inaccurate. The problem is that the edges in your polysurface are broken into pieces. The only way you can avoid this problem is to use Rhino’s surface modeling tools and even then you need to constantly check edges to make sure they are clean and accurate. If you want to make complex solids in Rhino with clean boundaries you should avoid the solid tools. And clean boundaries are extremely important if you make complicated solid models. Broken and inaccurate edge will not just make things difficult in Rhino, but it can also make it difficult or impossible to export your geometry to other solid model CAD applications.
I wasn’t able to duplicate what you describe, but that probably doesn’t really fix the problem.It just hides it. What it does is convert a polycurve to a single nurbs curve. That may fix the mid osnap issue but it doesn’t really change the fact that the curve is still broken into pieces internally.
MergeEdge command will do the same thing it won’t fix the problem it will just hide the fact that the curve is broken. It can still come back to cause problems later.
You haven’t said what your end goal is but if all you are doing is joining boxes and then want to extract clean edge curves from those boxes you can run the SimplifyCrv command on the extracted edge curves and that should convert the curves to unbroken lines if box edges started out aligned straight with each other
Another way to fix the problem @Rhino_Bulgaria found is after MergeAllFace explode the polysurface/solid into separate surfaces, RebuildEdges, and Join the surfaces into the polysurface/solid.
Yes you can get a lot of things to work OK if you just have a simple model made of planar untrimmed surfaces.
Rebuilding edges won’t fix broken edges on a complex model made of trimmed free-form surfaces.Doing that can even result in additional broken edge pieces if the rebuilt broken edges don’t match up at the breaks when you join the 2 surfaces back together
Yes, this is exactly one of the problems with the “Rebuild edges” command. Looks like I’m not the only one who avoids to use it. While it may fix certain edges, others may get broken, so there is always the risk of something going wrong.
I am having the same problem as you but I have no solution yet