Remove 2D view limits

[ghost]

Godot version:

16d4021

OS/device including version:

Arch Linux

Issue description:

The 2D view will clamp your ability to scroll it depending on where nodes are in it; if you add a node2d, or a control, for example, which extends beyond the view's current limits, the limits will extend such that you can move the view so that you can see these new nodes.

There's a number of issues with this:

1. It doesn't respect the node's size in all cases: if your node just happens to have a really long sprite or collision shape, the view will not compensate for that, only paying attention to the node's position; so, you won't be able to move the view to the point where you can actually see it.
2. It makes it difficult to place elements far away; you can scroll out quite a bit, but for a particularly large level, it becomes cumbersome to deal with the view limits. If you wanted to place a platform high above the view's limits, you have to work your way up there.
3. It doesn't seem to have a real point; if the idea is that I might get lost somehow, I can just double-click any node in the hierarchy and the view will snap to it. I don't believe having limits on the view helps me in any way. Maybe a button which centers the view on the origin would be better.

The current workaround is to throw some dummy control nodes into the scene and set their positions to very high values so the view limits stop being a nuisance, but I think the better solution is to just not have limits to begin with.

[groud]

I dont think this is a good idea. Having infinite view is cumbersome for most use cases. Regarding each points:

1. That's not true, most of the time the system accounts the node size, like with the tilemap node for example. If this does not work then it is a bug.

2. This almost never happens, it is a rare use case that can be workarounded by entering the values in the inspector.

3. Well it avoids you to get lost into a void of empty space. Zooming in and out might help, but on laptops without a mouse this is a little bit cumbersome, as setting the zoom is less precise than with a mouse.

[groud]

That being said it might be provided as an option

[ghost]

That's not true, most of the time the system accounts the node size, like with the tilemap node for example. If this does not work then it is a bug.

I tried it earlier today, it does not account for collision shapes; tried it with a sprite a few months back, and it did not account for that either. Sure, it could be fixed, but it seems like work for something that's not very useful; assuming it did account for these things, I still can't move the view further out to place nodes in a natural manner.

This almost never happens, it is a rare use case that can be workarounded by entering the values in the inspector.

It happened to me a lot when building a large level. While true I can just enter values, it defeats the purpose of a visual editor (besides, entering values is exactly what I had to do with the dummy controls.)

Well it avoids you to get lost into a void of empty space. Zooming in and out might help, but on laptops without a mouse this is a little bit cumbersome, as setting the zoom is less precise than with a mouse.

I don't think your average user is randomly moving their view to a point where they might get lost, as their attention is focused on where the action is, and the action isn't empty space. If this logic holds, the 3D view should also receive limitations on where you can look and where you can move the camera based on where nodes are, as you could also get lost there--but I don't think anyone has this issue, at least not which is easily fixed by the above mentioned features, such as double-clicking a node to focus the view. It's going to be cumbersome not having a mouse any which way it happens.

Further criticism: this feature has no settings to control it, from what I can tell. I can't turn it off. I can't set how far the limit will extend from the furthest node. Also: it favors the bottom of the origin, rather than the center, so even if you do zoom out, you can see plenty below, but almost none above.

There should most certainly be a way to control this.

[eon-s]

Limit may need to be extended at least a screen to each side, or maybe a screen as default and leave it configurable in the editor.

[fracteed]

I also find this annoying, especially in the -x and -y as noted by mateusak. I tend to put a few dummy sprites on far reaches just to free up the navigation space. Haven't noticed this kind of restrictive behaviour in other 2d applications.

[groud]

@eon-s it is already the case :)

[groud]

Maybe we could increase the limits, and center the view when you unzoom, so that the -x and -y are more accessible. But I see definitely no point in making those infinite.
There is no use case in getting lost at (-10000, -10000) coordinates when your game is at (0,0).

But as I said, we could make it an option for those who find it useful.

[fracteed]

@groud this sounds good. An option for the limits being unlocked would be very useful.

[KoBeWi]

I just discovered that point 2. from OP is still relevant, even with the panning improvement. Placing nodes is no longer a problem, but when you edit a tilemap and want to place some faraway tile (for whatever reason), it is currently impossible. You need to make a "path" of tiles to that point.

[Calinou]

Having infinite view is cumbersome for most use cases.

@groud Out of curiosity, what downsides would an infinite 2D view have? The 3D viewport navigation isn't limited, yet I can't think of any downsides that come from it being unlimited.

[groud]

@Calinou imagine you unzoomed a lot on your scene, which happens a lot with TouchPads zoom or free spining mouse wheel. When you want to zoom again you have to put your mouse in the correct spot to be sure you zoom on the interesting (thzt means including content) spot of your scene, and keep it centered at each step of the zoom.
That's quite annoying, as it is rare to need zooming on an area where there is nothing. So basically it avoids people to get lost on areas of the viewport that are not used.

[fracteed]

I agree with @Calinou that panning should work in 2d the same way that it currently works in a 3d orthographic viewport. For the game I am working on, I have 2d games mixed with 3d in the same project. It becomes quite annoying when I jump from working on something in 3d, which has no panning limits to then work on a 2d viewport which has the builtin limits.

Surely if someone was to lose their position in the 2d viewport they can just hit the F hotkey to zoom back to the object they are working on? Or you could bind a hotkey to home that centers the viewport, as is done within Blender. Blender also has no limits in any of its' 2d areas such as uv or node editors and you can pan as far as you want without restriction. If you did happen to get lost then it is just a matter of hitting the home key.

This gives a nice unified feel to Blender, since all of it's various editors have the same navigation feel. This is something I feel that is missing between the 2d and 3d editors in Godot in various aspects (most notably, multi object manipulation). I would also really like to see ctrl-middle mouse as a zoom control work in 2d the same way that it works in 3d. As someone that uses a Wacom tablet almost 100% of the time, this would be very useful.

[groud]

they can just hit the F hotkey to zoom back to the object they are working on.

Honestly that's not really practical for most users. It requires learning a key that's not intuitive.

Honestly I think blender is a really bad example, as navigating on the 2d interfaces is IMHO really unintuitive and annoying. Have instead a look to professional 2d software, like photoshop for example. You cannot zoom in the area outise of the canvas, because it does not make sense and it is not useful.

Also, think again about people working on laptops with touchpads, which is a really common use case that should be taken in consideration. It's not possible on those devices to point the place you want to zoom in and to zoom in at the same time. Infinite 2d workspace would make the user experience considerably worse for those users which is not acceptable.

[fracteed]

I don't think comparing a 2d game engine layout to a 2d image editor is at all a good comparison. When creating a 2d level you generally don't know how large your game area will be (assuming it is an area that will be scrolled in game), and the size of the boundaries will expand as you progressively add to the level . Whereas in an image editor you know your canvas or document size from the outset and there would be little reason to add to the outside of these initial boundaries.

A better comparison is to the other popular 2d game engines. GMS and Unity both allow you to freely pan without restrictions. Construct has the side scroll bars, but these dynamically resize if I remember correctly (has been many years since I touched that).

I also use a trackpad some of the time, and just use either the hotkeys or the +- arrows to zoom in and out with no issue. Also the option to frame up the selected object is right there in the view menu, so the user doesn't have to hit the F key.

The best solution would be to have the limits unlocked as a user defined option as you mentioned in an earlier comment.

[groud]

I don't think comparing a 2d game engine layout to a 2d image editor is at all a good comparison.

Then in that case it does not make sense to compare it to blender too. ^^ On the UV editors, if blender allows you to zoom outside of the texture, it is not useful either.

GMS and Unity both allow you to freely pan without restrictions

Still, comparing to what other game engine do is not an argument. Those engines are far from perfect, and IMHO what we have here is a better UX than what they have.

just use either the hotkeys or the +- arrows to zoom in and out with no issue

Well, you don't have a laptop with an AZERTY keyboard layout where you need to press shift key to push the + key. Not mentioning keyboard navigation is not practical for a lot of people, and are less discoverable. So keyboard shortcuts required to navigate without issue is not an option.

and the size of the boundaries will expand as you progressively add to the level .

That's exactly what the current system allows, if you move something far away by unzooming and moving it, you will be able to scroll that far (+ a viewport width) to modify it.

I am not against a setting for people that need to place elements far away all the time, but I wont be made as the default behavior, as it would impact people working on laptop too much.

So for me, what should be done is:

1. Allow the viewport to scroll to infinity (and beyond ;) ) with an editor setting
2. Make the unzoom center the viewport instead of putting it in the top-left corner, so that it is easy in an unzoomed state to move the nodes far away on the left or top part of the screen.

[fracteed]

Then in that case it does not make sense to compare it to blender too. ^^ On the UV editors, if blender allows you to zoom outside of the texture, it is not useful either.

The only reason I compared it to Blender is that many here only have 3d experience with Blender. The same goes for C4D, Houdini, Maya, Substance etc that also have 2d and 3d editors. The point being that they have unified navigation controls that work in their 2d and 3d editors, and they don't have limits when scrolling in a 2d view, regardless of whether is a uv editor, nodal view or painting view. Godot is the only 2d editor (aside from image editors like Photoshop) that I can recall that has this builtin constraint on panning.

Still, comparing to what other game engine do is not an argument. Those engines are far from perfect, and IMHO what we have here is a better UX than what they have.

Agreed, and that is why I use Godot! However I was only comparing the 2d panning functions in their editors, and not the whole ui. Whilst Godot is awesome, it is also not perfect :)

Not mentioning keyboard navigation is not practical for a lot of people, and are less discoverable. So keyboard shortcuts required to navigate without issue is not an option.

A user can just use the onscreen +- buttons to zoom when on trackpad if they don't want to use hotkeys.

That's exactly what the current system allows, if you move something far away by unzooming and moving it, you will be able to scroll that far (+ a viewport width) to modify it.

And that is why all the users on here are complaining about it, as it is cumbersome.

Allow the viewport to scroll to infinity (and beyond ;) ) with an editor setting
Make the unzoom center the viewport instead of putting it in the top-left corner, so that it is easy in an unzoomed state to move the nodes far away on the left or top part of the screen.

Sounds great, would appreciate if you are able to do this! Would also love to be able to zoom using ctrl-middle_mouse in the 2d editor the same way you can in 3d ortho viewports. Cheers!

[groud]

You must be kidding. A while ago the engine was literally PURPLE. They have UX designers and our UX is made by programmers (notoriously bad in the subject) in their free time. Godot's UX is horrible. It's one of the main points why indies still use Unity.

I obviously meant this on the point discussed here, not on the whole engine. But to be honest, I read far more people being happier making 2D games on the Godot 2D editor than making 2D on Unity. The dedicated rendering engine and pixel units helping a lot. Just citing this for example:
" Unity was already bloated, was slow to load and building 2D games was very hacky."

That's a very specific problem. I get that you don't want it, but clearly what most people want is
infinite scrolling.

Clearly not, this issue is the first issue raised in years on this topic, while most Godot users are still making 2D games with the engine. If this was a very important problem, it would have been raised a long time ago and have a lot more thumbs up.

The most offending issue is not even the finite scrolling, but the asymmetrical zoom in -x/-y. Who tought that was a good idea? It's even harder to implement it like that for god's sake: someone got out of their way to make sure the UX is kept at a certain level of bad.

Honestly, this kind of comments really pisses me off. What do you even know about how much something is hard to implement or not if you did not even have forked Godot on github ?
As explained countless times before, this is a game engine mostly built by volunteers, working for free to implement all of this. For something to be implemented / improved we need to have someone interested in solving the issue, with the time and skills to fix it. There is likely little interest in this issue, so it was not solved yet. If you think you can do this job better than all current contributors, feel free to open a PR and solve the problem.

[KoBeWi]

Okay, I get it. I offended you and all the hard working people here by saying that the UX is awful. However, I don't think pretending is healthy. One thing I see in this community is that once someone says something bad about Godot everyone loses their mind. I said it was bad, and I said what I think should be done. I may have been harsher than necessary but that doesn't discredit my points.

The problem with that comment was not that you criticized, but that you criticized too generally. You said UX is bad. Cool, but why it is bad? What and how it can be improved? Non-productive criticism doesn't lead anywhere either and only makes people angry. If you have specific problems with Godot, create proper issues for them. And don't say that it's pointless due to how the issues just float out there without being fixed. They ARE going to be fixed at some time. You never know when some random contributor will pick your issue. But if it isn't there, it's not going to be fixed. Vaguely "bad UX" won't be fixed either, because everyone has a different view on "bad". For me personally, Godot is better than Unity and any other engine/framework I used in the past. So just be more specific in your feedback.

[groud]

Okay, I get it. I offended you and all the hard working people here by saying that the UX is awful.

Let's make things clear, commenting about the UX state is ok. It's better when it is a constructive comment (as @fracteed comment's is) than just throwing a simple "Godot's UX is horrible", but that's still ok.

But this kind of rant :

You must be kidding
Who tought that was a good idea? It's even harder to implement it like that for god's sake: someone got out of their way to make sure the UX is kept at a certain level of bad.

Is definitely not acceptable.

I won't. You won't. So I guess because of what you think of me, Godot gets nowhere.

Don't worry, I don't choose the thing I am working on depending on who asked for it. ;)
I'll likely implement that when I find the time for it (unless anyone else volunteers to do so).

[groud]

Godot is out there, trying to compete with huge engines like Unity and Unreal, so they have a little bit of everything, but everything is left unfinished.

Well, no, Godot is not even trying to compete with them at all. Godot is a free product, we are not fighting for market share or whatsoever. Unity and Unreal have hundred of paid developers, while we only have two. There's no competition possible here in fact. There's no way we can work on Godot at the same pace as Unity and Unreal developers do, it will never happen. So yeah, a lot of issue will stay unsolved for a long time.

[groud]

Time and time again I've seen contributors ignore suggestions and just do what they want.

Yes, people work freely on whatever they want. There's no point in going against that. Once a contribution is proposed, it is reviewed by a subset of the main contributors, and eventually by whoever attends the IRC merging meetings. We don't merge everything, but PRs considered as an improvement are usually merged.

And what are you going to do? Are you going to stop making your games on the limited time you have to fix the mistakes of a proud developer?

Yeah, that's one of the consequences of choosing Godot. But usually companies choose to instead pay one of the contributors to implement or fix what they really need. If you can't afford that, use Unity or Unreal instead.

And there's no space for discussion to achieve some compromise, because you're the developer and I am not, so in the end your voice is more important.

That's how Godot (and most open source project) work. The more you invest yourself into the project, the more weight in the decision you have.

[RafalLauterbach]

I would like to add that topic #32163 actually contains solution :

" Try unchecking Editors > 2d > Constrain Editor View. This setting was implemented in #30041; read the comments in #25616 to know why this is enabled by default. "

Originally posted by @Calinou in #32163 (comment)

Sorry for waking up that thread, but I just want to help other "me's" who only found that topic, thought that it is just dismissed as an idea and would left without searching more.
I clicked on that mention link only from cursiosity, wasn't expecting to find answer there, as mention doesn't mean answer, and I believe it would be good to point toward answer from every topic that seeks it, so that's why I wrote it. I hope it's fine behaviour.
Oh, and only now I realised it was added to milestone, so I should've searched mode.