Ambiera ForumDiscussions, Help and Support. |
|
|
|||||
|
Since I'm planning the level design of my current project I wonder how to deal with the following fundamentel question (even before thinking about any LOD system): Which "terrain mesh - material - texture" combination would be the fastest one, getting the highest frame rate out of CopperCube during game runtime? Variant 1) one single big terrain mesh with one single material using one single 8k texture Variant 2) one single big terrain mesh with four different materials using four separate 2k textures (one per material) Variant 3) four individual smaller chunk meshes (each containing one single material using one single 2k texture) to sum up the big terrain from variant 1) or 2) Any help/thoughts on this appreciated. Thanks. |
||||
|
From what I've read, I think if you use the coppercube terrain, rather than a mesh, the engine culls the terrain automatically. 2- Then if you child your static objects to the terrain, it will cull them automatically too. 3- Try to merge multiple textures into one wherever you can as multiple textures on single models require more draw calls each frame. 4- Then one final thing is to clone all your static meshes as "animated mesh instances" (using coppercube's right-click menu) to render them more quickly than static meshes. In practice, this sped my game up hugely from a crawl to something quite speedy. I've also sometimes noticed huge differences in game frame-rates between certain model types (especially if I apply dynamic lighting and the built in "rotation" action... Sometimes FBX models slow my game down, so I convert them, to either .x (for animated models) or .dae for static and they work properly again - other times, FBX works just fine. Robo has been experimenting lately with single-mesh terrains. He has a few videos up with some ideas - and other users recommended lowering the poly-count of models - I managed to "decimate" my models by up to 90% in some cases and around 50% on average without much noticeable difference - although it can take time to swap all the models and apply the textures again. Polycount and lower texture-count of models seems to affect game-speed much more than individual file-sizes of models and textures but if you use the built-in terrain editor, I think the density of the mesh and the size of each terrain tile is the main thing to consider. So, ultimately, maybe consider experimenting with using a flat "built-in" coppercube terrain with a manageable amount of grid tiles, then place/child your split mesh solid terrain ontop to the coppercube terrain, to make the coppercube terrain cull your static model. One thing to consider with Coppercube terrain editor is that the Position and size of the terrain cannot be adjusted after creation. |
||||
|
Variant 3 ======= Where those 4 chunks reside in 4 seperate scenes. Your actions and travels all take place at the middle of the terrain -> you dont have to worry about looking outside the scene. And all scene transitions take place somewhere indoors or where parts of the environment where copied to match the connection/transition into the other scene. When firmly landed in the new scene remove the old scene from memory. Variant 4 ======= Create a tileable heightmap texture. use that to create a smaller tileable endless environment. Mesh generation from heightmap may be inaccurate -> not perfectly tileble meshes, then hand correction in blender or sketchup neccesary. for example: Tile1 = forest/plain Tile2 = road East to West Tile3 = road North to South Tile4 = road East to West crossing road North to South These 4 must match in mesh placement and height and in texture colors to be perfectly (unnoticeable) tileable. The idea of using such large textures is for windows only. And may not work well as moving and transforming this texture ( rotating camera ) in memory may become a burden. Notice: Recommended minimum hardware: Double Xeon, 128 GB RAM ... succes |
||||
|
Thanks a lot @DouweDabbe and @VeganPete, your thoughts give me helpful impulses to think. With a bit more time I could do some performance tests and maybe post some results ... |
||||
|
Nice one [b]Hadoken[b/]. Would be great to see the results of the tests if you get time. |
||||
|
|
){kind=link}