Ambiera ForumDiscussions, Help and Support. |
|
| [ 1 2 ] Page 1 of 2 |
|
|||||
|
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 Hadoken. Would be great to see the results of the tests if you get time. |
||||
|
Be interested in your findings hadoken as I have recently gone back to the idea of using CC inbuilt terrain as it uses less texture memory by re-using the textures. I now also have terrain texture according to slope angle and walking sounds all working so has a lot of benefits over simple terrain mesh although if only small in scope, a mesh with single dedicated texture will look better... Then again, I have yet to expand the basic 3 textures to 4 or 5 and with individual slope angles for each...that could rival the look of the 3d mesh setup much closer while up close much more detail. The problem I see with CC terrain atm is how blocky the mesh looks and loads by default from heightmap. If I reduce tile size and increase heightmap size then should look a lot better but then have much more polygons to display and hence lower frame rate. The old Irrlicht terrain system (different to CC) uses up to 8 LOD's but only 1 texture with 1 detail texture. CC doesn't appear to use any LOD's I can see... I've been experimenting with Irrlicht 's occlusion system but it doesn't copy and paste into CC at all...its setup differently.. |
||||
|
hey @Robbo, although your latest impressing results with CC's built-in terrain may prove me wrong I currently rather stick with my custom terrain meshes for 100 % control, baddest part of CC default terrain is its mandatory square shape form factor instead of some rounded borders like nature more looks like within the past months I did some terrain/environment research for my projects: I experimented with LOD systems, GLSL shaders, material & texture variation systems plus vertex color fake light-mapping from which I already got nice results here and there didn't have the time for more so far, but with the help of my latest mesh master extension (for plugin manager on itch.io) I might expect even better results in my further research for example, I was able to cut a big terrain mesh into smaller chunks in blender, but getting these with correct positioning & individual origin setting to work with CC's on proximity behavior (faster than JavaScript distance calculations) seems to be possible for me only now I have mesh master (so far did not test it out yet, but planning to ...) last state of things was I ended up in going for small level cells being connected by obvious or hidden scene changing portals so the frame-rates keep manageable (no real big open world, but at least maybe some illusion of it) I found your new API additions very interesting, especially the auto texturing per slope you let CopperCube do - like I'm used to do with my external tools outside the game engine some point is, since everyone knows CopperCube's graphics might look a bit retro (which I am totally fine with, because I really value gameplay much more than top notch graphics) I try to create nice looking projects with CC but which should still be compatible with older hardware (letting projects with graphics from 2010 also run on computers you can still get cheap from that period) so that's why I also like to use CopperCube version 6.3 with 32bit support where I still can, so your new API launcher doesn't help me in the first place, but for 6.6 projects further on it surely can @Robbo, I know that you have only access to CC's source and not the editor itself, but for the case of using your launcher, can there be done something about to prevent starting the core project .exe file without the launcher to make sure all new features are used by the game? I also would like to rename & hide the core project .exe file from the user as being an executable file cheers |
||||
|
@hadoken, what you can do to make sure that the main game exe won't run without the launcher by creating a scene that will check for the new functions, for example if you will be using my launcher having the function "ccbRemoveTexture()" then you can check if the function is defined or not with the help of typeof === "function" if the function is defined then switch the scene to the game, otherwise show an overlay or error message that the game should be run through the launcher.exe I finally completed the itch.io page, needs to create sample demo for the launcher, so that people knows how to use the new api functions and all. hope people will find that useful as well, i will be expanding that with new features and bugfixes. |
||||
|
sounds good, @thanks just_in_case, will keep an eye on it |
||||
|
Thanks hadoken , and interesting idea from just_in_case also. My own idea was to eventually hide the core CC game exe file under 1 or 2 folders - so not in the main section that the launcher exe is located in and so its sort of hidden and even if run wont work right anyway without the new API. All I would have to do is edit one of the source files to have a different location then recompile. Yes, CC terrains are blocky - no doubt about it. If you try load a large level from bigger heightmap and with smaller cell sizes then you get too many polygons and just wont work right. I found 512x512 is about max I am happy with atm giving almost 500k polygons. I also experimented with many large sections of a fixed 3d mesh terrain and combine together in CC with distance checks and 2x LOD&039;s but either way uses separate textures and very difficult and try and get memory usage down even if using just_in_cases new API for texture memory dropping and reloading (streaming), would still be difficult to manage and still wont load asyn causing the game to stop and start. That method is best for changing texture quality in a menu environment. I tried using Irrlicht occlusion system which if could work would be awesome actually but unable to work out the syntax adjustments needed between Irrlicht and CC. Maybe just_in_case could have a go ?? I am currently trying to adjust the vertex heights rather than cell angles as being more accurate and the vertex side seems to be the main problem with sharp angles, not the cell angles so much. Have to see how that goes... |
||||
|
If you don;t mind me chipping in again...as you say Robbo, increasing poly-count just to smooth out terrain geometry will induce slow-down. I just had a thought which may be relevant asa possible solution- when using a low-poly mesh, you can smooth the appearance of the harsh, angular geometry by using vertex normals, in conjunction with lighting - is it possible to do the same with height-mapped terrain? -ie: use low-poly height-mapped/tiled terrain but somehow with vertex-normal shading to blend the sharp geometry, rather than increase tile/polygon resolution to smooth it. That may be one of the key differences between the appearance of a Height-mapped Terrain-tiles and a modelled, Mesh-terrain. If not, you can possibly strike a balance between smooth appearance and low-poly count performance by using a low-poly terrain-mesh (or slices, as mentioned by Hadoken) and then apply vertex-normal smoothing to disguise the faceting of the triangles/faces. You can probably use blender's modify-nodes to decimate the model and massively reduce poly-count without affecting geometry detail, then add the smoothness back in using just the vertex-normals. After much tinkering with CityEngine, I've opted to use terrain meshes for the fact that (for each of my 200 city scenes) a single height-mapped terrain (Generated by CopperCube) was ~160MB with a crazy amount of polygons - whereas the same heightmap as a CityEngine terrain-mesh was around 20MB... manually recreating a similar terrain-mesh (using a 2D plane and CopperCube's polygon editor) seems to take just around ~1MB instead and looks just as good when vertex-smoothed. For your game though, the terrain is probably a huge feature and would be a deal-breaker if it looked shoddy or glitched the performance. Maybe a happy-medium is best in your case. |
||||
|
Thanks VP, yep, I&039;m still experimenting. I just added the occlusion culling system from Irrlicht into CC source code but it may not be helpful from looking at the code...its based on a single or a few occluders at most occluding the rest of the scene in view frustum rather than checking every non culled scene mesh against every other non culled mesh as that would be too much to check every frame... I might have a few easier other ideas for basic terrain culling. In terms of smoothing, the vertex&039;s for each cell (2x triangles per cell square) can be smoothed to look batter without adding new geometry so thats what I will try. Smoothing the vertex normals might also be helpful as you mentioned to get a better look. |
||||
|
Quick update on occlusion culling in CC: I have got the irrlicht Occlusion Culling system to work in CopperCube now (took like 2 days with like 40 files to update) and is now working on the terrain system tiles. Im geting a 35% increase from a low of 200 FPS in certain places to a min 305 FPS now.. so its working. Im also getting a strange flashing of dark background every few seconds though....have to investigate why... any suggestions welcome... |
||||
|
That's an awesome frame-rate improvement Robbo - well done buddy. Another thing I just thought of is texture "blend mode" - when I do graphic design, I often use hundreds of layers (all stacked on top of each other). If I mask teach layer properly (kinda like an occlusion), it takes quite a while to do properly and the software quickly starts to crawl: if, instead, I change the blend mode of the layers, it can achieve the same visible culling with no noticeable impact on performance - and it's a lot quicker for me to do. The main reason people would prefer masking is because then it's not dependent on any other layers (whereas blending textures makes them all dependent on other layers - prioritised by their layer priority (those behind are affected by those infront). I'm not certain how that relates to coding in coppercube - I suspect a similar thing could be done with a fairly simple shader that is dictated by z buffer, but I'm just guessing. I imagine that all the relevant functions probably already exist in the API somewhere as it's an extremely common feature for graphical layering. Just be aware that layer-blending the materials/textures may screw around with the lighting/normals - not sure, just an imagined possibility. Just a quick thought, might not be relevant/advantageous at all. Congrats on what you've achieved so far by tweaking the API. Good luck - very inspirational developments. |
||||
|
Thanks for that VP - will have a look into that idea also. I found the issue related to the 2D overlays (mostly) as these are not in the irrlicht code so never was an issue with irrlicht occlusion. Something to do with z-buffer maybe and occlusion though should not be as they are not culled.. I made it even better now than the existing irrlicht code. I first check for culling via the camera frustum and if within view then I update the array data for occlusion checking within the view only. Before was checking all terrain tiles all the time (194) every frame but now can go anywhere from 2 to 110 and so much better for performance wise. I&039;m getting almost 100% framerate all the time now...(for me is 334 FPS). Just need to fix the 2D overlay thing... |
||||
| [ 1 2 ] Page 1 of 2 |
|
|
){kind=link}