Why is Bevy's Coordinate System Right-Handed Y-Up?

[cart]

Why is Bevy's coordinate system right-handed y-up?

[cart]

This can be broken up into two questions, but the optimal solve requires considering both:

• Why is Bevy right handed?
• Why is Bevy y-up?

This really only comes down to these choices (from the perspective of our current right handed coordinate system):

1. Do what is natural for right handed 2D / 2.5D and make Y-Up the global assumption across 2D and 3D, at the cost of making 3D slightly weird by making -Z "forward" semantically. This is a hidden implementation detail for most people.
2. Do what is maximally natural for right handed 3D and make Z-up the global assumption, at the cost of making 2D very very weird (2D gamedevs think in z-levels for depth, not y-levels. Y is always the vertical axis, not Z)
3. Fracture Up, Down, Forward, and Back concepts in Bevy into UP_2D (Y) and UP_3D (Z). These would no longer be universal in Bevy. This increases our weirdness budget/api surface and makes documenting/answering questions hard ("User: what is up in Bevy?", followed by "Helpful Bevian: Thats a complicated question ... [dumps a bunch of info]"). It also puts 2.5D / platformer style games in an awkward position. Would those devs pick UP_3D because they have 3D models? Or would they pick UP_2D because they want to use the conventions natural to their genre?
4. Switch handedness, which breaks compatibility with math conventions and most of the ecosystem that we care about (ex: all 3D modeling programs, godot)

IMO (1) is the optimal solve (the current approach) by a wide margin

Unity and unreal dodged this problem by doing (4). But they created way more painful "ecosystem compatibility" problems as a result.

Freya's "gamedev ecosystem coordinate system" chart helps illustrate why right-handed is the right call from an ecosystem perspective:

[thmxv]

This does not make much sense.

Pretty much every math book ever written use:

• X axis going left to right
• Y axis going near to far
• Z axis going up
• Right hand rule

Using this would make perfect sense for 3D and for 2D. In 2D, the viewing direction (eyes to page) is the top down direction (-Z)

It also would be a better compatibility with the ecosystem:

• All math books use that
• All engineering/CAD software use that
• All architecture software use that

Also this explanation of "why use unnatural conventions" as "because it is natural" does not hold much.

The only way this "Y up" is natural is if you are confused by "bottom of the page" (near) and "top of the page" (far) and think this means "bottom" and "top". Or if you read your math books in bed (holding the book vertically not horizontally).

Anyway great engine none the less. And rust: great language even if if uses "Vec" as a type for an array which have nothing to do with linear algebra.

Unrelated but in the same vibe: What is wrong with the hardware (IEEE 754) where 1.0/0.0 == Inf and 1.0/-0.0 == -Inf where obviously both should be NaN?

[rlidwka]

I feel the need to answer this, since working with coordinate systems was the second most annoying thing in Bevy I encountered last project (the most annoying by far was delayed transform propagation).

I actually had 4 different coordinate systems in one project. Bevy as game engine, blender as asset editor (from which I can't simply copy displayed XYZ coordinates to bevy). And then, since it was a robotics project, there're two standards, NED and ENU, because americans can't possibly agree with europeans on anything related to standards, and I had to use both to interop with different things.

The most natural system (for me at least, but hopefully many agree) is: X forward, Y right, Z up. Is that what Unreal does? If so, I can very much respect them picking usability choice over legacy support.

X forward, Y right, Z up is great, very intuitive, with a small downside. It's left handed. Is it actually a downside? What does chirality change actually? You need to flip cross-products (including normals), and that's about it.

If you don't want to do that, maybe consider compatibility with 3d modeling tools. X forward, Y left, Z up (or Y forward, X right, Z up) is going to be at least compatible with Blender, which has XY as ground plane. It is a bit annoying in yaw/pitch/roll calculations, but at least it removes coordinate transforms from blender imports (that's probably the most widely used 3d editor nowadays).

I seriously can't understand Y being vertical. For 3D it is natural to have XY as ground plane. For 2D it is natural to have XY as screen plane. Only difference here is camera rotation: for 2D it looks towards -Z, and for 3D first-person shooter it would look towards X.

And finally, the coordinate system I'm considering to use nowadays is: X forward, Y right, Z down. This corresponds to a standard in robotics called NED (North-East-Down). It is right handed, it has natural XY. Z is inverted to preserve chirality, but that's easy to get used to.

[rlidwka]

At the end of the day, everything you render must be transformed into window space, where X is right and Y is up. No exceptions.

Y is down in win32, as well as in css. But this might depend on each particular device and driver.

What do you gain by fighting it?

More intuitive coordinate system to work with 3d.

What do you gain by not fighting it? A few CPU instructions in best case?

As for negative Z being forward, I find it helps to, instead of holding on to the concept of "deepness", think in terms of "foregroundness": something with a higher Z is in the foreground relative to something with a lower Z

I work with 3D objects. 3D objects have forward, lateral, vertical directions. 3D objects do not have "deepness", "foregroundness", or any of the sort.

I'm okay with viewport having XY coordinate system, because viewport is inherently 2-dimensional. In fact, you can't have it in any other way, really. But why do you force this concept onto 3D?

For a PDP-7 in 1965, which shipped with only four kibiwords of memory

I'm not sure where you copy-pasted this from, but "kibiword" is not a thing, the unit is spelled kiloword.

[SolraBizna]

Y is down in win32, as well as in css. But this might depend on each particular device and driver.

Y was down in nearly every 2D-only graphics system. That's still on the up/down axis. [Edit: If I'm being honest, disagreements between Y-down and Y-up cause me a lot more trouble than disagreements between Y-up and Z-up when handedness is the same.]

I'm okay with viewport having XY coordinate system, because viewport is inherently 2-dimensional. In fact, you can't have it in any other way, really. But why do you force this concept onto 3D?

Because I'm projecting this 3D scene onto a 2D surface.

I'm not sure where you copy-pasted this from, but "kibiword" is not a thing, the unit is spelled kiloword.

"kibi" is the SI [edit: IEC] binary prefix for 1024, analogous to "kilo", the SI prefix for 1000.

[Barugon]

For 2D, I personally think of a traditional cell animation setup, where the camera is looking down onto the sheets.

[rlidwka]

Because I'm projecting this 3D scene onto a 2D surface.

You can project something onto XY plane or XZ plane, math works out the same. That's inner details of the renderer anyway.

Why should I as a user care about this detail if I'm describing 3d world?

"kibi" is the SI binary prefix for 1024, analogous to "kilo", the SI prefix for 1000.

Neither "byte", and especially not "word" are SI/SI-derived units, so SI standards are not applicable here.

Going on a tangent here: Computer science does not use SI prefixes. Current recommendation, as far as I remember, is to use "kilobyte" as a unit of storage capacity, which is shorthanded as "KB" or occasionally "KiB" for clarity, and always means 2^10 bytes. I can provide citations, but I'm afraid it has nothing to do with Bevy really. Edit: I vaguely remember "decimal kilobyte" being a unit, but it is rarely used, so doesn't have a shorthand.

[SolraBizna]

You can project something onto XY plane or XZ plane, math works out the same. That's inner details of the renderer anyway.

I think I have been unclear. When I say I'm projecting something onto a 2D plane, I'm talking specifically about the rendering step; the only part of a 3D rendering pipeline that is not optional.

If you are in a situation where Z-up makes more sense or is more convenient to you, go right ahead and use Z-up—if you're starting from a Y-up frame, that's just one view rotation away. What bothers me is when an engine (or modelling program) forces Z-up, because then it forces having two definitions for up instead of one—in cases where Y-up is more convenient, this leads to two rotations instead of zero. There's no significant efficiency cost either way, but it adds a layer to the math, which makes it easier to make mistakes. (Such as with Minecraft, which routinely and to my great displeasure switches handedness randomly during rendering.)

Anyway.

If we want to be really classy, we could be like POV-ray, and make the user specify right, up, and forward vectors, permitting any handedness and axis definition the user finds convenient. Just as long as we don't be like POV-ray in making left-handedness the default.

---

Further discussion of units and prefixes in SI vs. IEC prefixes and bytes, where it is less off-topic.