Move face - farce

unhandled
moveface

#1

Trying to move the end of a cylinder which features a hole…
Still not doable in 2017 in Rhino

Move face-1

Move face atrocity.3dm (46.0 KB)


(Rajaa Issa) #2

Hi @osuire This is a know issue and it is on the pile. Here is a referece to the bug…


#3

Well, it is on your fancy bug tracker since August 2016, but I reported this at leasy 4 years ago, and has certainly been reported by others way longer ago.
In my mind, this is not a bug ; it is rather a manifestation of a poorly designed geometry kernel.


(Rajaa Issa) #4

The direct editing algorithm was initially designed for planar and slab-like geometry only. It was later extended to solve non-planar polysrfaces. It produced satisfactory results in many cases, but it has its obvious limitations. I agree that it should fail rather than produce bad results like the one in your example. In general, CageEdit is more appropriate to use when trying to stretch non-plnar surfaces, especially if they include holes and other complexities. I’ll discuss with the developer, and see if we can address some of these issues.
I appreciate you taking the time to bring this up.


#5

Direct editing has been around for quite a while ; for most CAD systems, it is a non-issue.
Holes are not complexities ; they are omnipresent in design, mechanical engineering, architecture, … they should not pose the slightest problem when editing a solid.


#7

i believe there are different approaches in handling this issue. some applications use an extended history, others work completely parametrically, rhino i believe moves the surface editing points which if not taken care, quickly results in a mess.

the same happens when one tries to tweak solid points too much on something more complex like a cube.
i would also say that these need some rework… but with rhino it unfortunately works that way that if there are not enough voices speaking out long enough its not been taken serious.

but on the other side reflecting this issue, rhino mostly has been a tool for me to finish digitally what i have developed before. punching holes into some pipe and trying to let it do the hula hoop is not how i use it


#8

Blessed is he who is content with little


#9

who can really judge that


#10

For profiles extruded in 1 direction (the world is full of them!!!), I always use Scale1D. I usually block them, so I can change the profile at any time.


#11

Scale1D won’t work in the example given. The idea is that the hole and any other boundaries that are not affected by the extension of the cylinder should remain unchanged. If you extract the cylinder and use ExtendSrf it will extend the cylinder properly. You can then move the face the same amount and everything will join correctly.

This is not a problem with Rhino not having the core tools to do this. This is just the way the solid tools in Rhino work in general. This time its obvious so everyone can see the error. Most of the time the errors are tiny so that you don’t see them until you stumble over them later.


#12

Aha, I totally missed that hole! Yes, Scale1D is not usable in this case.

In general I’m more concerned about having hundreds of extruded profiles in my model, which at one point or another will change sections. That’s why i block them and use scale1d, and if they have holes, i just mark them with circles

My wish would be to have something like a void polysurface which can cut a virtual hole into blocks or any other geometry without actually changing that block or geometry.

Anyway, yes, the example here illustrates old solid tools bugs.


(Rajaa Issa) #13

Initially SolidTools only supported planar faces (and simple extrudes) in the original MoveFace and MoveEdge commands. At a later stage, we hooked some of the UDT technology (the one that CageEdit uses). This allowed free-form objects to be deformed using sub-object selection. There are few special cases that need to be accounted for (the example above is one). I agree that we do need to make it work better. For this work to get higher priority, we need you to let us know how important is it to your workflow, and if current workarounds are painful. Examples are appreciated.
Thank you all for contributing to this conversation.


(Abraham Wechter) #14

Personally I just use MoveFace and MoveEdge for simple solids but it they produce bad geometry in more complex situations I’d rather see a failure notice.


#15

Related to this or ? not ?

I have used move face - with disturbing results on polysurfaces. An example is a rectangular solid, sliced to match an upper and lower contour line [part fitting] and sometimes edge fillet applied. When moving the face, the entire “shape” changes as if stretching it out like pulling taffy. I would expect that in a scale operation, but in a face move, I don’t.

What I would expect is just the face being moved from its current position to a new one, being able to use the same commands available as options such as along curve, normal + …

Perhaps it is me, not knowing any better, or misunderstanding commands. But it would be the most reasonable interpretation - at least to this user :slight_smile:

Again, I may be incorrect, but this often leaves me to duplicate the face border and then extract the solid from there, or the surface and using it for a solid, but everything then requires extra work - joining, unions, +…


(Wim Dekeyser) #16

That doesn’t really say much. Can you post the 3dm file?


#17

Well, here is the say.

Along with the file I have a pic of the single wire sliced rectangular solid, before slice with slice curves intact, and after move face of the two ends after a double ended FACE move - NOT A SCALE, clearly no longer following the curves.

In the drawing, initial shape with slice lines, copied to new location and sliced then face double move.

You can duplicate it and I would expect you have the same result. Please let me know what you end up with, is it my install or is it my understanding of what a face move is?

If you require anything else, feel free to ask.

forum.3dm (89.3 KB)


#18

I guess I should have stated, my idea of a face move is a move of the face, not necessarily following the “overall” shape of the solid. In other words, more along the lines of a face extrude, not a scaled taffy stretch. After all, moving a face, should be the face, not changing the initial geometry. Otherwise, why have a scale function at all.

I am trying to understand the reason I am missing the reason…or as some would state, I am missing the big picture…


(David Cockey) #19

You can use ExtractSrf to detach a face from a polysurface, and then drag, Move, ExtrudeSrf, etc that face as desired. Be aware of the OutputLayer= and Copy= options in ExtractSrf.


#20

Thanks David, I do understand that aspect. I would say my point is, in its basic form, that move face is not reliable for precision. Stated, move face does not keep geometry true to original UNLESS that object is absolutely rectangular or tubular [I think it is called “a simple solid” or “primitive”].

Again, “I” did not expect changes along the entire sliced solid when moving the two end “faces.”

I can move the face in my previously attached drawing using the option “along a curve” which yields much better results but I will not state “maintaining initial geometry.” Good enough? No.

I design, draw, export to CAM and machine. I found this due to what I ended up with while double checking tolerances. Going back to the drawing, I zoomed, zoomed, zoomed and although the screen is not a proper representation, could measure the differences between the original slice line and the new END face moved solid.

Again, perhaps it is my lacking an understanding about how it works or is defined, but this is not my first party and I have been using CAD/systems since the early 90’s [designing and such much earlier, including the original method - hand drawings]. I guess if things are different, then I need to learn and adjust. I think I have adjusted by using alternated methods to "move a face", so I guess I have also learned.

I think I understand what everyone here is getting to, along with what they are stating, that there is always another way or method, but I think it is important to remember the original reason “MOVE FACE” topic [that reason always gets in my way and the topic is in my face].

The one thing I am absolutely positive of these days is that I have learned over the years is that I never stop learning…or adjusting. Cause I surely am having a tough time with the new newfangled way things are done…still better though, I guess…

I yield, whatever everyone is happy with I will adjust to.


(Wim Dekeyser) #21

FWIW, I couldn’t find out what was what in your file. Overly complicating things by posting several pieces of geometry where only 1 should be shown and a clear indication of which face to move where.

Anyway, by reading what you wrote in these several posts, I would say that MoveFace works as designed - though not as you want. MoveFace will move the face, including the joined edges of adjoining faces. These will not automagically grow or shrink or do whatever to keep some design intent in place. Rhino doesn’t know about your design intent - it just moves the face and the joining edges.

Does that mean that it will only work on absolutely rectangular geometry? No, definitely not. Does it have problems in certain situations? Yes, definitely. I would like to see improvements in this type of workflow but don’t expect them in the short run (i.e. within 5 years). I use the command occasionally but for the time being don’t expect too much of it…

Also, porting workflows from other CAD programs directly to Rhino will likely do more harm than good.