Godot: 3D editor zoom limit

[eon-s]

Ubuntu 16.10 - Godot version: 2.1.2

Issue description:
Editor zoom gets locked in a specific point for no apparent reason.

Opening a new viewport, gets locked somewhere else.

Example of the closest zoom for 3 viewports:

There is no indication anywhere about editor zoom values, limit or focus, and the lerp is really annoying when moving or trying to zoom out.

---

Instead of zoom I would prefer a "forward" camera movement...

Steps to reproduce:
Try to zoom close in 3D, open another viewport, move around, try to zoom to the same place.

Link to minimal example project:
Platformer 3D demo.

[bojidar-bg]

Duplicate of #7591?

[volzhs]

I too prefer to move camera forward instead of zoom.

[eon-s]

@bojidar-bg closely related I think; if is a zoom, the editor must give more information to the user, like zoom value and focus location (for rotation too), a temporarily visible icon when zooming (and rotating) could be enough.

@volzhs an editor option to change zoom to forward ?
But zoom is needed for rotation center...

[Zylann]

It all comes down to focus, what the user wants to look at.

Replacing by moving forward has a problem:
What if you focus a small object with F, how fast is the zoom going to move? If it's too fast the camera won't be easily locked on the object and just go away (and I don't want to use a different keystroke there).
If it's too slow, it will be as annoying as you show, but only if you don't pay attention to how 3D focus works.
Also, as @eon-s said, you need that focus information in order to rotate around it, which is really useful.

That "locking" is present in lots of 3D software.
You have it in Blender.
In Unity though they have a hybrid approach: if you zoom on something, it will get slower and slower, as you would expect, until some close-up point is reached and starts again to accelerate, letting you go forward through it, and even has a middle-click shortcut to adapt the editor's camera near plane to what you are focusing/clicking on.

The current default control scheme treats zoom and pan with a center-of-rotation. On the other hand, it treats Alt+pan as translation, so... why not consider Alt+zoom a forward translation too? Or see if Unity's approach is doable?

[eon-s]

@Zylann Blender does that horrible ultraslow lerp thing and I don't know if anyone finds it useful :smile:
An alternative to do a "forward" will be nice, still I would like to know where in the 3D space is the current focus and/or how far is from the current camera, it could be shown as a distance number with the "perspective" label too (because is different on each viewport).

[Zylann]

Which "lerp" are you talking about? If you mean "tween animation", I didn't see it anywhere, except for focusing on a object, for which it is useful.

[jmf]

Scrolling the mouse wheel actually moves the camera forward. It just does so until it reaches the origin, where it gets slower and stops. This behavior is the same as in Blender and many other 3D programs, so people who use those programs will likely expect that behavior.
An option to switch to FPS-like controls would make it way easier to navigate for people who aren't used to the standard 3D software controls, plus it would make navigating big scenes way easier for everybody.

[eon-s]

@Zylann maybe has a specific name I don't know, I mean the thing that affects zoom and movement in relation to the distance of the camera and focus, you need several wheel rotations to get a decent speed zooming out and many screens to move one unit to a side on max zoom.

@jmf some call that zoom :) , and we don't know the origin (focus), is not at (0,0,0) if you move the camera, I will like at least to see where or how far is for better 3D navigation.

[Zylann]

@eon-s it's exponential zoom, which is also the best you can do in 3D when it's about zooming on something (the same in 2D), because it doesn't rely on the size of things. Never felt this frustration when you use the mouse wheel but one tick is too much, and one tick back is too far? ^^

There is also an alternative to zooming back: the Home action, which is the same as focusing the scene to see it as a whole. FPS mode can help too, I remember UDK had that (maybe UE4s still?). But again, at which speed is it supposed to move around?

I understand rotation point mode can be frustrating if used without focus in mind, but I don't think there is a silver bullet in 3D. Mostly hybrid approaches and knowledge of the controls are involved. In any case, a view system must be aware of what is in view, otherwise there is no reference to take values from. In 2D we know it's pixels matching the viewport so there is no ambiguity, but not in 3D.

Edit: bear in mind 3D could also have orthographic mode. It sounds unrelated, until you switch to perspective :p

[eon-s]

@Zylann Godot is not a 3D modeller, is a game engine, navigation on scenes needs to be good enough for designers, not for modellers.
For the correct min/max speed, "Editor Settings" :P

[Zylann]

@eon-s designers or not, I call this a 3D view. No exceptions there^^ it should not be a swiss-knife indeed (like having a way to roll, or making an angled focus like in 3DSMax, these are out of scope clearly), but I still find focus-point zooming useful (and orthographic too since games can have this view too).

There can be an editor setting, but it will be flawed if it's only a speed in units/drag, because it will need to change too often due to the size of things being different depending on the game or even within scenes.
It needs to be exponential too so the further away you are from objects, the faster it goes, and the closer you are the slower.

The key point I agree with (which is the issue), is that it should not lock when getting too close. One way to overcome this is to to control how close the camera can get to the bounding box of objects, this way you will control how much objects enlarge in terms of factor, and not with a fixed distance unit.

[eon-s]

@Zylann is this, right?
https://github.com/godotengine/godot/blob/98baec68809ebf2dc15dbd44822bb945b039ae6b/editor/plugins/spatial_editor_plugin.cpp#L1423

and/or this https://github.com/godotengine/godot/blob/98baec68809ebf2dc15dbd44822bb945b039ae6b/editor/plugins/spatial_editor_plugin.cpp#L705

That looks like an arbitrary speed drag and distance lock, hardcoded.

---

That cursor.distance may be the thing that could be exposed and shown in the editor so the user gets a reference or use the value for an editor plugin.

[Zylann]

That is not a speed in units/drag, but a factor (look below how it's used). There is still the need for that, my point is we can't fix a linear speed :)

[bojidar-bg]

What about having a shortcut (e.g. Shift-scroll) which would move both the camera and the focus point forward (by some distance, which might be the same distance it currently moves the camera by)?

@eon-s About exposing the distance to the cursor, I guess it might be better if we draw the cursor itself, for reference. Not sure if it won't be confusing though, so feel free to comment.

[eon-s]

@bojidar-bg yes, drawing something similar to the origin, and can be shown while moving the camera only, and/or maybe toggled, like grid and origin.
I think that it won't be more confusing than blindly trying to center the rotation on a point or zoom in more when cursor is too close.

[Zylann]

Showing the focus point will be kind of dull because you'll end up with a static spot always in the middle of the viewport. The only thing it will eventually do is disappear under objects if their Z is higher. It depends how it looks though, if it's a world-space cross line thing it could also show orientation (but personally I will disable it if it's implemented :P)
You could experiment this though, see how comfortable you feel when using it.

[Einlander]

I too think that the 3d view should not have the controls of a 3d modeler, because it is a game engine. If you make a closed scene and need to navigate inside it becomes very difficult. It should work similar to other engines, hold a mouse button to freelook and while holding the mouse button wasd will navigate as if it was a spectator camera. Shift will make it fly faster so the movement can be slow.

[Zylann]

Having both modes available would be a good compromise, because each has different advantages and limits depending on the scene.

[ghost]

I agree with the idea of freelook. WASD movement is one of the things that I really miss in the engine.

[Zylann]

I created a branch on my fork and implemented freelook quite quickly. A bit rough but works fine^^
WASD movement should be simple too while RMB is held, however it depends on the user's keyboard, so I wonder if it's better to use the arrow keys instead? (which are in turn used already by some focus handling, not sure why/how).

[eon-s]

@Zylann nice!
Ouch, the 3D view does not grab focus?.
But WASD is ok, I guess (it could be a toggled menu/button option just in case somebody else want to use the keys).

[Einlander]

@Zylann you think you can add an option to set the keys you want to use?

[Zylann]

Added movement, works great as well: https://www.youtube.com/watch?v=lmFVNVHTBFk&feature=youtu.be

My only concern would be that it's a bit difficult to automatically adjust the speed after you flew around using freelook. For example, if you go from a far point to a close up with an object, then use orbit or pan, you'll suddenly move away very fast because they didn't change in between.

I thought about getting depth samples from the view to determine at which distance objects roughly are, so that freelook can adjust pan & orbit distance, but I don't know how to easily get this info.

If you think it's ok already, I'll add some options, cleanup and PR ;)

[Zylann]

I made a PR for freelook, however it's an alternative to the existing system which is better fit for focus-less free movement, it doesn't replace or modify existing stuff, so current zoom is unchanged.

[eon-s]

@Zylann that will solve the movement problem made by zooming to get forward, do you think that will be better to keep this issue open in case somebody comes with a solution to the zoom limit and speed?

[Einlander]

Should it zoom at all? It could just vector the camera forward in the direction it is looking at instead of zooming. The pan and orbit would still work as it does now.

[Zylann]

I explained above about the wheel zoom, it's not that simple to "just" move forward.

[Zylann]

How about this for zoom indication? https://www.youtube.com/watch?v=yEcmuY2FqsM&feature=youtu.be

[eon-s]

@Zylann is really cool, you have mentioned the speed in your freelook implementation is affected by zoom too? because this little bar can kill 3 birds at once (freelook speed, zoom and orbit reference).

[Zylann]

Freelook speed isn't tied to zoom distance. One thing I wanted to try instead was, when freelook is used, to set the distance to be recalculated from the depth of what's in front of the camera. This way, when you go back to orbit, it would rotate around a predictable point. However I don't know how to do this efficiently yet. I probably won't do it, trying to find a simple compromise for that iteration.

Note: orbit reference and zoom are the same, it's a distance in code^^

[eon-s]

@Zylann yes, is in the cursor, but the bar can be read in both ways too and is good.

[eon-s]

The freelook mode #8616 and zoom bar indicator #8689 solves the location reference and navigation problems on a 3D viewport.

I'll close this so other issues can be opened to discuss these new features if needed.

[Einlander]

Is there a way to lock or disable the zoom? I can't stand the way it currently works and I would like to have the option to override the mouse-wheel with the W-key behaviour with gdscript.