I feel that “ExtendSrf” is just one of those “easy to develop” features that fails to adress the end-user’s needs.
I wish that it was possible to extend the edge of a surface by some accurate width, and not following the UV paradigm which isn’t related to anything concrete and useful in practical terms.
I don’t even understand the relation between the extension factor and the actual result since the width of the extended strip varies in width…
Hello - the extension is made in parameter space so the 3d extension is only consistent in special cases… like planes. I think that on wiggly surfaces with varying UV, the extension should be correct at the extension/base point location, but I’ll have to check that.
-Pascal
Hi Pascal, I think that’s the technical description of the wish: have a tool that extends a row of points by a variable U or V distance so the physical distance matches the ‘on surface’ numerical input. That’s a great wish IMO.
Gustavo
I don’t live in parameter space ; the objects that I try to represent don’t follow this logic at all.
If I need to extend the edge of a surface, it is generally by a certain (constant) width ; not some esoteric relation to the innard of the modeling software.
It’s exactly the same story with meshes generated from Nurbs : they are based on the parameter space which fails to make them reflect the actual topology of the shape.
This is software thought out by programmers : it misses the point.
Hi Gustavo - yes, of course, I understand the wish and expectation, I was just trying to clarify what (I think) it currently does- I don’t think it is at all trivial, if even possible, to extend an untrimmed edge consistently in 3d space - let’s ask - @rajaa, am I overly pessimistic ?
https://mcneel.myjetbrains.com/youtrack/issue/RH-44718
thanks,
-Pascal
That is my understanding. To extend an untrimmed edge by a constant amount along the edge will require using a trimmed edge, or adding control points (perhaps a large number) in the direction along the edge. That’s a limitation of the math of NURBS surfaces, not of particular algorithms.
1 Like
I know that it is absolutely not trivial.
To reprise my analogy, making good meshes requires running a live physics engine like Kangaroo.
Well then, why not invest time and money on a fast implementation of such engine natively in Rhino instead of trying to get the present U-V based meshes out of their misery with a so-called “Mesh V2” ?
Same goes for the Extend Srf tool : there should be an option to automatically extend + Trim a surface edge so that in the end, the edge is offset by the actual value that was input by the user.
Or if the devs can dig deep enough into the maths, why not add control points so that the surface can remain untrimmed ?
In any case, we need to stop pretending that this tool makes practical sense.
When you select a trimmed edge, does ExtendSrf through point does what you are after?
This is what ExtendSrf does in this case (to my understanding it should create accurate consistent distance):
- Edge is “offset” to go through the selected point. Offset provide consitent distance in 3D.
- Offset edge is extended.
- Side edges are extended.
- Surface is re-trimmed.
Now in Untrimmed surfaces, we have to decide between 3 alternatives:
- Trim the surface to keep distance consistent.
- Attempt to rebuild the surface to match the edge and keep it untrimmed (new surface might not go exactly through the old one, but it might in the general case).
- Current Rhino solution, which uses the distance at the selected point, but it will not be consistent across the edge.
So from user perspective, which of the above should the default behavior? Should the user have a say?
Hej osuire,
like davidcockey said, to extend non-rational geometry, a new surface has to be added away from the extended edge or the existing surface has to be parameterised anew. This is inherent in NURBS mathematics and, particularly when trim boundaries from surface intersections are concerned, a loss of accuracy is inevitable.
My recommendation is to provide three options as outlined above, with the trimmed surface as the default. The trimmed surface method results in what most users expect - a surface with an edge a consistent distance from the original edge. The Help description for this option should explicitly state the extended edge may be a trimmed edge.
The rebuild surface option should default to the overall absolute tolerance but with the user able to override that tolerance with a user specified tolerance.
The current method for untrimmed edges needs to be retained. I usually extend an surface edge beyond where I need it, then trim as desired and shrink the result.
2 Likes
We can start with a test command to see how it works and take it from there. Changing surface topology to go through the edge and keep the surface “untrimmed” might cause undesirable result. So does the change from unrimmed to trimmed. Combining all these in ExtendSrf command might be too confusing, at least to start with.
Your concern isn’t clear. Does it apply only to the option to rebuild the extended surface so it has an untrimmed edge. That one is not trivial to implement and could soak up considerable time.
I’ll change my recommendation to initially implement the first option, extend a consistent length by trimming the extended surface, and keep the current method of extending to an untrimmed edge but not necessarily a consistent distance. Extending an untrimmed edge to a consistent distance and trimming should be a simple extension of what is currently done for extending a trimmed edge to a consistent distance.
Sorry, I corrected a typo in my reply above. Hopefully that makes it more clear.
I agree that creating trimmed surface with consistent distance is a good first step.
Hi David - Since the surface can potentially be made quite different and behave very differently from the input when it’s all done, users may end up confused no matter what. I’d say ‘what most users expect’ may actually vary a good deal, depending on what they’re up to at the time. So the idea is to think a bit about how to present the options, assuming they are implemented, in a useful way and not just change the behavior.
-Pascal
Are you referring to the extended surfaces being quite different depending on the option, and/or being quite different from the original surface?
For the option where the surface is rebuilt with an untrimmed edge then I agree it will generally vary somewhat from the input surface and the surfaces from the other options. As I said above that option should be lower priority.
If you are referring to differences between surfaces extended to what ever untrimmed edge results versus extended a consistent distance with a trimmed edge then I don’t understand. The resulting surfaces from both options should be identical where they overlap, and identical with the orignal surface where they overlap with the original surface. If the surface is extended with untrimmed edge is extended to match the hidden, untrimmed edge of the extended surface with a trimmed edge, then the control points should be identical. (Hopefully that isn’t too confusing. 
)
I agree about the need to carefully consider how to present the options.
Hi David - I mean the change, for example, from an untrimmed to a trimmed surface - in the case of an exact extension on a wiggly surface, this would be the result and that is a significant change compared to the input object. I’m just saying that I foresee at least a certain amount of confusion resulting, if users are not both knowledgeable and careful. For instance, you would not be allowed to MatchSrf the new surface, but a moment ago you could… WHAT??? etc.
-Pascal
maybe we need an _ExtendSrfByDistanceOnSurfaceIntoTrimmedSrf command. So people know. WHAT???
That already occurs if a user extends an untrimmed edge and MatchSrf will modify the result, and then extends a trimmed edge (perhaps a different edge of the same surface) and MatchSrf won’t modify the result.
Perhaps the options for ExtendSrf should include:
-
Extend a surface, either a trimmed edge or an untrimmed edge, a consistent distance and the result will have (with the occasional exception) a trimmed edge. This would be a simple extension of how extending trimmed edges currently works.
-
Extend a surface, either a trimmed edge or an untrimmed edge, and the result will have an untrimmed edge (ie iso-curve), This would be an extension of how extending untrimmed edges currently works.
Don’t add an option for extending a consistent distance and then rebuilding to eliminate the untrimmed edge. Instead add a new command for rebuilding any surface with 4, 3 or 2 edges, some untrimmed, into a surface with untrimmed edges. I currently do this using Patch with a starting surface, and can describe how I do it if desired. However that might be best in a new thread.
I still don’t understand what the change compared to the input object would be, even for a very wiggly or folded surface, which doesn’t currently occur.
