Move face - farce

As the slice geometry you use has a taper and the move-face operation follows the CPlane, for this example, if you set the CPlane to a relevant face of the sliced solid, then the stretched result is perfect.

Complicated?

Below is an image sequence of the simplest primitive sliced two sides in the Y plane. Then the upper & lower slices deleted. Then a move of the left only END face some whatever distance. Then a FRONT view depicting the non-object geometry. This non-object geometry is along the entire length of the object. Extend [move face] the other end and more distortion. I wish I could somehow get in on the oscilloscope.

Does that get any simpler? Again, I understand, BUT the issue is with the move face command unless you are telling me that is not the purpose of move face. I asked to be corrected, and am still wondering what is correct.

If it moves the face adjoin edges, then I would expect the face and edges to extend from the surface, not stretch the solid - as I keep repeating - like taffy. I know there are options other than NORMAL, like along curve +, and I have learned to adjust ONLY AFTER modeling and finding an error [my opinion] that I did not expect.

So I guess, apologies to everyone for my ignorance and to Osurie, along with the known issue according to Rajaa, I was reinforcing the topic of “it does not work” whether or not it does what I expect because I certainly do not expect what it gives me, whether or not that is the answer. Apparently, there is an issue or it would not be on the known list of issues. To me that means that it does NOT do what it should.

To that end, I second Osurie’s comments, and commend Rajaa stating the obvious, that it is an issue.

So what should I expect it to do? Be redefined to accept the current situation? Never be corrected?

I can live with that too, and commend Rhino and it’s developers, I love the package, faults and all. I am not going to change and move away from Rhino. I even wish to move on with Grasshopper.

If these comments come off as harsh, forgive me. It is intended to only speak the truth, even if it ends up being only my truth [and apparently a few others like me].

I have learned a LOT on this forum from all of you. I appreciate everything written. I can’t write enough compliments to go around.

That said, today it is a bug and I hope it someday is corrected unless the definition of a face move is changed to reflect its usage. What I can’t help but wonder is where this may play into other commands. If it causes an aberration that is not expected here, then where does that domino down the pipe into other commands or Rhino calculations? Is it everything Osuire states it is “In my mind, this is not a bug ; it is rather a manifestation of a poorly designed geometry kernel” - surely I would think after Rajaa’s comments it is not, but it is based on old geometry and calculations and that will require correction someday. I hope those that are not aware of it and model do not assume it works correctly, else they are on a road to poor modeling.

I stated before, I was done but it appears what I stated, the idea of it and the model was misunderstood.

WIM - I learn from you too, I welcome the comments. I hope this is clearer. Anyone? Semantics drive me crazy. Hey - I have my own fault - scratch that, I just do not work as any of you expect me to.

Apparently the image needs to be clicked on to see the steps - it does not fit the window. That is a feature, not a bug :slight_smile:

Brian - the light comes on!

Thanks, at least now I can sort of understand some of what and why. I think it is not supposed to work that way, but it gives a glimmer based on the programming alluded to by Rajaa - it being based on 2d objects, thus the construction plane pick.

However, I just tried setting the CPlane, one face at a time to the face [using the same end face each time just as in the examples] being moved, then the top face, then the side face, which means I have exhausted the three axis, and I do not get your results although I can understand perhaps why I should. FYI, the slice line creates a compound curve cut, not a taper.

Much appreciated. I can’t believe I got this far into the topic when all I was attempting to do was second Osurie’s comment about work/not work. Trying to give another input of “it needs fixed” - sometime.

Can you answer another question? Since you apparently use this approach, if your method works [not for me yet for some reason], in your use of it do you believe it advantageous to some degree to leave as is and not “fix” it with your experience? Since you seem to have the answer to the original quandary, perhaps you have the answer to this question to.

In the example you provided, the end faces are perpendicular to the world plane, so the MoveFace dragged normal to that chosen face. The split block will follow on behind and result in your pulled taffy (had to google that one…). This is behaviour that I would expect.

When I used the Cplane approach, I assumed parallel sides and set the Cplane to the side face (see the previous post image for the Cplane indicator).

If you set the moveface option to constraint=none, you can drag the shape to follow the Cplane.

If it is a non-regular solid, and you need to maintain the shape, perhaps the best method would be to explode and extend the surfaces beyond where you want to end up then trim back with a planar surface, or similar. Don’t know if this answers your question but hopefully helps a bit. Here are some screenshots which may be of use.

When moving a face on a non-prismatic shape there are numerous alternatives. Consider this example. Design Intent Alts DC01.3dm (193.0 KB) The original has planar top and bottom, and curved sides. The top face was moved up 10 units.

MoveFace preserves the original top face, and stretches the sides to match it. The lower portion of the shape no longer matches the original .

For alternative B the top face was moved and extended. The sides were then smoothly extended past the new top face. The extended sides and top face were trimmed with each other. The lower portion is preserved but the top no longer matches the original moved top.

For alternative C the top face was moved. Blends were created between the side edges and the corners of the top. New side surfaces were created using the new edges. The lower portion is preserved.

Which is the design intent? Will it always be the design intent?

Another example; a four sided truncated pyramid. Design Intent Alts 2.3dm (131.2 KB)
Methodology is the same as the example above. Should the design intent be the same?

Really good information, well done examples and I thank you. I believe this will help a lot of “us” with what “we” saw to be aberrations.

Thanks again. I learned a lot today.