Why does Extend Surface stop? (Can only extend in small increments.)

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). :slight_smile:

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.

-Pascal

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 :slight_smile: … 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.” :smiley:

image

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…

GIF

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:

surface  
  
  ID: b09b758a-d234-42f9-91f2-f437de5a586c (2)
  Object name: (not named)
  Layer name: Base 05b::Top
  Render Material: 
    source = from layer
    index = -1
  Active visual analysis modes:
    Edge analysis
  Attribute UserData:
    UserData ID: CE28DE29-F4C5-4faa-A50A-C3A6849B6329
    Plug-in: 17b3ecda-17ba-4e45-9e67-a2b8d9be520d
      description: User text (0 entries)
      saved in file: yes
      copy count: 125
  
  Geometry:
    Valid surface.
    trimmed surface.
      NURBS Surface"U":  degree =3  CV count = 17  (-17.071 <= U <= -0.021)
        "V":  degree =1  CV count = 3  (0.167 <= V <= 1.042)
  Edge Tally:
      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-
image

If you slide the points in a bit and flatten that acceleration-

it extends more as you probably expect…

-Pascal

1 Like

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… :expressionless:

(Together with filleting and unfilleting, I think more intelligent trimming and untrimming is on the top of my wishlist for Rhino 9…)

2 Likes

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. :wink:

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.

My favourite untrim tool is ! _ReplaceEdge and especially its “Select curve” mode.

3 Likes

I consider that more like a “retrim” tool… :stuck_out_tongue_winking_eye: