Example if i have one object with many faces with static or no collission physics if this object in inactive layer cost any performance to BGE?
in resume spawn this object when needed is better of stay this object all time in main active layer?
most of the time, having objects on inactive means no rendering or logic is happening which means minimal performance loss. however, i think the object still need to be stored in ram?
the exception is lights. lights are always processed, no matter where they are. very bad for performance.
in this case the environment object will be used in level 3 only then when playing level 1 or 2 i dont spawn the group of this objects right? the group of object stay in inactive layer.When playng level3 spawned correct? for get better performance?
So your level will still be in RAM, and for an environment, this may be quite large. You could investigate using multiple blend files, one for each level. You could then link your character rig into each level blend file, and use the game actuator to switch between them.
+2. I agree with jeoff. I second multiple blend files, or lib-load. But, I donāt link my player character, instead, I get my player char the way I want it in one blend. Then make multiple copies of that blend. level1.blend, level2.blend and so on. I use a script to write data to a text file, like health, ammo, points, trophys etc. then each level.blend will read from that script so the user doesnāt lose any items. Itās just easier for me, but linking the char is just as good, maybe better.
In the old days with 2.49, I would export as runtime, and change the āstart game from fileā actuator from level1.blend, to level1.exe. save all level.exe to one folder, and it worked. But lately that hasnāt worked for me. But maybe I did something wrong, as I didnāt test that fully.
Adding to the topic ā for a particularly large area or a hypothetical open world, has anyone tried cutting the map itself into separe blendfiles and load/unload them as needed? e.g. libload in the cell the player is currently in plus all adjacent cells, then libfree those that are distant enough. It makes sense to me, in theory at least, but perhaps Blender isnāt so keen on the idea.
Yes, I have, but I have trouble with libfree crashes, and others have stated that libload is unstable.
But yes I have. 
I have a 3 levels of my game in just 1 blend file. i prefer working with this method
I have large open worlds,
I use a planets quads and skin each quad with a patch, a patch is a subdivided plane,
when a patch spawns in it samples noise at each vertex and generates height and color data based on the noise, I then use texture nodes to mix materials using this data,
when a patch spawns in that is saved, it can also load in objects that were on the patch stored in a list per tile
own[āSavedTilesā][faceIndex] = (vertexDict,objectsData, spawned)
vertexDict[PlaneVertIndex] = (normal, color, uv, position)
this map is using the technique and I have a whole world
I am planning on swapping out the terrain with this GLSL node shader
we have
SpawnedTiles[ index ] = TileInLocation
SavedTiles[index] = data
FreeTiles[index] = a Tile object
we use a kdtree of the faces -> this makes it return the points in order of closeness
we attempt to fill x tiles per frame so we donāt pull down the frame rate
we bail after we check too many tile or fill too many with break
1 proccess in the script fills tiles
another tries to free them (if they are outside of a radius they are added back to FreeTiles and turned invisible / suspend physics and objects on the tile are updated / saved in savedTiles and so is vertex data )
1 Like
Great explanation then spawn with add remove based on level when player stay can be get a good performance. in large open world my Camera View go to 1800.00 cause have look a sky day/night cycle. but can work with near for remove objects when in long dustance o player view