Gltf-blender-io: Remove option for Z=Up export?

Created on 19 Dec 2017  路  8Comments  路  Source: KhronosGroup/glTF-Blender-IO

A recent PR (KhronosGroup/glTF-Blender-Exporter#130) contributed this, I just wanted to check that this should be supported? In other words, should we have options that are technically invalid according to the spec, and/or should it be named something other than Convert Z up to Y up?

exporter question

Most helpful comment

Marking as "task" rather than "external bug;" the issue is relevant to this tool.

I could imagine there are reasons to keep the option around (the addition of a root transform node might be unwanted, for example, when an author could rotate the model and freeze transformations) but at minimum we should probably move the option to only be visible when experimental/developer features are enabled in the addon settings... presenting this option may lead users to assume this is valid in glTF, and to complain when viewers show their model sideways and don't offer Z=up options, which in the end would create a less consistent convention.

All 8 comments

in past discussions of the three.js Blender exporter, this option was removed: https://github.com/mrdoob/three.js/issues/11803

I agree this should not be part of the exporter, it produces invalid gltf files.
If switching axes is needed it should be the client importer's responsibility

@UX3D-nopper I think maybe you've closed this assuming I was suggesting that we add the option, which now exists. I am actually suggesting that we remove the option, as it produces invalid glTF files and may cause loaders to expect this.

If we choose to remove the option it would be good to investigate https://github.com/KhronosGroup/glTF-Blender-Exporter/issues/154 first, although I'm guessing that is not an exporter problem at all.

Marking as "task" rather than "external bug;" the issue is relevant to this tool.

I could imagine there are reasons to keep the option around (the addition of a root transform node might be unwanted, for example, when an author could rotate the model and freeze transformations) but at minimum we should probably move the option to only be visible when experimental/developer features are enabled in the addon settings... presenting this option may lead users to assume this is valid in glTF, and to complain when viewers show their model sideways and don't offer Z=up options, which in the end would create a less consistent convention.

we should probably move the option to only be visible when experimental/developer features are enabled in the addon settings...

Yes, please leave this option around. It's fine that by default Blender's Z-up is transformed to Y-up when exporting to GLTF, but not every model has a natural up direction and you sometimes want to directly export X,Y,Z vertex coordinates without any transformation happening on them. Or actually, it would be best if Blender added general coordinate transforms options (including no transformation) to all exporters, but that's not something that's going to happen soon I think.

By the way, I don't understand the notion that the option being discussed here can produce "invalid GLTF files". Yes, the GLTF spec "defines +Y as up", but you can only judge if a model is correctly oriented when you know the actual purpose and usage of that model, no 3D specification can dictate what is the natural up direction. Example: suppose you're modeling the Space Shuttle, including it's fuel tank and booster rockets. When the purpose of the model is to show the launch pad "up" for the SS might very well mean "it's nose pointed in +Y direction" in the GLTF model, while a 3D scene of it landing on a runway then up might be with the cargo doors upwards. Plus, in many situations there is no natural "up" direction or it is merely defined by the camera orientation used, e.g. the same space shuttle model flying around Earth or an abstract scientific simulation of 3D blood cells.

In general, I agree that there are types of 3D data that lack a natural "up", and that there's no guarantee that the user has correctly oriented their content within Blender to start with.

In the case of aerospace models like the Shuttle, I work on desktop software (STK) that has well-established conventions for how such models are oriented (long story short it's "runway" configuration, and it gets pitched up to 90 deg when sitting on a launch pad, with the "forward" vector facing the sky at the start of launch. This works even for non-Shuttle rockets, as once they start moving in space it quickly becomes clear that the nose is "forward" not "up"). But I get your point, if you were making a Shuttle with the full stack sitting on the launch pad for Sketchfab or something like that, you wouldn't be following the STK convention, and instead would have the nose pointed at the up vector.

Ultimately I'm OK with leaving this in as long as there are some users who want it. I don't see the glTF ecosystem becoming polluted by models that confuse which way is up. I do, however, see lots of models where the forward vector is confused, but I don't think this option itself is responsible. Blender is nearly ambiguous if you're not paying attention to the orthographic view names. The default Blender light source is behind the default cube when viewed from "front", and your default view is the port (left) side of the cube, which blender calls a "right" view. So I have to agree that keeping or removing this option doesn't make the orientation any more or less enforceable or consistent. Generally it's up to users to make sure their models are aligned as best they can.

Well, can this ticket be closed?

Ultimately I'm OK with leaving this in as long as there are some users who want it. I don't see the glTF ecosystem becoming polluted by models that confuse which way is up.

Sounds good to me.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

scurest picture scurest  路  4Comments

UX3D-nopper picture UX3D-nopper  路  3Comments

Quinten123 picture Quinten123  路  4Comments

rainclaws picture rainclaws  路  3Comments

donmccurdy picture donmccurdy  路  5Comments