Zone Invalidation Improvements

[RuffledPlume]

• Zone Invalidation is triggered as soon as the API is invoked
• Wait for all queued invalidation to complete before the next update is triggered
• Moved JobGroup removal to release, not completion since we still want to loop through JobGroup work in some cases
• Added FrameCounter to allow tracking of when ZoneUploads we're queued

[aHooder]

This looks mostly good, I'm just not sure about skipping invalidation for the current frame. Queuing invalidation jobs asap seems good, and we ofc ideally need to block until they're complete before rendering that zone whenever not doing so would result in animation flickering. The issue is this might accidentally introduce stuttering while sailing, perhaps due to item spawns being loaded in via invalidation post scene swap, causing a stutter if we block. I'm also not sure if skipping it just for one frame will help much here either.

I think either we could try to detect this animation flicker issue, and only block in that case, letting as much load async as possible, or we could perhaps never block when the player is sailing 🤔 Do you have any thoughts on this? Tbh I'm not sure how we could reliably detect the animation flickering issue.

[RuffledPlume]

Detecting that the player is sailing is probably as simple as checking the Local players world view to see if it's not the root, however I'm not sure that's the best route.

Since this flickering is tied to zone invalidation & a dynamic renderable, there has to be something innate about this setup that we can detect. It's odd that it causes a flicker, since other dynamic renewables don't flicker mid animation due to a zone invalidation.... Right?

I wonder if the model is added as a alpha model, or is maybe a MultiLoc.

Where is this happening again, I'll work up to being able to see it locally so I can also debug the issue.

[aHooder]

It is probably possible to detect, yeah. The flicker occurs when a GameObject with a DynamicObject renderable (although null getModelZBuf() probably) changes to a static GameObject with just a Model renderable, as far as I know. It likely also technically has an issue of duplication when transitioning from static -> animated, but I haven't seen that. I guess the most basic check could be to keep track of the count of non-null getModelZBuf() results in the zone, and block on invalidation only if that number changes. That'd mean we'd have to block on estimation though.

[RuffledPlume]

Hmmm, we could also keep track of what gameobjects are being dynamically drawn within a Zone, so keep a HashSet of GameObjectIds which is cleared at the start of each frame.

Then within InvalidateZone, we can then check within there has any of the dynamically drawn GameObjects become part of the Zones static geometry, if so we tag the invalidation as blocking

[RuffledPlume]

I've updated the PR to include a check within invalidateZone, it should catch Dynamic GameObjects becoming part of the Zones static Geometry & cause the subsequent upload job to block before rendering the next frame.

This should prevent the dynamic gameobject from flickering, whilst allowing all other zone invalidations to occur async

[RuffledPlume]

Fixed as part of #921