Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add implementation note for negative transform determinant #985

Merged
merged 2 commits into from
May 31, 2017

Conversation

bghgary
Copy link
Contributor

@bghgary bghgary commented May 30, 2017

As requested in #971 (comment)

@bghgary bghgary requested review from pjcozzi and lexaknyazev May 30, 2017 23:34
@lexaknyazev
Copy link
Member

What if animated scale goes from positive to negative value? Matrix transform could have (near) zero determinant in a frame or two. In that case, Babylon's approach (z-fighting) may be more preferable than Unity's (black geometry).

@pjcozzi
Copy link
Member

pjcozzi commented May 31, 2017

Babylon's approach (z-fighting) may be more preferable than Unity's (black geometry).

Seems like a hard thing to get engines to agree on. I wonder how much of this engine behavior is by accident; I don't know if we should copy it. Perhaps leave unspecified. 😨

@lexaknyazev
Copy link
Member

@bghgary
I've added a note on non-invertible transformations. Please merge if everything is fine.

@bghgary bghgary merged commit 8b03e14 into KhronosGroup:2.0 May 31, 2017
@bghgary bghgary deleted the negative-determinant branch June 1, 2017 16:10
@zellski
Copy link
Contributor

zellski commented Nov 3, 2017

Just for clarification -- by spec, generated glTF should, without question, reverse winding order whenever it detects negative scaling either through static transform or an animation path? I was a bit taken aback by this, because I figured it's so common for applications to dynamically mutate these transforms later... that whichever transform is embedded in the glTF is not necessarily so intrinsic that it should affect a geometry rearrangement. It seems like it could foist some unwanted astonishment onto the user. But maybe negative scale is such a specific thing that it's warranted. So it would make sense for a FBX->glTF converter to detect this situation and compensate as suggested?

@bghgary
Copy link
Contributor Author

bghgary commented Nov 3, 2017

by spec, generated glTF should, without question, reverse winding order whenever it detects negative scaling either through static transform or an animation path?

Hmm, perhaps the implementation note should be clarified. The intent is that this is the runtime behavior of a client implementation (e.g. a rendering pipeline).

So it would make sense for a FBX->glTF converter to detect this situation and compensate as suggested?

I would not expect converters to do this.

@zellski
Copy link
Contributor

zellski commented Nov 4, 2017

Thanks @bghgary. Chances are I'm just easily confused and the spec language is fine. I'm relieved to hear you say this, though. It felt like a strange operation for a static converter to perform. If I add it I'll hide it behind a flag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants