Are command in V8, V7 and V6 returns “Unable to compute area” when used for this simple surface.
Area command in V5 works properly for this surface. SideSrfProblem.3dm (2.0 MB)
Updated Surface was created using Loft command with Normal type and then trimmed. File has two versions of the surface - both have same problem.
Update Area works with untrimmed version of the surface work. Problems appears to be due to trimmed edge.
Version 8 SR17 (8.17.25063.13001, 2025-03-04)
@wim The problem appears to be at one or both ends of the the trimmed edge. DupEdge the trimmed edge. Extend the curve past the ends of the surface. (Use Extend, not ExtendCrvOnSrf) Untrim the surface Trim using the extended curve.
Area works.
Area does not work if ExtendCrvOnSrf is used instead of extending the curve past the surface, and that curve is used to trim the untrimmed surface.
Hi David -
I don’t need to extend the curve to get the behavior. When I just duplicate the edge, I get a curve that I can explode. One of the segments is 0.00021477 units. When I trim with the curve that is still joined, area fails. When I explode it and only use the “long” curve, area will work fine.
I’m still thinking the real bug is upstreams but I’ll throw this file onto the list…
→ RH-86435 Area: Failure Case
-wim
It looks like both the 2d parameter space curve and the 3d space curve of the long trimmed edge are defective.
If you run DupEdge on that edge and turn on the control points you will find a pile of 4 control points at one end of the curve (window select what looks like one point)
If you run CreateUVCrv on the surface. You will find that the 2d space curve that correspond to that 3d edge curve looks like this: 2d_curves.3dm (2.3 MB)
Do you have a copy of the surface before ChamferEdge was used on it?
Model before and after chamfering. Important: This boat-like object was created quickly to explore concepts and use for initial calculations. It is not representative of what I would consider good surfacing. AreaProblemBeforeAfterDC01.3dm (2.2 MB)
Note: The original surfaces were created using DevLoft. I would not use these surfaces in a final model.
Revised My, perhaps incorrect, recollection of the process I used.
EdgeChamfer 6mm, RailType=DistBetweenEdges Did not trim automatically.
ExtendSrf the chamfers.
TrimSrf using the extend the ends of the chamfer surfaces. Result of trying trim on the negative y side of the model was entire model being trimmed.
ExtendSrf the top and bottom of the chamfers.
I may have exploded the model but not sure.
Plane on the xz plane, then Split using the plane. (Not absolutely certain I did this.)
As I mentioned in the post directly above my memory is I extended the chamfer surfaces, then split them with a plane on the centerline. The chamfer surfaces were then used to trim the other surfaces. My guess is that is the cause of the very short segment which is shorter than the absolute tolerance of 0.001.
I’ve had problems in the past caused by very short segments at the ends of trimmed edges, but since using V8 have seen very few such issues. Perhaps the code used for area is still sensitive to the short segments.
It looks like you extended only at the bow end. The other end was extended by the ChamferEdge command itself. This is a problem that has been reported dozens of times over the past couple decades. The extension is done such that a fully multiple knot ends up right in the worst possible place where it often causes the defective fragmented trim of the base surface. The fragmented edge, like the fragmented extension, is just another Rhino booby trap that sometimes will cause problems with downstream operations.