ModelOverride Offset

[RuffledPlume]

JSON Added for the Model Overrides:

      "modelOffsetRelative": {
        "type": "boolean",
        "description": "Applies model offset relative to the models orientation."
      },
      "modelOffset": {
        "type": "array",
        "description": "xyz offset",
        "items": {
          "type": "integer"
        }
      },

[aHooder]

I think respecting model orientation should be on by default, but it doesn't hurt that it's configurable.

The preOrientation stuff is tricky though. You can go check the tables in the Canifis bar I think, if you want to test how that works. I believe in this case, we'll want to subtract preOrientation from the orientation, or perhaps disregard it entirely, not sure. If I remember correctly, preOrientation is rotation applied to the model before it reaches us, as in it's already applied to the vertex data. That's why we pass in preOrientation to UV calculations, so they can invert the rotation before computing UVs from a reliable base orientation for the model.

[aHooder]

I feel like we should go through and validate the XZ orientation stuff a bit more thoroughly before merging that part of it, but I don't want to get bogged down with that currently, so this is sort of on hold. If we want to, we could make this only work along Y for the time being, so it can still be used for to fix the actual issues we need it for. The existing XZ offset in LightManager is also not entirely correct, so it would be good to unify it with whatever we end up with, which is hopefully correct in more cases.

[Jin-Jiyunsun]

I feel like we should go through and validate the XZ orientation stuff a bit more thoroughly before merging that part of it, but I don't want to get bogged down with that currently, so this is sort of on hold. If we want to, we could make this only work along Y for the time being, so it can still be used for to fix the actual issues we need it for. The existing XZ offset in LightManager is also not entirely correct, so it would be good to unify it with whatever we end up with, which is hopefully correct in more cases.

Would be fine by me doing only Y, I have personally yet to come across anything that would benefit from offsetting X or Z, as usually moving stuff like that will just make more holes or gaps