-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Cesium treats +X as glTF forward vector, 2.0 spec says it's +Z. #6591
Comments
Also this repo contains an out-dated |
New vehicle added in #6592. Note that if you use the corrected model with |
Expanding the scope: It's not just One option here could be to add a |
As you already noted, the scope here goes far beyond models. I think this is a massive breaking change for Cesium if we were to make it. I'm not sure changing all of Cesium because of glTF 2.0 is the way to go. It might be better for the Model primitive to have special logic for handling gltf models so that glTF "just works" with Cesium's existing convention. |
Yes, and I suspect the existing |
Is that all related to this? #3256 The East/North/Up transform we default to everywhere makes |
@hpinkos I was noticing that in my testing of headings just now. |
@emackey yeah, I've been trying to argue for years that |
@hpinkos OK. I think that's an unrelated issue. The proposed fix here would just make glTF 1.0 and 2.0 agree on East. |
Gotcha 👍 |
Fixed in #6632 |
Not sure how I didn't notice this before, but
VelocityOrientationProperty
apparently places the+X
vector as the forward vector, while glTF 2.0 settled some time ago on the+Z
vector being forward.This means that all glTF 2.0 models used with
VelocityOrientationProperty
will fly or drive sideways.The text was updated successfully, but these errors were encountered: