Update CHANGES for model orientation change

[lilleyse]

Fixes #6713 by giving instructions about how to correct models that are rotated unexpectedly.

[cesium-concierge]

@lilleyse, thanks for the pull request! Maintainers, we have a signed CLA from @lilleyse, so you can review this at any time.

---

I am a bot who helps you make Cesium awesome! Contributions to my configuration are welcome.

🌍 🌎 🌏

[hpinkos]

@lilleyse is this transformation something we apply runtime in Cesium or is it saved as part of the glTF? Can we have more specific instructions for how to make this change? I wouldn't know how to do it from what you wrote.

[lilleyse]

It's saved into the glTF. I updated the wording, hopefully it is clearer now.

[hpinkos]

Which one is the root node? Is it always nodes[0]?
What do I do for my glb models?

Would something like "open up the source model in a model editor and rotate it to face the correct axis and re-convert it to glTF" be an alternate recommended solution?

The instructions need to be clear to someone who has little to no understanding of the glTF spec. Asking someone to open the glTF in a text editor isn't a good solution for someone with less of a technical background. And it won't work at all if that matrix has a value already, right?

[likangning93]

@lilleyse @hpinkos is providing a client-side workaround for "wrong" models ok? It'd be more self-contained than, say, developers having to hand-edit the glTF or ask artists for new assets.
It seems like for most Entity/CZML cases this could just be solved by adjusting the entity orientation:

    var position = Cesium.Cartesian3.fromDegrees(-123.0744619, 44.0503706, height);
    var heading = Cesium.Math.toRadians(135); // add/subtract 90 degrees
    var pitch = 0;
    var roll = 0;
    var hpr = new Cesium.HeadingPitchRoll(heading, pitch, roll);
    var orientation = Cesium.Transforms.headingPitchRollQuaternion(position, hpr);

    var entity = viewer.entities.add({
        position : position,
        orientation : orientation,
        model : {
            uri : '../../SampleData/models/CesiumAir/Cesium_Air.glb',
            minimumPixelSize : 128,
            maximumScale : 20000
        }
    });

And then in the Primitive API users probably just need to premultiply a rotation onto the model matrix or something.

[mramato]

I don't think a Cesium workaround is a good idea because the model is still "wrong".

I'm with @lilleyse on this one. Cesium was incorrect before and that led to equally incorrect models. We should advise everyone to fix their models.

[lilleyse]

Yeah, models that are definitely incorrect should be fixed. E.g. the ground vehicle was +X forward and was fixed to be +Z forward. I don't think I would consider @kladess's models in #6713 incorrect though... which is why I don't really like the suggestion in CHANGES.md all that much. I think the CZML update would actually be a lot easier. But I guess if we had to pick one thing to go in CHANGES.md, it would be to update the model. Now time to get the wording right...

[likangning93]

We should advise everyone to fix their models.

I still think we should have a client-side fix documented in some capacity.
What about for users that don't have the option to fix their models?
Maybe the glbs are being loaded from a customer's server and the customer refuses to fix the models, or the point-of-contact is on vacation until after a deadline, or a myriad of other frustrating reasons.

[mramato]

I still think we should have a client-side fix documented in some capacity.

OK, if @lilleyse agrees with this I'm fine with it.

[lilleyse]

Updated. I tried to cover all the cases here, but didn't want to get too verbose. I linked back to this PR where we can provide more instructions if needed.

[likangning93]

Some modeling programs might have a different up/forward convention, so maybe it's better to specify something like a 90 degree clockwise rotation about the Up-axis.

[lilleyse]

Thanks @likangning93, updated.