search

godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.13k stars 73 forks source link

Invert Y Axis. UP should increase, not decrease #2070

Closed CitrusWire closed 3 years ago

CitrusWire commented 3 years ago

(This is a rephrasing of https://github.com/godotengine/godot-proposals/issues/2048 - it's evident from the responses and why it was closed that I failed to express myself clearly)

This ticket is absolutely NOT about:

These things are utterly irrelevent to the proposal.

To keep things simple, I am mostly only going to talk about the Y axis here.

Describe the project you are working on

n/a

Describe the problem or limitation you are having in your project

Godot has flipped the Y axis so that it is upside down. This is a problem because it's not how most people think of axis, it's inconsistent with how the X axis is treated, and it's not how all other game engines deal with the Y axis (see other ticket ( https://github.com/godotengine/godot-proposals/issues/2048 ) for references proving this).

Or put another way, in Godot you have the following:

Vector2.UP == (0,-1)
Vector2.DOWN == (0,1)

In every other game engine, and in the real world, this is:

Vector2.UP == (0,1)
Vector2.DOWN == (0,-1)

If I say "Start at 5, go UP 3", what number are you now thinking off? Yep, 8. Now, lets try another: "Start at 20, go DOWN 6", what number are you thinking of now? Yep, 14.

That's because UP and DOWN have meaning, and reversing that meaning makes no sense (exception: drawing software also reverse it, but that doesn't mean it makes sense).

This also applies to FORWARD/BACK (Z axis) being reversed. In fact, they do the exact opposite of the Number Line concept you learn at school - https://en.wikipedia.org/wiki/Numberline: image

"Start at 3, go FORWARD 1" what number are you at now? For Godot FORWARD means to -1, so you should get 2. Not even slightly intuitive.

Further, this is inconsistent with the X axis, for which Right (+1) and left (-1), do what you'd expect despite those being more cultural.

This will also serve to make the origin point bottom-left, from the current top-left.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

The ability for the user to specify what whether the Y axis is swapped to "human-normal" or "Godot specific". This could be either a Project setting or an Engine Setting.

I expect this should be invisible to most addons, and irrelevant for tutorials (there are tons of other Project/Editor settings that can invisibly break tutorials but people don't worry about them).

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

As above

If this enhancement will not be used often, can it be worked around with a few lines of script?

Doesn't seem to be any consistent way to switch it around at the script level.

Is there a reason why this should be core and not an add-on in the asset library?

It's an engine thing

YuriSizov commented 3 years ago

In every other game engine

Is this even true? As far as I am aware, in computer graphics screen coordinates start in the top left corner of the screen and therefore increase down and to the right. Godot just follows the same principle.

CitrusWire commented 3 years ago

Is this even true? As far as I am aware, in computer graphics screen coordinates start in the top left corner of the screen and therefore increase down and to the right. Godot just follows the same principle.

Yes. Straight from the other ticket (which I explicitly referenced!):

Below are the random selection I looked up of OS and proprietary engines:

Unity uses bottom-left, so increases Y axis: https://docs.unity3d.com/ScriptReference/Vector3.html

Gamemake studio - as Unity - https://docs.yoyogames.com/source/dadiospice/002_reference/maths/vector%20functions/vectors.html

Unreal also increases the axis: https://docs.unrealengine.com/en-US/BlueprintAPI/Math/Vector/index.html

CryEngine - https://docs.cryengine.com/display/CS/CryEngine.Vector3 - as Unreal

Ogre - Not obvious from the API - https://www.ogre3d.org/docs/api/1.7/class_ogre_1_1_vector3.html#details

Solar2D - No Vector type

Wikipedia also concurs that this is the "standard" orientation for cartesian coordinate systems - https://en.wikipedia.org/wiki/Cartesian_coordinate_system#In_two_dimensions

I know computer graphics software starts top-left, but it's the exception that proves the rule. Almost every other domain I can think of uses bottom-left. Latitude / Longitude, the Compass, the vast majority of graphs...

From that wiki page:

Computer graphics and image processing, however, often use a coordinate system with the y-axis oriented downwards on the computer display. This convention developed in the 1960s (or earlier) from the way that images were originally stored in display buffers.

So it's a historical anacronism from back when computers had memory measured in (kilo?)bytes, and software developer had to care about every bit.

YuriSizov commented 3 years ago

but it's the exception that proves the rule.

It's not the exception. It is how it always is underneath, to the best of my knowledge. The engines you've referenced just invert it for engine users.

Also the Vector3 in Godot uses a positive Y for UP. It's the Vector2 that uses a negative Y for UP, because that maps to how screens work. Keep in mind, that Godot has separate pipelines for 2D and 3D, to better accommodates each perspective's needs, and most of those engines don't.

Calinou commented 3 years ago

Image editors like Photoshop and GIMP use the "Y+ goes down" convention. The same goes for HTML/CSS.

CitrusWire commented 3 years ago

It's not the exception. It is how it always is underneath, to the best of my knowledge. The engines you've referenced just invert it for engine users.

I must humbly disagree; It is an exception from the end-user perspective. Think about it this way, there are countless things that computers do behind the scenes and we translate to human-convention. DNS (212.85.158.4 is how the computer accesses godotengine.org, human minds are feeble and can't readily remember 32bit numbers), counting (it uses binary, not decimal), writing (all done with bytes). Etc etc. The purpose of computers is to make life easier for the user, with the minimal constraints.

Also the Vector3 in Godot uses a positive Y for UP.

You're right! :-o That's insane! :-? That's a terrible inconsistency. (And of for bonus confusion of course the Z axis remains inverted).

Image editors like Photoshop and GIMP use the "Y+ goes down" convention.

Indeed, but Godot isn't an image editor or a web browser, it's a game engine. ;-)

YuriSizov commented 3 years ago

The purpose of computers is to make life easier for the user, with the minimal constraints.

And in this case we are talking about something that is designed by programmers for programmers to make life easier. In 2D it makes all the sense in the world the way Godot does it. And it's not an inconsistency, it's the benefit of having different pipelines for different needs.

3D is used exclusively for game worlds, worlds that resemble our own reality and perspective, but 2D is used for a lot of other things too. This includes games without a realistic perspective on the game world (imagine Solitaire, for example, or Mahjong) as well as menus, UIs, applications. There is no physical "up" in those cases, not unless you're imagining exclusively platformers and such. And so it makes sense to follow how the screen coordinates work for games and applications that are bound to that screen space.

And it also makes sense when working with textures, UVs, other cases of flat imagery.

I think this is what conflicts you. You think in terms of a physical world, but 2D applications are not necessarily bound to it, not like 3D applications are. Imagine you'd propose everyone starts to write from the bottom on a piece of paper because physics of our world dictate to do so. That'd be weird, wouldn't it?

CitrusWire commented 3 years ago

There is no physical "up" in those cases

There is no physical "UP" or "FORWARD" in number systems either, but I can be confident that I can predict your answers for the numbers game.

Imagine you'd propose everyone starts to write from the bottom on a piece of paper because physics of our world dictate to do so.

Indeed, and that's why HTML/CSS starts at the top: it's a document, and it actually makes sense to follow the millennia of custom we've built up for document parsing.

The reason I have raised this proposal is as a result of the countless hours I have lost while creating rasters with imaging libraries and their insistence on top-left origin while I'm trying to draw a graph or something else that uses bottom-left origin. I'm trying to reduce that happening for myself and others here because I know it will result in countless gotchas.

And it also makes sense when working with textures, UVs, other cases of flat imagery.

This I do agree is possibly a benefit of top-left (I've not gained from it yet mind), although given all other game engines use bottom-left, I presume they have tools for it.

but 2D applications are not necessarily bound to it

Again agreed, but 2D is fundamentally a grid, and society has stated that the common default for grids is bottom-left as 0,0; it's also the game engine convention too. So it's what I expect most users will be familiar with and will introduce the least "WTF is going on" moments.

And it's not an inconsistency

If different things are not consistent it's literally the root word for "inconsistent". Sure it's great that Godot can do stuff like that, but I absolutely don't think it should. It's just adding more confusion to the process of switching from 2D to 3D.

YuriSizov commented 3 years ago

I think I've said everything I wanted to say already, but I want to address this:

It's just adding more confusion to the process of switching from 2D to 3D.

Most reasonable 3D systems, at least in my opinion, have Z as UP, not Y, which already breaks that consistency between 2D and 3D axes. Godot, ironically, doesn't do that, but I just want to point out that 2D and 3D do not generally map one to one.

CitrusWire commented 3 years ago

Most reasonable 3D systems, at least in my opinion, have Z as UP, not Y, which already breaks that consistency between 2D and 3D axes.

Yes, but that's a handedness thing which this isn't about. In all cases I'm aware of, none of them swap positives and negatives, let alone seemingly randomly (how it seems to me as a user) between 2D/3D as Godot does.

dsnopek commented 3 years ago

The problem here may be that there isn't a standard, there's many standards. :-)

To point out just one example, the HTML5 Gamepad API specifies that up (described as "forward" in the spec) on a joystick to be -1:

https://www.w3.org/TR/gamepad/#dom-gamepad-axes

It's likely that we could find many examples of applications, engines and even official standards ratified by different standards bodies that have their axes oriented in different contradictory ways.

IMO, the best thing to do here is just pick a way, and then stick with it.

Jummit commented 3 years ago

Is there a reason to change it other than the assumption that it's unintuitive for some users?

CitrusWire commented 3 years ago

To point out just one example, the HTML5 Gamepad API specifies that up (described as "forward" in the spec) on a joystick to be -1

W3C is making me :-( (good point though!)

Is there a reason to change it other than the assumption that it's unintuitive for some users?

Personally I think ease-of-use is a very good reason for changing something unless there are very compelling (usually technical) reasons not to.

Note I suggested adding it as a setting, so it's not being "changed" per-se, merely appended to (though longer term I would suggest changing the default, but that's a different ticket :-) ).

SIsilicon commented 3 years ago

I'm pretty against this move cause all screens define the coordinate origin from the top left, and since we're talking about 2D, it would make it less intuitive than it already is. This is especially true when building a GUI, which most if not all games should have. UI designers work closely with screen space, which again, has its origin defined in the top left.

Bromeon commented 3 years ago

I know computer graphics software starts top-left, but it's the exception that proves the rule. Almost every other domain I can think of uses bottom-left.

Not just screens, but also several 2D graphics libraries use the Y axis down convention, so it's definitely not an "exception":

There are various advantages of this, as it follows the way how the most common scripts on Earth are written, what is considered natural flow in books and UI design, and so on. Maybe the naming of the "UP" constant can be debated, but that the downward direction of Y is unintuitive is your assumption, not a fact.

aaronfranke commented 3 years ago

and in the real world

The real world does not have axes.

In fact, they do the exact opposite of the Number Line concept you learn at school

This number line does not point up or down.

it's inconsistent with how the X axis is treated

It's not though. X being to the right does not imply anything about the Y axis.

and it's not how all other game engines deal with the Y axis

In every other game engine

Several of the engines you listed (Unity, Unreal, CryEngine) are 3D engines. They may have 2D modes, but they are still 3D engines because they're 2D in 3D. Godot is fairly unique in that it has a dedicated 2D mode in addition to its 3D.

Shadowblitz16 commented 3 years ago

I agree y axis should face down. This is due to the fact that godot uses a 2d system where y axis is down

This makes converting between vector2 and vector3 difficult with rotation as its not as simple as just inverting the y axis of the vector

Calinou commented 3 years ago

Closing due to lack of support – see reactions on OP.

peabnuts123 commented 2 months ago

I know this will probably never change, but I just wanted to add that Y is usually down in screen space, but usually up in world space. I don't know why nobody has mentioned this in this thread. Everybody seems to be arguing (on both sides) that there is a "one true convention" which is obviously nonsense. Many people (such as OP) think of their game "world" in world space, not screen space. UI may also be thought of as World or Screen space by different people (can also depend how "diegetic" your UI is). Ideally Godot would offer a setting to switch between the two, based on how your brain thinks about your game's virtual environment.

I will also say that I personally also prefer to think in World space even when working in 2D. In my experience, computer graphics usually always has many concurrent abstractions on-the-go at the same time anyway i.e. world coordinates -> camera coordinates -> screen coordinates -> device coordinates, etc. It's really nonsense to say "all games should be written using world coordinates" or "all games should be written using screen coordinates".

Shadowblitz16 commented 2 months ago

@Calinou you should reopen this there are more likes then dislikes now.

I would honestly rather see y being inverted in 2d rather then 3d, as much as I'm used to 2d y increasing down. I would also rather origin in 2d be center to be consistent with 3d but that's call for another issue to be made.

aaronfranke commented 2 months ago

@peabnuts123 The argument isn't that there is a "one true convention". The argument is that both are extremely common and it is not worth it for Godot to switch.

CitrusWire commented 2 months ago

The argument isn't that there is a "one true convention". The argument is that both are extremely common and it is not worth it for Godot to switch.

Surely the correct conclusion if both are "extremely common" (as they are), is that there should be an option so that the Godot user can specify whichever they're most comfortable with, as @peabnuts123 suggested, and as I suggested in the original suggestion.

Godot already has hundreds of options, the majority of which are trivial/irrelevant to 95%+ of users (albeit a different 95% per setting). By comparison, it's clear this evokes strong opinions because it's important to a lot of users.

Without this change/setting, users have who have an alternative preference need to re-learn concepts as basic as forward/backward and up/down. In some cases we're unlearning literally decades of experience with other axis orders, certainly I am. This is needlessly adding to the already significant mental overhead of game development.

Main features of godot are things like "intuitive scene driven design"; "Coding tools that fit your needs", "Master usability with a flexible GUI system". It seems reasonable to expect this flexibility and intuitiveness should extend to something as fundamental as world-coordinates.

I concur that @Calinou should reopen this; the stated reason for closing is no longer invalid. I presume this is because the people who closely monitor github (regular users) and so vote first, have all become used to this mechanism, whereas the long tail of new users is filled with people who find it baffling.

aaronfranke commented 2 months ago

is that there should be an option so that the Godot user can specify whichever they're most comfortable with

This will never ever happen, ever. Godot has one coordinate system (well, one for 2D and one for 3D) by design. Adding a setting for making +Y up in 2D is a monumental task with tons of downsides and miniscule rewards.

Please consider that even if the engine had this feature, it would be a major pain for everyone, fragmenting the community because GDScript files from a +Y-up project won't be compatible with a +Y-down project, significantly increasing friction when reusing content between projects, or when sharing code with your friends, etc. There is no way to avoid this problem, not even with the world's best programmers. The only solution is to get rid of the dual coordinate system and revert back to only having one coordinate system.

CitrusWire commented 2 months ago

with tons of downsides and miniscule rewards.

This thread has already shown that the rewards are not "miniscule": forcing people to ignore decades of experience which have built into innate abilities and skills, and re-learn something as basic as forward and backward is a significant overhead/expense. There are indeed various reasons this proposal is problematic; downplaying the advantages is not necessary.

Please consider that even if the engine had this feature, it would be a major pain for everyone, fragmenting the community because GDScript files from a +Y-up project won't be compatible with a +Y-down project, significantly increasing friction when reusing content between projects, or when sharing code with your friends, etc.

While there would be some issues, I'd like to highlight that this is already a "solved" problem in the domain of GIS. Every set of spatial data comes with a definition stating which coordinate system it is using, this is one of thousands of possible coordinate systems, not just two. The GIS software handles this all invisibly to present one uniform view of the world to the user no matter how disparate the coordinate systems are (well, there are some systems that aren't compatible).

akien-mga commented 2 months ago

I appreciate the interest and I understand the need that some users may have for a 2D coordinate system that feels more natural to them, or greater consistency between 2D and 3D coordinate systems.

But as several people clearly pointed out above:

In short, Godot has chosen its 2D and 3D coordinate systems when it was created and these won't be changed. All engines and graphics tools have made their own choices, which may differ for various historical reasons, good or bad. There's no one true coordinate system. There's just conventions within each tool, and when these conventions are kept stable, it makes it possible to convert from one tool to the other, and to communicate with a shared language.

I acknowledge the original reason for closing this proposal wasn't explicit enough, so I understand why it was brought up again. To clarify, the problem is not one of user support/demand, but that maintainers rejected that proposal for the aforementioned reasons.

So I'm closing and locking this already rejected proposal as it's not up for discussion anymore. Please don't attempt to reopen new proposals on this topic as the decision has been made.