Performance Enhancement: Moved Automap to its Own Physics Layer

[Vwing]

Moved Automap onto its own non-interacting physics layer, so we don't have to constantly enable/disable its game objects. This is a huge performance boost in large dungeons.

Also we now destroy the generated Automap geo immediately on transition to the outside. This could wait, before, because the geo was disabled; but now that we don't disable geo, we need to do it immediately.

EDIT: Ah, it was already on its own physics layer. I just set it non-interacting with other layers and removed all the then-unnecessary-and-super-unperformant enable/disable code.

[Daneel53]

Will push this one into the next 1.2 Test3.

[RedRoryOTheGlen]

Tested on 1.2-Test3, the automap markers and models are detectable by the player's activation raycast. This makes activating actionable objects inconsistent as the raycast may hit the automap model of the object (and result in no activation) or hit the player or compass automap marker model.

To replicate, Privateer's Hold has the lever in the throne room and the hidden switch that rotates the book shelf in the summoning circle room. Both actionable objects are affected by this issue.

Activation check returning automap model of lever (with name manually changed for clarity)

Automap markers blocking the activation raycast

Excluding the Automap layer from PlayerActivate.playerLayerMask has been tested to solve this issue.

Thanks for your work!

[Vwing]

Glad you caught that. I went ahead and excluded the 'Automap' layer from every raycast that doesn't need to interact with it, PlayerActivate included.

[Vwing]

Undid changes that would've conflicted with #2781, since it already ignores Automap.

[Daneel53]

This PR was deeply tested into 1.2 Test3 in the same time as RedRoryTheGlen's PR 2781.
Both authors confirm that all is now working as intended.
Both PR are ready to be integrated into the game.

[KABoissonneault]

I'm not sure I understand why every raycast call needed to be modified for this change. It seems like if that's truly necessary, then this change would break any mod using a raycast that's not been modified to exclude the Automap. Can't the Automap be excluded from physics by default, and be enabled only in those sections that need for rays with the automap to block?

Gonna put this PR on blocked while we resolve this

[KABoissonneault]

Could we get some screenshots of what this change looks like from the editor?

[Vwing]

Yes, here's an animated gif showing before and after the change:

Before: Automap collided with everything
After: Automap only collides with Automap

[Vwing]

It's not entirely necessary, was just being prudent. The only tested-broken cast was in PlayerActivate; trying to select a lever, for instance, would sometimes hit the automap version of that lever.

Unfortunately there isn't a way to make a layer default-excluded from raycasts.

But I could test a couple workarounds that are more constrained to just changing the automap code. Will investigate later this week.

[Vwing]

@KABoissonneault I have reworked the AutoMap so that it no longer generates its geometry at the same position as the real world geometry. I set the offset to -10,000 in the y, so it's being generated 10 kilometers below the world (Unity units, not game units - Unity units are larger). In cultural reference terms, it is now a "Backrooms" rather than an "Upside Down".

Also reverted all changes to Raycasts.

Tested it out, and levers work as expected. Automap functions as expected. And we still get 30fps performance gains in large dungeons, the goal of this PR.