Video says it all, I think… note that osnap is OFF in this video!
Also note that camera angle doesn’t really matter. The surface only wants to extend in small increments, for some reason.
Yes happens to me quite often
Hello - does it behave any better if you SetBasePoint to the location you are dragging?
-Pascal
Hi, I suggest to use the “Untrim” command (set “KeepTrimObjects=Yes)” and see if the “Extend surface” command will work better on the edge you want to extend. This kind of an issue usually happens when another edge of the surface is already trimmed. “Rebuild edges” also could solve it if you try to extend a trimmed surface.
Also, check if there are overlapping control points somewhere along the surface. If that’s the case, then maybe “Remove multiple knots from surface or curve” will eliminate the issue. If the problem remains, try to manually pick and remove control rows with either “Remove knot” or “Remove control point”.
1 Like
So what’s the difference between the red and green surfaces here, other than the fact that one can easily be extended, while the other cannot?
ExtendYesNo.3dm (52.2 KB)
Ok, interesting, but that’s still not in the direction that I want to extend, and Rhino doesn’t rebuild during extend, so those CVs (and split edge) should be untouched…
EDIT: Also, merging that edge didn’t help the situation.
1 Like
Aah, try to move objects closer to cplane and run command _extendsrf
1 Like
Wooow… I would never have thought about that!
Hello - the red thing is degree 2, the green is 3 in the U direction - I guess that degree 2 is stopping the G2 extending, tangent extending works as expacted.
-Pascal
Well, moving it closer to the Cplane also worked… which makes it sound more like a floating point error?
1 Like
I guess so, McNeel Wiki
Objects Too Far From the World Origin
Objects that are extremely far (millions of units) from the world origin suffer from display and precision problems due to the polygon mesh vertex locations being represented by a single precision number. This affects the appearance of shading and rendering and the appearance of polygon mesh objects.
One solution to this problem is to move all the existing geometry closer to the origin and make the model there. But, since the model may need to be placed to correspond to survey data that uses the very large numbers of units, this is not always possible. The following procedure can help fix the problem.
Regarding that, @Pascal, pardon me butchering the terminology here, but is the world size floating point precision in Rhino calculated with 32-bit or 64-bit?
(I only know sort of how to ask this because I heard that Unreal Engine 5 is switching to calculating their world sizes with 64-bit precision in order to be able to create vastly bigger worlds…)
I wish I knew… I’ve never even thought of this question.
-Pascal
Single precision numbers are 32 bit, and double precision numbers are 64 bit according to the IEEE 754. Single and double precision math can be done with 8 bit, 16 bit, 32 bit or 64 bit CPUs. Many, probably now most, CPUs have a “floating point unit” which has circuts optimized for floating point arithmetic.
Well, I do see the wobbly meshes in addition to the problems with extending surfaces in a model that I just uploaded to McNeel. But the problematic objects aren’t very far from the world origin, imo.
Do you know what I’m missing? I tried to change the file tolerance, but it didn’t really make a difference.
This happened to me so many times, with simple surfaces close to the scene origin that were not modified in any other way other than using “Extend surface”. The visual feedback of what to expect after completion of the “Extend surface” command does not correspond to the actual result we get. Also happens when I manually write a number for extending and then Rhino extends the surface like 10 or 100 times less than the input number, which is confusing.
New Rule: every command will not make the edit where it’s being asked to make the edit. Rhino will secretly move the input objects to the origin, do what it needs to do, move it back to were it was and the command will just work as if the edit was never far way from the origin.
It’s 2021 people. We can send people to space, we can work with teams all over the world, and we cannot do a trim, extend or fillet because a part is too far from the origin in a virtual world? Come on!
G
4 Likes
Yes it is - but the extension is only predictable in terms of 3d space if the parameters can easily match 3d space - like for a plane. If the parameterization is not consistent then the extension cannot match 3d space. Here I extended by 10. The blue line is an offset of 10 from the original edge, red.
-Pascal