When making a polysurface from curves or surfaces, it is very important for me to have splits at tangents.
My “CreaseSplitting” option is set to “Enabled” of course, but regularly, I envounter cases where the splitting is not done and makes subsequent operations fail.
Here’s an example :
DivideAlongCreases>SplitAtTangents=Yes seems to fix it…
I know.
That’s not the question
I don’t even understand the logic behind this.
If one wants a single surface from extruding a curve, then he makes that curve unique by re-building it.
Why does Rhino feel the need to mess with this ?
Editing solids is already super-lame in Rhino, and this makes it much worse.
The surface at the end of osuire’s OffsetSrf example is strange.
What shows it as:
Valid surface.
surface.
NURBS Surface (rational)
“U”: degree =3 CV count = 22 (-2943.80809 <= U <= -2617.70104)
“V”: degree =1 CV count = 2 (0.00000 <= V <= 1.00000)
CurvatureGraph shows discontinuities in the curvature:
RemoveMultiKnot reports no multi-knots.
How is a discontinuous curvature possible in a degree 3 surface without multi-knots?
Hi David - RemoveMultiKnot specifically ignores fully multiple knots so as not to mess up this type of surface.
-Pascal
Pascal, Why is this type of curves / surfaces generated in the first place ?
Why not let the user decide when/if he wants to generate wonky geometry like this ?
The real world is filled of plates with straight edges and filets at the corners ; most of my parts are like that.
I’ve been struggling with these useless rebuilds of multiple curves or surfaces into one for ever.
It shouldn’t be a fight of every instant to hinder this behavior, but rather, it should be something one specifically asks for (and I’m not even sure why one would want this).
Hello - I don’t know what this means - what exactly are you referring to?
-Pascal
See David Cockey’s screen capture.
Why would a set of straight and arc-shaped edges ever get merged into a monstrous unique surface with flat and cylindrical portions instead of a set of flat surfaces and cylindrical surfaces ?
When, would that be remotely useful ?
I guess it lowers the size of the file since it generates less distinct surfaces , but it mostly makes editing and exporting of simple prismatic shapes a real nightmare.
@pascal Thanks for the explanation about RemoveMultiKnot.
There should be an option that no degree 3 and higher surfaces are created with curvature discontinuities similar to CreaseSplitting for tangency discontinuities (aka “kinks”).
Also there should be consistency between commands on whether single surfaces with curvature discontinuities or polysurfaces are created when an input has curvature discontinuities.
To be honest, I side with Oliver on this one - a long time ago, I lobbied for a global option to have crease splitting happen before geometry was generated - the equivalent of first exploding polycurves and extruding/whatever the individual bits then re-joining the result (where possible, of course) - but that did not go through. What was decided was to apply DivideAlongCreases after the geometry was created in a case-by case way…
I think this just did not get coded into OffsetSrf - either it’s just an oversight, or there is a deliberate reason, that I have no idea.
Hi all - I also, generally prefer to split things up - however, there are enough situations where this would be undesirable that the developer is wary of making that happen all the time - for example - Rhino allows users to make surfaces from junky curves - ones that have say tons of control points and slight curvature discontinuities all over the place. This liberal attitude is at least perceived by the devs (as I understand it) as a good reason not to break things up as you and I might like when we use carefully made curves. I know - an option - we’ve discussed this many times, here and come up, so far with the current behavior. Perhaps, @dalelear , you can weigh in and correct any misconceptions behind my comments or expand on them with the real reasoning…
-Pascal
It’s exactly because of this that I often find myself extruding curves without joining them first which is cumbersome to say the least. Personally I don’t have any reason to make these type of surfaces into a single surface.
Furthermore these type of surfaces tend to mesh VERY badly in most cases.
Automatic surface creation with multiple knots should be 1) consistent across all commands which create surfaces and 2) controlled by a user set option.
My 2 Eurocents:
I think the easiest way to solve this situation would be for Rhino to extrude seperate (connected, not joined) curves as creased polysurfaces by default.
The default for joined polylines should be the type of merged surface in the opening post.
That way the outcome would be determined by the underlying curves.
Both defaults should be overridable via commandline.
Ah, and by the way the same problem occurs with when is selected. And yes, it drives me nuts!
Norbert
There’s a lot of reasons why that doesn’t work for me… Some of the simpler ones are, if you have a set of curves that are supposed to form a closed, planar curve boundary (so you can make surfaces or closed extrusions/solids from them, and all they are is grouped but not joined, if they won’t make a surface, it’s hard to tell where the problem is they’re all open curves so you can’t tell if together they still make an open curve, or maybe one segment is not planar or… So you end up having to join them anyway.
Not to mention the fact that maybe you want to edit the curves as joined and not separately… etc.
I agree with these arguments ; by the way, in the example I gave, the starting geometry for the faulty solid was a surface which was offset, not extruded curves.
Editing joined curves… Here’s another irritating Rhino quirk : the crippling extra control points added to joined curves.
It is bad enough that Rhino can’t maintain tangencies while editing a planar polyline with fileted corners, but the extra CPs make it impossible to move even a sharp corner point.
That’s another one of those “The programmer thinks he knows what’s good for you” type of issues.
Here’s a Fusion / Rhino comparison :
With a C# GH component, it is possible to get the proper behavior for OffsetSrf :
OffsetSrf Solid With Creases.gh (13.5 KB)
I agree, why does a polycurve have to be of a uniform degree?
I understand that it makes programming easier, but it makes designing much harder since we need to explode curves to edit straight lines.
So it would be a huge help if Rhino had a turn on controlpoints-for-simplified-curvesegments, kind of like a curves solid-editing-points.
Hello
I had never tested the Offsetsrf function to generate an extrusion, I usually use the extrusion of curves or surfaces. When I do this, I always rebuild my polycurves (built from arcs and segments), precisely to avoid having “joints” in my generated extrusion. I do this when I have to apply curves on developments (=unrolled surfaces) of curved stair stringers. I also do this when I need to use the “interpolate on surface” function to get a smooth curve on the curved surface. I attach an example file that was discussed in another discussion.
From now on I will test the Offsetsrf function directly on my curves to check the operation.
Overall, this proves that you have a choice of functions to achieve your goals, even if you have to know them!
I agree with you about editing attached curves, it can quickly be boring for simple 2D drafting functions.
Translated with www.DeepL.com/Translator
railing.3dm (1.1 MB)
