When making our games, it's very important to us that the world feels alive and compelling. Faking the scale with skyboxes is a fine approach, but I find it much cooler when you can see something in the distance and actually GO there seamlessly.

Therefore, having constant scene transitions between each area is a no-go for us. We reserve any full-on scene transitions only for going to entirely separate areas, such as building interiors.

But of course, having a ton of nodes constantly active nowhere near the player is a nightmare for performance. The same goes for distant geometry.

So how do we do it? We split up the world up into individual scenes that connect to each-other within the main world scene. Internally we refer to the main, full world as a globe, and each segment as islands. Then - and this is the key detail - within each of those islands, we house an Area3D that's always active. These Area3Ds are responsible for the changing of each segment's root node process modes. When the player is outside of the area, the process mode is set to disabled. When inside the area, it's enabled.

This ensures we never have more than (usually) two islands of the world active at any given moment. Meaning collision & code that don't need to run... simply don't run.

We then fine-tune these area collision shapes in a way that ensures node processing becoming enabled/disabled doesn't visually appear to the player, which usually involves masking the transitions between each area with geometry so they can't ever notice things activating. Additionally, we really sell it by having larger nodes that have their process mode set to always moving in the distance that you can see from multiple angles around the map. It helps the distant level segments that are disabled still feel alive when you're looking at them from afar.

Finally, the alternative to this approach would be to follow a similar one, but with individual process mode enabler/disablers per node. This is for example if you have enemies that can follow the player through segments or objects the player can take throughout the world. Our game is largely designed in a way where we don't need this, though we do have objects you can bring from scene to scene and segment to segment. For those, instead of individual process areas we handle them with smart node re-parenting as you play.

If you have any questions, go ahead and shoot! I think we've landed on a system that compliments our game well, and utilizing similar ideas I'm sure it can be applied in various situations. I'm aware it's not exactly anything novel, but I figured giving a little look into how we're going about the process for our own game might help others.

How we're accomplishing a large 3D open world in Godot in a surprisingly simple way