unify scenes axis-up about gltf HOT 19 CLOSED

@fabrobinet any update here?

from gltf.

no but I am sure I will need it in the coming 2 months, it is a converter thing.
For these stuff we can use a milestone like converter v1.0 ok ?

from gltf.

For these stuff we can use a milestone like converter v1.0 ok ?

OK

from gltf.

Could I have the 'Y_UP' or 'Z_UP' info somewhere in the glTF for now? I need this as I import several models from various sources and they are not properly axis aligned without that information.

In fact, let's add this to the spec, as an extra, so that give us plenty of time to change the converter.

from gltf.

@fl4re the plan is that y is always up just like angles are always degrees, units are always meters, etc. So it is the job of the converter to ensure this. This is a converter feature I also need. If @fabrobinet can't get to it soon, perhaps he could provide some implementation advice if you are interested in implementing it.

from gltf.

Specifying/standardizing only the up direction is lacking and partial, since it does not fully conceptually define a basis. It is of course the first and most immediate thing that one can see being wrong, when imported models come in sideways in the scene. But there is still room for subtler issues coming from the ambiguity from the two remaining axes. If the up axis is fixed/defined, then also the forward and right axes should be mentioned for completeness.

I'd favor the approach where the file would store vector directions for up_direction, front_direction and right_direction (or handedness) instead of assuming a hardcoded one. If desirable, offer a canonical recommended one for authoring.

from gltf.

If the up axis is fixed/defined, then also the forward and right axes should be mentioned for completeness.

Although this doesn't matter for some models, this would also be useful for me. @fabrobinet?

from gltf.

Since that would be always the same directions for all asset this should be detailed in the specification not the asset. Otherwise it would convey the idea that it may change per asset and would confuse adopters. This said, as a debug option, we could have an extra restating this in the file, but I would object that it is a property (that would always be the same) in the json.

from gltf.

Yes, the 'up-axis' in COLLADA defines all the other axis - in the spec.
glTF is only 'Y_UP' as per the COLLADA spec.
glTF spec should be updated
Converter should be updated to convert the model to the right axis system.
This can be done easily by adding a transform matrix at the root of the
scene.

Having information in glTF that there was a transform applied from the
original document could be useful, if the application has external data it
want to use with the glTF model.
On the other hand, having a convention in the spec/document, that the scene
always contains a root transform (that can be unit matrix), would be
enough, as the user can take in account that transform

Regards
-- remi

On Thu, Apr 3, 2014 at 8:13 AM, Fabrice Robinet [email protected]:

Since that would be always the same directions for all asset this should
be detailed in the specification not the asset. Otherwise it would convey
the idea that it may change per asset and would confuse adopters. This
said, as a debug option, we could have an extra restating this in the file,
but I would object that it is a property (that would always be the same) in
the json.

Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-39463321
.

from gltf.

@fl4re adding a transform matrix at the root of the scene is an easy solution that works well for just one scene.. but more complex scenarios like merging scenes together won't work well that way. And remember the scene doesn't have a root node, so we would have to create one artificially just for that (which was exactly what you didn't want when you asked to remove the root node some time ago).

from gltf.

only fools don't change their minds :-)

Anyways, whatever the solution you have in mind is fine by me, as long as
we have a way to have all those models in the same coordinate system.
What are you proposing?

I'm not sure I understand why it would not work (adding a root transform
matrix) would not work in all case. Do you have a specific example in mind?

On Thu, Apr 3, 2014 at 11:27 AM, Fabrice Robinet
[email protected]:

@fl4re https://github.com/fl4re adding a transform matrix at the root
of the scene is an easy solution that works well for just one scene.. but
more complex scenarios like merging scenes together won't work well that
way. And remember the scene doesn't have a root node, so we would have to
create one artificially just for that (which was exactly what you didn't
want when you asked to remove the root node some time ago).

Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-39487064
.

from gltf.

@fabrobinet any update here? How hard is this now given the recent converter architecture improvements you made?

from gltf.

The reason I don't really like the approach of simply adding a node (even though I like the simplicity) is because one of the major benefit of unifying axis up is the ability the merge scenes together.
For clients who wants to insert nodes from different scenes, having to worry potentially about an extra node sounds a bit awkward to me. I am fine with this quick solution for now if it proves to work well , but I don't think it will scale well and we'll need to follow up with a more involved solution to really keep the exact same node hierarchy but changing the axis.

from gltf.

@pjcozzi the answer to you question depends on the solution, I believe adding the root node should be easy, and using asset modifiers in the converter for my preferred solution will be more complex but still doable with the current architecture.

from gltf.

agreed with @juj to be more explicit, but I believe this impact just the spec, not content of the glTF file.

from gltf.

keeping this around for specification purpose only (see points just above).

from gltf.

@tparisi for the draft 1.0 spec, add:

The model's up axis is the y axis.

from gltf.

OK; I think I should put in a whole section on coordinate system etc.

from gltf.

Sure, whatever you think.

from gltf.