Vertex slide enhancement?

Is anyone in the know about developments in the vertex slide function? Newer builds are all consistent in an improvement of sorts that a vertex will only slide (G, G) in the direction of the location of the mouse cursor when the function was called. The clamp is permanently on. All this is workable around (just move the cursor and hit G,G again) except for vertices on an edge, which formerly could be moved out on an extension of a segment by using the clamp function © but now cannot be slid away from the surface at all, thereby losing two directions of travel completely. If you are the programmer who is fixing this and I am not clear please ask and I will make a graphic…

I would appreciate any link to a discussion elsewhere about the fate of this tool which is nice to extend surfaces a little without changing their curvature id you know what I mean by that.

I just tested on the zoo-logique recent win32 build and wow, i sincerely hope it’s a bug or an overlook , because it’s frankly so bad and add an extra waste of modelling time to get it done how you need now that i can’t believe it’s an intentional change, just retrying my trusted 2.69, the vertex slide is a -lot- better.

Maybe it should be reported in the bug tracker.

You can still slide in two directions if you make sure that you have one or more edges selected as opposed to a single vertex.

I’m guessing that someone may have found the standard vertex slide a little hard to control because a single vertex can go in four directions and thus might jump around a bit.

I am becoming curiouser and curiouser about the process of making these changes… Who might this someone have been, do you mean a developer or just some user who asked for it to be done and boom it was approved? As far as I know it hasn’t been long since this tool was just enhanced to have this added functionality. I havn’t heard of any complaints. And the clamp feature, as I mentioned, is simply gone! A vertex on an edge actually had six directions to go in before with the clamp off. Now, only four.

If anyone is reading this who cares and is also on the dev team - maybe the UI team? if that’s where this was done - I think you have at least three users (Erickblender, Sanctuary and me) who feel that this is a mistake. The last build I have that this worked properly on is hash 9a1585a.
I also wonder about some - but only some - of the sliders being changed to have no clickable arrows for up and down on them… was that intentional too, do you think, Ace? You seem to keep good track of developer changes. Thanks for your help.

Also I understand that some changes in the development builds are works in progress, but both of these issues seem to be an example of something being fixed that did not appear to have been broken before.

I think when you look at it, from some perspectives, it could be tricky to ensure that your mouse movement is aligned to the edge that you’re slighting the vertex in, a little slip of the mouse and your vertex is all of a sudden sliding on another edge. A quick test of mine shows that only vertex-slide is affected by this directional restriction (though I do think it could be somewhat looser, with the possibility of adding a free-slide option to get the old behavior back).

Having the clamp permanent may also be seen as a tactic to help enforce good quality modeling. In some cases, if the devs. decided to be too loose with how tools operate, you could end up with a mess of overlapping faces, bow-tie faces, and loose edges that could take longer to clean up than if you worked with the more stringent version of the tool. It would make you feel like a rookie in this case, the more carefree you make the tools, the higher the potential for speed, but the more likely a mess will occur.

I thought the official position was that functionality would not be removed to dumb the program down for less experienced users? I guess the idea is that the more experienced you are the better you are able to come up with a workaround. Even if it takes much longer to implement. Please note that I am definitely not arguing with you, Ace. (I know you did not and probably would not make this change.) But the accurate workaround for this task below for example is to define a new transform orientation.


I’m sure there are others, and I do know how to define a new transform orientation. Is it quick? Not really. There’s a lot of importance assigned to ‘not interrupting the workflow’; this the reason given for the new toolbar tabs because scrolling takes so much time. How is this change even consistent with that philosophy?

A quick test of mine shows that only vertex-slide is affected by this directional restriction (though I do think it could be somewhat looser, with the possibility of adding a free-slide option to get the old behavior back).

Only vertex slide has a clamp option… All that needs to be done is to have the clamp option restored. It looks like it’s still there; certainly the bar still says ‘clamp(C) on’.

I believe that needs to be done is to find the correct balance between enforcement against accidentally messing up the model and raw modeling speed. We’re only human, we’re bound to make a mistake in scene creation eventually, whether or not it’s major or minor might depend on a mix of the skill level of the user and the looseness of the tools.

By no means am I saying that Blender should hold the user’s hand as it guides them one task at a time, but allowing mistakes to be done too easily might actually slow you down as you stop to fix them.

I understand your point Ace. But having the clamp become non toggle-able just seems like a simple coding mistake. I’m trying to call attention to it.