godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
87.04k stars 19.54k forks source link

Vector3.zero/up/down/etc like in Unity #7317

Closed hatem-u closed 5 years ago

hatem-u commented 7 years ago

Shorthand for writing Vector3(0, 0, 0).

Calinou commented 7 years ago

Have you tried Vector3()? That should work.

williamd1k0 commented 7 years ago

I think it might be useful to have some shorthands for Vector2 and Vector3: eg:

Vector2.up # Vector2(0, -1)
Vector2.right # Vector2(1, 0)

source: https://docs.unity3d.com/ScriptReference/Vector2.html https://docs.unity3d.com/ScriptReference/Vector3.html

reduz commented 7 years ago

i think the code is more readable if such things don't exist

On Fri, Dec 16, 2016 at 10:31 PM, William Tumeo notifications@github.com wrote:

I think it might be useful to have some shorthands for Vector2 and Vector3: eg:

Vector2.up # Vector2(0, -1)Vector2.right # Vector2(1, 0)

source: https://docs.unity3d.com/ScriptReference/Vector2.html https://docs.unity3d.com/ScriptReference/Vector3.html

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/7317#issuecomment-267733965, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z28NvIswnUhid0wbDqiuT1NRRdYZ0ks5rIztogaJpZM4LPt1j .

Zylann commented 7 years ago

The main usage I would see for some of these constants is that they are making conventions explicit. In 2D, up is actually Vector2(0,-1), while in 3D it's Vector3(0, 1, 0). Also, forward in 3D is Vector3(0,0,-1) due to OpenGL convention, unlike what most people think. In that way, they provide code self-documentation.

I don't see an usage for Vector3.zero or Vector3.one though, writing Vector3() or Vector3(1,1,1) is simple enough to understand.

LeonardMeagher2 commented 7 years ago

You could always create a helper singleton for yourself, it's obviously not going to be as straight forward, but something like

extends Node
const up = Vector2(0,-1)

use it as a singleton called v2 then do v2.up add all the things you want to v2, maybe even functions you find helpful for yourself. same for Vector3 using something like v3 maybe.

It's not a solve all, but it'll help you if you really need it, you might also find out how much you don't really need it.

akien-mga commented 7 years ago

The main usage I would see for some of these constants is that they are making conventions explicit. In 2D, up is actually Vector2(0,-1), while in 3D it's Vector3(0, 1, 0). Also, forward in 3D is Vector3(0,0,-1) due to OpenGL convention, unlike what most people think. In that way, they provide code self-documentation.

Yes and no. They are not making conventions explicit as they are obfuscating those conventions. When you read var vec = Vector2().up you don't know that it actually points towards the negative Y axis. So you need to actually do some real math later on, you no longer have that useful reminder that "hey up is negative Y, right, so if I want to go up-right I need to give an impulse of (40, -120)".

LikeLakers2 commented 6 years ago

Akien, I don't believe there would be a risk of forgetting such a thing. Even if you do, often it is a simple google search away, is it not? (Also, it should be Vector2.up, not Vector2().up!)

Reduz, assuming you're saying that the shorthand should not exist, I would like to say that the shorthand will prevent Vector2(1, 0), Vector2(-1, 0), Vector2(0, 1), and Vector2(0, -1) from being typed and retyped in every Godot tutorial I've seen. It's short, sure, but it's also been typed enough that I believe a constant would be warrented anyways. Also, the names of the constants are a bit more descriptive than two integers.


I support the idea.

hubbyist commented 6 years ago

Shorthand for simple math is limiting I think. Different projects may have different preferences for directions.

So For a 3D first person shooter

    extends Node
    const up = Vector3(0,0,1)

For a 3D top down space shooter

    extends Node
    const up = Vector3(0,1,0)

can be both valid use cases.

    extends Node
    const north = Vector3(0,1,0)
    const south = Vector3(0,-1,0)
Zylann commented 6 years ago

@hubbyist technically, your 3D FPS example is impractical because up isn't Vector3(0,0,1), it's (0,1,0). You can certainly use this convention, nothing is against it... but the UX in editor won't be optimal because not though this way, I can tell you^^ But I get your point for sure

mysticfall commented 6 years ago

I also support this idea. Even if some projects can use different coordinate convention than the default one, it wouldn't change anything for them as we don't really forcing anyone to use such shortcuts.

But for the majority of other projects, it would surely make the code more intuitive and coincise. It can also prevent mistakes and eliminate confusions regarding the coordinate system, especially if you are using an IDE which allows showing a declaration of such constants by clicking them.

If some people use a different coordinate system, they can define their own constants or constructing vectors everytime as they've always done, and simply regard Vector3.Up as denoting the global coordinate system used by the editor.

(By the way, I think we could remove gdscript label from this issue now, since it also affects C# as well.)

aaronfranke commented 6 years ago

The C# code already has this. I added it in https://github.com/godotengine/godot/pull/17134

But this still needs to be added to GDScript. So yes, the "topic:gdscript" label is appropriate.

Zylann commented 6 years ago

I found one additional reason why those shorthands are useful is, their value is tedious to write. Just look at the gesture you do when typing Vector3(0, 1, 0), compared to Vector3.UP :D

KoBeWi commented 5 years ago

The C# code already has this.

GDscript seems to have those too (at least in 3.1), so issue can be closed.

Calinou commented 5 years ago

This was implemented in https://github.com/godotengine/godot/commit/ba974b8d1e245818d819791bd628e70ec3b92de3, closing.