I noticed @Calinou had just added a version with poly occluders, and I figured that the level would run better with the central core area as an internal room.
I added a RoomManager to the level.tscn, and put the Lights, Structure, Props and Core within a RoomList spatial.
The Room_Structure is the outer room, and the Room_Core is an internal room (using the RoomGroup to set the roomgroup priority to 1, which is higher than the 0 default outer room priority). This means that the camera will be in the outer room unless inside the core room.
The bounding points for the core room is very rough, it appears that the player can only enter (due to physics) through the walkway, so that may not be a problem.
rooms_convert() is called in the level _ready() through a call_deferred() so there is time for setting the portal mode of dynamic objects before the conversion.
Portal mode for dynamic objects
As the player, robots etc are currently placed within the level, it is necessary to explicitly set their portal mode so they show up as the camera moves between the rooms.
Instead of setting the portal mode in the inspector, the player, robot, bullet and forklift call a function Portals.change_portal_mode_recursive() in a Portals autoload, which sets all MeshInstance, Particles and CPUParticles.
The player is set to global portal mode (as it is always visible), the others are set to roaming (which will cull them correctly through the portals).
This leads to quite a performance increase for me, depending where you are in the level and what you are looking at. It varies from about 20% fps increase outside to as much as 100% increase when in the core area. Of course this depends what you are looking at, what your settings are (and hence your bottlenecks).
I left in the Occluders, but set them to invisible so they won't be active. Useful for comparison purposes.
I added a P key action on the keyboard for turning on and off portals at runtime, to compare fps.
I noticed @Calinou had just added a version with poly occluders, and I figured that the level would run better with the central core area as an internal room.
RoomManagerto the level.tscn, and put the Lights, Structure, Props and Core within aRoomListspatial.Room_Structureis the outer room, and theRoom_Coreis an internal room (using theRoomGroupto set the roomgroup priority to 1, which is higher than the 0 default outer room priority). This means that the camera will be in the outer room unless inside the core room.rooms_convert()is called in the level_ready()through acall_deferred()so there is time for setting the portal mode of dynamic objects before the conversion.Portal mode for dynamic objects
Portals.change_portal_mode_recursive()in aPortalsautoload, which sets allMeshInstance,ParticlesandCPUParticles.This leads to quite a performance increase for me, depending where you are in the level and what you are looking at. It varies from about 20% fps increase outside to as much as 100% increase when in the core area. Of course this depends what you are looking at, what your settings are (and hence your bottlenecks).
Occluders, but set them to invisible so they won't be active. Useful for comparison purposes.Pkey action on the keyboard for turning on and off portals at runtime, to compare fps.PERFORMANCE UPDATE:
In combination with https://github.com/godotengine/godot/pull/33340 and using small screen, with everything else low but shadows on:
Core, just to left of door, looking back (best case)
Starting position, looking at core (worst case)