Update mesh AABB when software skinning is used

[pouleyKetchoupp]

Not updating the mesh properly can cause rendering issues in some cases, like shadows not updating properly.

This is 3.x only since software skinning is not implemented on master for now.

This change seems to have a limited impact on performance. In release_debug, I've only noticed a drop of around 4% when updating +100 models at once (mostly due to calculating the AABB itself, not dynamic shadows).

Fixes #53018

[akien-mga]

Thanks!

[lawnjelly]

Just to note, it's usually better to update AABB in a high performance setting something like this:

godot/servers/visual/portals/portal_renderer.h

Line 338 in dbe0e46

// update the AABB

The Godot AABB structure is not good for fast building, for this working with min max works better, than convert to position + size in a final step.

Also for skinning, often the approach used is to use a conservative oversize large bound, and not recalculate it. So being able to set a custom AABB, and if this is set, to not do the AABB calcs might be good.

Still this works to be going on with.

[pouleyKetchoupp]

The Godot AABB structure is not good for fast building, for this working with min max works better, than convert to position + size in a final step.

It's amazing, I just made a test based on an equivalent of the portal code, and it works very well! This gets rid of most of the drop in performance, I'm going to open another PR.

Also for skinning, often the approach used is to use a conservative oversize large bound, and not recalculate it. So being able to set a custom AABB, and if this is set, to not do the AABB calcs might be good.

Makes sense too, although in this case, even if the AABB wasn't modified we would have to call an instance update because of displaced vertices, so from what I see it doesn't look like it would make a lot of difference. Might be useful in specific cases though, it's good to keep in mind there's more room for improvements.

[lawnjelly]

It's amazing, I just made a test based on an equivalent of the portal code, and it works very well! This gets rid of most of the drop in performance, I'm going to open another PR.

Yeah it will reduce to just a couple of SIMD instructions per vertex I expect, whereas the default Godot mechanism for expanding will have all kinds of branching and extra work that only needs to be done once off.

This is a bit of a trade off and why some engines store AABBs / RECTs as min / maxes rather than position + size. The windows RECT structure for instance is left, top, right, bottom, presumably for these kinds of reasons. Storing as min / max is faster for building and intersection testing, storing as position + size is faster for moving.

The other great trick BTW (although can't be used here I don't think) is to store the max values of the AABB as negative max (or min as negative min). This means you can do intersection tests with all comparisons of the same sign, which means they can be combined easier in SIMD instructions. I do this in the BVH.