Why is Z up in some software and Y in others?

no reason

IDFK

>>538461
How do you know it they are "up"?

Think I actually have an answer to this.

X and Y are based on the first, initial 2D plane that you design from. In technical drawing and CAD, the front and side planes of an object ten to be the most important (or at least the first planes we plan from, cause they're the ones we're used to seeing the most on objects irl), which means that in these fields your front plane would contain X and Y (like on a math graph), and only when you rotate your view 90 degrees would you add the notion of depth, Z.

Meanwhile, in architecture, since plans are drawn top-down, the X and Y axis are represented on a horizontal plane. When you raise the walls, you get Z.

Historically certain 3D programs were created with architecture in mind, others with technical design. That's the basic explanation why some have Z and Y inverted. Since a convention was never established for this, you see most programs use the same coordinates to this day (along with all the annoying flipping issues it brings).

I honestly think it's a retarded problem and I'm not too sure why software devs can't agree on a convention (maybe continuity issues within the same software? idk), but I'm hoping over the years we're gonna see a trend solidify with new software releases, because there's honestly no reason why coordinates shouldn't be standardized.

No real reason, just someone decided one day that it's that way. Same reason you have to invert rgb channels for normal maps in soms engines.

>>538478
Physics sim uses it for gravity, camera rotates around it, Various functions refer to it as up.
Probably many more reasons.

It depends on if the guy coding the system had an actual math background or if he was just a faggot who had only done work on graphics.

this is what's going on with that >>538653. The details may be debated but that is essentially it. A standard should have been agreed upon many years ago, it's becoming more and more of a clusterfuck for every new 3D environment released.

I no longer care what axis convention is used, fuck make it X-up, just make it the same across the board.

>>538724
It's all about what view is seen as the principle plane. if you think of top view (like a map from above), world Z becomes up towards you according to mathematical convention. If you think of front view as principle Y becomes up in mathematical convention.

It has nothing to do with being a homosexual or artist.

i think its local/global but i could be wrong

Well it only matters if you don't know which is which. What is even up in a figure? As long as you know the reference frame it shouldn't be a problem.

>>538717
This. Fuck those cunts so much!!

>>538461
Software developer choice. Not super important.

>>538653
Technically a convention exists, which is to use semantic labels on axes (forward, left, right, up instead of xyz) but then you run into the problem of whether you're using left-handed or right-handed coordinates. Ultimately, just like no one can agree on standards for text or date encoding, any attempt to standardize is futile and essentially counterproductive, these things should simply be annotated in the file format and then you just need an extra matrix multiplication in your export process to accommodate any frame of coordinate.

>>538835
this is why we need a wwiii for graphics

>>538653

I'm in chemical engineering, and it's just a matter of choice. Define the coordinates you want to use for a given problem and roll with them all the way through. Sometimes we do 2D stuff in a x,z-plane for no goddamn reason at all.

If you look at graph paper on a desk z is up. If you look at a graph on a white board y is up.

>>538653
> I'm not too sure why software devs can't agree on a convention (maybe continuity issues within the same software? idk)
It's not necessarily even consistent within a particular software package. E.g. 3DS Max was notorious for using different coordinate systems for different subsystems (they may have fixed it by now; I haven't touched it in over a decade).

But >>538724 has a point. If Z isn't up, it's because someone was too focused on the screen, treating 3D purely as "graphics", just like 2D but with an extra axis bolted on.

For physics, and for modelling environments (rather than objects), you have a horizontal plane and a vertical axis. That much is a law of nature, not a human construct.

And if the horizontal plane is X-Z, then either the developer got too far in before they started actually thinking about anything, or (if the horizontal plane being X-Z was intentional) they need their head examined.

>>539794
>For physics, and for modelling environments (rather than objects), you have a horizontal plane and a vertical axis. That much is a law of nature, not a human construct.
Nah, there's no concept of a vertical axis in nature, that's a human construct made to deal with gravity and for example the first problem you'll have when writing a planetary engine is get rid of the notion that "up" is even a fixed thing.

And even if that were true that still doesn't tell us which axis should be which. That's why 3D graphics API don't tie the notion of up to a given axis, instead it's always dependent on user-supplied info even for small scale scenes. This ties into the whole frame of reference concept in both math and physics, which don't actually assume up to be any specific axis despite what that other faggot said.

And this is why sensible exporters and importers simply will provide the necessary semantic info, ie what at least two axes of your frame of reference (usually up and forward) are meant be, so a program can map that to its own frame or reference.

>>538461
i doesnt matter really

you can rename them to u v w if you want

Sky's blue, water's wet, axes are oriented different in different programs.

Is XY top down, or front?
So is Z depth or height?
Its not a more complex question.

>>538461
The better way to phrase this is why some programs stick the -Z on there.

>>539932
it actually is. For example in some APIs XY is front but lesser Y is higher. And then there's the whole business with left-handed vs right-handed coordinate systems.