-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Conversation
What if animated |
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. 😨 |
@bghgary |
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? |
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).
I would not expect converters to do this. |
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. |
As requested in #971 (comment)