Options to convert up axis#68
Conversation
| |`--checkTransparency`|Do a more exhaustive check for texture transparency by looking at the alpha channel of each pixel. By default textures are considered to be opaque.|No, default `false`| | ||
| |`--secure`|Prevent the converter from reading image or mtl files outside of the input obj directory.|No, default `false`| | ||
| |`--inputUpAxis`|Up axis of the obj. Choices are 'X', 'Y', and 'Z'.|No, default `Y`| | ||
| |`--outputUpAxis`|Up axis of the converted glTF. Choices are 'X', 'Y', and 'Z'.|No, default `Y`| |
There was a problem hiding this comment.
Doesn't the glTF spec mandate Y up?
There was a problem hiding this comment.
Yeah...
We also go against the spec in 3d-tiles by allowing z-up gltfs. Personally I don't see too much harm.
There was a problem hiding this comment.
That makes sense I guess, thanks.
likangning93
left a comment
There was a problem hiding this comment.
Setting Z-up for input seems to work like a charm for a couple models I have. Also, using a matrix multiply instead of fiddling with swizzling doesn't seem to lead to a noticeable performance hit, even on 1 million+ vertices. Awesome!
Just some speculation on testing, but I don't think I see anything that needs to be addressed in another code change.
| expect(rotatedNormal).toEqual(normal); | ||
| } else { | ||
| expect(rotatedPosition).not.toEqual(position); | ||
| expect(rotatedNormal).not.toEqual(normal); |
There was a problem hiding this comment.
I guess it's not a big deal since we're using Cesium's up-axis conversion, which I assume is relatively well tested, but should we try to come up with more definitive tests for this? It could be a huge pain though.
There was a problem hiding this comment.
Actually these types of tests are missing from Cesium too... I think they do belong there instead of here.
|
@lilleyse can we do a release today so we have this and the ambient fix published. Thanks. |
|
Published. |
Fixes #63
@likangning93 can you review and test?