Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[nemyax]

I'd like to raise the issue of the shifting point of interest when you dolly (RMB-drag outside the circle) in arc rotate mode. It was discussed before but no decision was made.
Steve, you never said yes, but you never said no either. Do you agree that the current behaviour should be changed so that the point of interest is retained during the dollying?

[johnar]

...I was talking about dollying (moving the camera/view forward and backward—RMB outside the circle).

  I don't have any issues at all with arc rotate, but think that maybe you and i use it a little bit differently.
 eg: lets say i have some objects spread around the workspace, and i want to zoom in on the object in the top left corner.This is how i would do it. 
Start in ,(normally),front view.-> activate arc rotate -> then RMB inside circle to bring the view of that object into the middle of circle -> then MMB to zoom in to that object.
 Because using RMB outside circle barely makes a noticeable difference in orthogonal views, (Frnt,Right,Left,Top,Bttm), i'm assuming you're starting from perspective view?
 If you were to start from a different view and have a go the same way as above, then the issue you're explaining might not be such a problem. ?
 
As far as rotating around an object goes. Sometimes it quicker and more efficeint to hotkey back to (eg) front view - arc rotate - rotate view around object from a distance, and once you've got the angle of view right, then, as above, RMB inside circle to center the view of the object, then MMB to zoom in on it.

 

[nemyax]

i'm assuming you're starting from perspective view?

I use a single perspective view most of the time.

lets say i have some objects spread around the workspace, and i want to zoom in on the object in the top left corner.

Select all, F, select object, F. But that's not the point. I want the dolly tool to respect what I'm trying to get closer to (or away from), not change my point of interest. To me it looks like the focus-shifting behaviour is only due to an implementation oversight. You don't get this in any other software.

[johnar]

   

lets say i have some objects spread around the workspace, and i want to zoom in on the object in the top left corner.

Select all, F, select object, F. But that's not the point.

I am in no way suggesting that you simply Frame your object

 

i'm assuming you're starting from perspective view?

I use a single perspective view most of the time

 Well, to me, this is your problem.

If you were to start from a different view and have a go the same way as above, then the issue you're explaining might not be such a problem. ?
 

[nemyax]

this is your problem

No. It hasn't been in years and in a dozen programs, and it didn't start to be today.
johnar, you seem to imply I'm making a nonsense request (that'll be for Steve to decide) and should be using a particular workaround. You also suggest zooming, which in a perspective view means changing the FOV. But this is about dollying, which means moving the viewpoint in and out. There's a place for each of them; zooming works fine already, but it's no substitute for dollying.

[johnar]

johnar, you seem to imply I'm making a nonsense request

Not at all. Just thought you might be overlooking something.
 Arc rotate viewing in perspective view can sometimes cause odd results. Thats all.

EDIT: I've always seen the arc rotate as an 'object viewing tool', to 'pan, rotate and scale' your object workspace view. Not as a 'camera'.
 I understand the difference in dollying and zooming, but consider those to be camera options, therefore scene mode functions.
 So, a misunderstanding, not a belittlement.

[Raxx]

Moved to the v0.98 discussion board.

To me it looks like the focus-shifting behaviour is only due to an implementation oversight. You don't get this in any other software.

I don't think this was an implementation oversight. The purpose is to let the user move both the view's location and pivot point, the same way it does when panning inside the circle. This way you don't have to rotate the view all over the place trying to get the pivot point inside, say, the tip of a finger. Instead you can pan to it and then RMB drag outside the circle until you see the pivot is where you want it. This is spectacular for when working in orthographic views, and I think Steve implemented it with that in mind since ortho is what most users would use. (granted, component framing would render this feature fairly trivial...but still good for tweaking view position)

My suggestion is to use MMB to dolly instead of zoom. That is, it moves the view forward/backward while its pivot point stays in place (as nemyax suggested--visually this only affects perspective view). Retain the RMB-outside-circle functionality for ortho users' benefit and random scenarios for perspective users. Change FOV zoom to shift+MMB (ortho won't have noticeable changes). The only conflict is the camera system in the scene editor--so just make MMB move the camera forward and backward instead of changing the FOV. Camera movement is changed far more often than FOV (or should be, in cinematography), so making MMB move the camera makes sense.

[nemyax]

My suggestion is to use MMB to dolly instead of zoom.

That would be awesome.

component framing would render this feature fairly trivial

Absolutely. I just didn't dare cram two requests into one thread.

[Steve]

nemyax: Currently the RMB dollies when dragged up and down outside the circle to the exact point at which the viewer (perspective views) or the camera (camera views) is aiming - the center of the screen. I don't understand how you want this changed.

Update: Do you mean to keep the camera's height above the ground plain constant?

Note: there is a bug in the camera view - the camera's movement isn't changed in the animation keys. But the temporary change in view does what I describe.

[nemyax]

Steve
No, not the height.
Suppose you framed an object with F in a perspective view. Now dolly away from it and arc rotate the view. In the scheme that I'm proposing, the rotation still happens about the centre of the object (the arc rotation pivot has stayed put). Currently in Anim8or, it happens about a point that's closer to the viewpoint (the arc rotation pivot has dollied along with it).

[Raxx]

To put it in simpler words, the forward/backward dolly action needs to happen without moving the view's pivot point. The pivot point currently moves with the viewer when dollying. It needs to stay put and not move with the viewer.

[Steve]

OK so 'F' framing would set the pivot in the center on the object in X/Y/Z. Moving sideways or up and down would move the pivot. And of course rotating would rotate around the pivot.

Note: This means you can't dolly forwards beyond the pivot point.

[nemyax]

'F' framing would set the pivot in the center on the object in X/Y/Z

Would it be difficult to frame selected points/edges/faces, as Raxx pointed out?

Moving sideways or up and down would move the pivot.

That's right.

This means you can't dolly forwards beyond the pivot point.

Yes, and you should decelerate as you get closer.

[Steve]

Would it be difficult to frame selected points/edges/faces, as Raxx pointed out?

No, but that's a different subject   I'll be adding it soon

[nemyax]

I'll be adding it soon

Super!