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!
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.
I mean, the visual feedback that directly follows the mouse pointer shows a fake prediction where the extended edge would be upon completion of the “Extend surface” command. However, once the command finishes the extension is way shorter than the visual feedback. If the visual feedback was able to follow the mouse pointer and show a preview of the result, what’s the reason for the result itself to be much shorter? Happened also on totally flat and relatively square untrimmed surfaces or ones with a very small amount of curvature (like a flat curve that was extruded in a straight direction, then the extrusion can’t be extended properly to match the result shown in the preview).
Hm - I guess an example would be good for this. I have seen edges that do not want to extend but these tend to be trimmed. My hunch of the moment is that the screen feedback and the corresponding 3d locations are not following each other well.
If it happens again I will post a sample model here, as long as I remember to do it. The main problem is that the preview was correctly following the mouse pointer and showed an extended outline version of the surface with proper curvature extension. I suppose that the issue it not related to the view, because it happened multiple times no matter what was he camera position. The surfaces were always untrimmed.
Again, I uploaded this file to McNeel yesterday and mentioned this thread. Is this really too far from the origin?
The measurement are to the surfaces I posted earlier in the thread.
Glad you didn’t say we can send people to the moon … in spaceships designed, enginerded and fabricated in a mix of imperial and metric units…
All you really need to do is subtract boundingbox 0 (Lower left corner) from the inputnumbers and adding it back in to the results. It’s easy to work around, I mean, do you hear GoogleEarth complaining about buildings in Australia beeing too far away from Greenwitch? “Sorry mate, your house looks fashionably deconstructed sine you live too far from the origin.”
And having a dynamically adjusted project origin would be easy to implement too, but it should be done on a high level, in the core of Rhino and is probably a can of worms to bugtrack with all the thousands of commands from the last 20 years that rely on coordinates. So I understand that this doesn’t automatically float to the top of the important-things-to-fix list. But from a users point of view it should be pretty high up there as architecture work a lot with world coordinates, so Rhino isn’t all about products being constructed at W0,0,0 any more.
I hope the big brains finds a way to implement this so it automatically happens behind the scene in a backwards compatible way.
(PS! The trouble with far from origin numbers and accuracy is that in floatingpoint numbers all “whole digits” eats up storage and calculation space from the digits behind the decimal point. Thus accuracy is affected both in visual representation and in calculation)
When using a CPlane to edit or build an object somewhere in the scene, is not the origin zero temporarily moved close to that object, too?
I believe all calculations are done in worldspace and (simplified:) that the C-plane is just a transfomation matrix of the input and output numbers.
Happened again in the latest version of Rhino 7…
extend-grr2.3dm (149.3 KB)
In the past, that was a problem typical for trimmed surfaces or ones with highly accelerated curvature change that would cause a sudden flip of the direction of the eventual extension.
but now in Rhino 7 it happens all the time even with very simple surfaces in my workflow. Not sure why. Also, I noticed that it’s a challenge to extend a cylinder surface despite the preview suggesting that everything should be as expected. Sometimes, trying to extend a lightly curved surface by 200 mm will actually extend it by an extremely short distance such like 0,177234 mm.
This is what the “What” command says for your surface:
ID: b09b758a-d234-42f9-91f2-f437de5a586c (2)
Object name: (not named)
Layer name: Base 05b::Top
source = from layer
index = -1
Active visual analysis modes:
UserData ID: CE28DE29-F4C5-4faa-A50A-C3A6849B6329
description: User text (0 entries)
saved in file: yes
copy count: 125
NURBS Surface"U": degree =3 CV count = 17 (-17.071 <= U <= -0.021)
"V": degree =1 CV count = 3 (0.167 <= V <= 1.042)
4 boundary edges
Edge Tolerances: all 0.000
Vertex Tolerances: all 0.000
Render mesh: 1 mesh 118 vertices 116 polygons
Created with fast meshing parameters.
Analysis mesh: none present
Untrim it and it will be fine to extend in the desired direction.
But don’t try to extend it sideways, because your 1st row of control points goes to the opposite direction rather than following the natural flow of the majority of the control points inside the surface. I think that this surface is a result of rebuilding a more complex surface, because Rhino tends to create those issues with the “Rebuild surface” and “Rebuild surface UV” tools.
The surface increases in curvature on that 'side edge-
If you slide the points in a bit and flatten that acceleration-
it extends more as you probably expect…
Yeah, I wrote about that above. The easiest way is to simply use “Rebuild” or “Rebuild UV” and reduce the amount of control points to the bare mininum, since this particular surface does not need so much control points anyway.
_Untrim the surface first. As already stated, the surface has other less-than-ideal properties, but it appears that the trims are tripping up _ExtendSrf in this case.
I keep forgetting that if Rhino trims one side of a surface, it still adds trim curves all around the entire surface…
(Together with filleting and unfilleting, I think more intelligent trimming and untrimming is on the top of my wishlist for Rhino 9…)
Well, actually there are always trim curves around the entire surface. In the case of “untrimmed” surfaces, they simply correspond with the “natural” edges of the surface. As soon as you trim one edge, you need to recalculate the entire edge loop anyway.
That’s a very back-end thing to expose to the user front-end. I’ve only used Rhino for 3 years, but I have never seen a benefit to this since you can duplicate any edge you want ayway. And as you can see in the above report, it causes problems (not to mention horribly unintelligent “untrim” functionality). But again, I’ll raise the issue properly after 8 is released.
No, that’s just how NURBS work. Surface trims are complete “loops”, so even if you trim “an edge” Rhino has to recalculate the entire new loop with the trimmed edges plus the untrimmed ones.
I don’t know what’s “horribly unintelligent” about the untrim functions, you have Untrim (pick which edges to untrim), UntrimHoles (only interior edges/loops), UntrimBorder (untrim the entire outside border) and UntrimAll.
There are certainly limitations when you have joined polysurfaces, mostly because simply untrimming one thing might cause problems with the other joints.