Use of tab to ignore all other distractions when moving ortho not working

Hi
V5
One of the best things I ever learnt/was told was in ortho view when wishing to move cursor straight, e.g moving an object, or scaling, or copying, to start the move and before it latches onto something in a different plane, hit tab, then whatever is proving attactive to the cursor gets ignored.

iN V5 this is not happening, its seeing things and proving a real struggle. I just cant get the cursor to go the journey, it might misbehave early on, or I am almost there and you can see it jump to something else. (Project is not on)

NIGHTMARE.

whats happened ?

Steve

It’s news to me that it ever behaved as you describe.

Start (pick first point), then move
Press the Tab key.
The marker is now constrained along the line between the first point and the point where the marker, was when you pressed the Tab key.

This is (no surprise) in the Help

Holding Alt toggles the OSnaps, not Tab. Holding Shift toggles Ortho. Tab is just a direction constraint.

What always worked foir me isnt working.

I have been hitting tab and its been overiding any snapping away from the ortho planar directionI want to go, yes its a linear direction but also I was told that it stopped the cursor snapping to thing further away from me or nearer me as I travelled that straight route.

Now its just not doing that in V5.
So from what you guys say, I do the following.

I want to move the control point at end of a curve to a point I just made which is a few mm above it.
select line hit F10
Move tool and select end of line point
start to move upward and  in perspective view I can see my curve whipping away to somewhere,
so hold Alt down,
I need to go straight so hit tab and a menu appears on screen showing me all the prog I have minimised !

Alt and tab is obviously something I have never used and is not possible here.

try again,…select point at curve end , start to move and curve in perspective view is whipping away somewhere else, so hold alt down as soon as i select the point, i have ortho on so it should move straight up screen, and it does,
I arrive at my point, but how can I snap toi it, let go alt and the line whips away again on perspective view !

In V4 I didnt get this happen. I never used Alt. I just cannot move this point/curve.

I need something that will ignore all snaps that can happen except along the planar route in ortho view that I am moving the cursor along. Tab did this. thousands and thousands of times. Unless I have ben in a dream.

I just cant do the basic of things here and move something planar in a straight line ignoring snaps to other objects in any other direction.

somewhere I have the article that said use tab, the post would have been in the days of newsgroups in outlook express so wont be found here.

its ok holding alt down but it disables snaps even on my route and I need it to snap to where I am going, in this case a point, could be an int or end or whatever. release alt and it finds something not on my route but further away into the screen, to put it in laymans terms.

Steve

Steve

Steve

Alt+Tab is a windows Shortcut and will override all software short cuts.

You should Tap TAB before holding down ALT.

But if you wish to snap to an Point won’t you need OSNAPS to be active?

Maybe you are looking for the Planar/Project combination. Have Planar Activated in the Status Bar select the point to move start to drag and then go and Toggle Project on the OSNAPS toolbar.

Alt toggles your object snaps - if they are enabled it disables them (while held down), if they are disabled it enables them (while held down). You cannot to alt+tab as you found out as that is a Windows convention for switching between open windows.

Tab locks the direction to a line between two picked points - the first one is where you have already picked (before hitting the Tab key) and the second one is the one you picked after hitting Tab. The movement is then constrained to an infinite line between these two points. Object snaps are still active, but the snap will be projected to this line - so no matter what you pick, it will stay on the constrained line.

But why do you need tab in this case at all? What’s wrong with just selecting the line end point - with Point osnap on, hold the left mouse button down and wait for the point osnap to light up, a fraction of a second - then continue to hold the left mouse button down, drag the line end point to the new point wait for the osnap to light up again and release.  This is called “snap-dragging” - you can only do it in V5, not V4.

–Mitch

You say Pick then Tab then Pick to get the constrained line.

I have always done pick then start to move in the direction I want then tab, before I sense its going off in a direction I dont want using other views to spot for such. Then I keep moving . I dont click the mouse again until I reach my destination.

Tab locks the direction to a line between two picked points

What would your second pick be on, as surely that places the item I am moving, and I want my locked direction to be happening before the second pick, as it does for my method, the second pick is the ‘I want you placed here click’ ?

When one moves things, first click is select it, second is place it. tab for me or anyone surely must occur between the two.

The movement is then constrained to an infinite line between these two points.  Object snaps are still active, but the snap will be projected to this line - so no matter what you pick, it will stay on the constrained line.

EXACTLY. Thats how it always has been for me. I can go along this constrained line and when I reach my destination it snaps to it, the item will be moved and stay on the constrained line, wherever the point that the cursor is snapping to, the item will have moved planar along that line, it wont have jumped to somewhere else nearer or further away in the ortho view in the second click and it wont have been acting like a puppy dog on a lead along the route.

But why do you need tab in this case at all? What’s wrong with just
selecting the line end point - with Point osnap on, hold the left mouse
button down and wait for the point osnap to light up, a fraction of a
second - then continue to hold the left mouse button down, drag the line
end point to the new point wait for the osnap to light up again and
release.  This is called “snap-dragging” - you can only do it in V5, not
V4.

Just tried that and with ortho on, and it doesnt take much for the point to move away from the straight line I want to move it in, it gets to my destination curve and kicks out, if I hit tab it cant kick out, it goes dead straight and no chance of any deviation whatsoever at the curve. I have found that to be 100% sure of the route, no deviation of any kind, especially subtle that I dont spot, tab delivers ! 100% faith in the direction and linearity of it with tab denying osnaps pulling my object off its linear path.

In the item I was having great problems with, I tries moving the item without tab and it behaved, hit tab as I am moving it and then its reluctant to move, being held back, or its acting up , hit tab again and its travelling smooth, I am in control etc, in V4 tab gave control, there it lost it.

Something is different in V5. Tab made sure it did as you say, the destination click saw the point of the item I am moving remain on the constrained line.

Tab definitely during a move is losing me control, in V4 it gave me control.

Danny…
You should Tap TAB before holding down ALT.

But if you wish to snap to an Point won’t you need OSNAPS to be active?

Yes, Alt is of no use as I need the Osnap, I just want the move constrained with Osnaps happening but not affecting the move, and giving me the osnap I need when i get to my destination.

I have never had problems, and now in V5 I have them.

Steve

Nope. Have you tried it??? When you press Tab, the next pick does not fix the next pick point only the line along which it lies. Please try this stuff out. Sorry, this was badly explained. When you press Tab, it locks the direction from whatever the first pick point was to wherever the mouse cursor happens to be - if you happen to have the mouse hovering over a snap point when you press Tab, that will be the constraining point.

Yes. That’s normal. Object snaps override Ortho.

I don’t believe this is the case, I haven’t seen any change, but if you have a concrete example of the exact same geometry that works differently in V4 and V5 with respect to Tab, please post it.

–Mitch

There must be another explanation because the function has never worked like this in Rhino… and to prove it’s not a conspiracy against you:

Here is the Exercise in the Rhino V4 Level 1 training manual that teaches users the function of the Tab constraint.

And I have even dug out the Version 3 user guide (back when proper manuals were shipped with software)

Go here: Screen Capture Software | Snagit | TechSmith.
Make a video to show us what you are seeing.

Hi,

Mitch…When you press Tab, it locks the direction from whatever the first pick
point was to wherever the mouse cursor happens to be - if you happen to
have the mouse hovering over a snap point when you press Tab, that will
be the constraining point.

Agreed…I use it that way…better explained :slight_smile:

Object snaps override Ortho.

Thats why ortho often isnt enough, tab constrains, puppy dog is now on a dog catcher rod and not a lead !

Dannyboyesiom…
the green and gold block example …if as in my attached test the destination can see a variety of cursor snaps happening with small movement of mouse, selecting destination with Osnap then hitting tab isnt an option ! as it wont keep still long enough !

Mitch, I assume the snapdrag is done without using move tool, tried it, same distractions take effect as with move tool.

I reckon something pulled my cursor immediately after I started to move and before I hit tab. I have a busy project with images as well and maybe they are proving too much as soon as I start to move. Puppy dog and too many lamposts !

video of where I went wrong and testiing tab and no tab.
UseOfTabConstrainMove

Steve

What kind of mouse are you using

Logitech M BJ58, gives extremely precise work, I was by the way deliberately being a bit ‘mr average’ in the video to show how easy it is to see cursor distracted.

In my travels in rhino land I can have situations with a lot of distractions, one behind the other for example.

Tab kills those off, its idiot proof, 100% know the cursor will travel straight and not jump backwards or forwards, it might look ok in ortho but turn another view on and you see its gone to something more rearward, tab stops that from happening.

My mouse by the way reaches around the entire screen in 2 inch of mousemat travel, and top to bott in 1inch.

I have pixel precision. Superb mouse, took 3 months to find one that gave 2 inch does screen width.

I will be posting about this when I get 5 mins as Win7 sees me need a new one, my stash of these is killed off by Logitech not releasing the win7 driver for them :frowning:

save mouse talk to my forthcoming thread.

Steve

This must mean that the slightest vibration causes mouse movement, which is your enemy here not the tab key.

Any mouse can do that if you set the speed and acceleration sufficiently. My M705 goes across both my 1920 pixel wide screens in about 2 inches…

–Mitch

This must mean that the slightest vibration causes mouse movement, which is your enemy here not the tab key.

For others maybe

BUT NOT ME,…No, trust me, I am pixel perfect, I have a 1920 pixel wide res screen and can move the cursor one pixel at a time ! fact ! people are amazed at my dexterity. I have been using this mouse with rhino V4 since day 1.

getting another when this is THE MOUSE for accuracy will be a challenge, its fine, Logitech want shooting for not bringing out mouseware drivers for win7, they killed of millions of mice with that move, but thats another thread as I say.

I did say I was deliberately moving it a bit to show what happens if mr average tries it.

The issue I had was that I have so much going on behind the point I was moving that I had no chance to hit tab before it had found something I didnt want it to find ! Or thats what I think. I am still finding things different in V5, cant quite put my finger on it but I am racing against the clock and just dont have time to mess about analyzing all the little gremlin things, are they me, are they different to V4, but something is going on. I need to save out the file to V4 and try for the same move there, but the jpgs I have all went grey, I went into properties to point the item to the source and it made no difference, so another issue/threre when I get 5 mins, one thing after another. I cant tesy fully until I can replicate the file exactly, unless the move is no where near an image, most are.

V4 didnt give me the niggly acting uip cursor I am geting in V5. same mouse, so its not the mouse or me. I just dont have the time to stop and analyse each instance of V5 acting up on me. maybe its just the busy file, getting busyer as I add to it.

Steve

I don’t think the mouse is an issue here, but rather familiarity with project (and planar). See if http://screencast.com/t/Noemj4MjeSG helps.

Also as a side note, if you incorrectly set your direction constraint with tab as you did in the first attempt in your film, you can just hit tab again and that will clear the constraint. You don’t need to cancel the whole command.

Sam

Does that not defeat the objective of what you are trying to show that this does not work for your workflow.

I usually find that moving in a slight circle around a point is enough to trigger the different OSNAPS available but when I get the one I want staying in that Quadrant allows me to choose it correctly.

In an actual build, as opposed to this test piece where I tried to mimick stuff in the background, with my very precise cursor moves, it will seek out things in the background at my destination point.
Its finding all sorts of stuff/distractions beyond the destination point.
Tab stops this from happening, somebody in Rhino made it so, no doubt after users struggled to keep things linear and planar, so I aim to make use of this feature so kindly presented to us. Just make sure that at point of departure the cursor isnt already distracted/snapping off somewhere else.

Steve