As in my other thread, I’m working on an action RPG FPS that uses randomly generated levels (mazes). How it works right now is that I create a 3 dimensional array of Cells, and each Cell is then used to create one or more Geometries, which are then attached to a Node, and all of those Cell Nodes are then attached to a Level Node (still Node objects, I’m referring to instance names here).
Right now, things are fairly simple so it runs fast. It generates fairly large mazes, but they dont slowdown. However, nothing else is happening so thats not surprising. I read the optimization section of the docs, and I see it mentions to avoid using large numbers of geometries unless you can help it. Obviously, I’m concerned about my level here.
Can anyone suggest a good way to speed things up? I’m looking at using the GeometryBatchFactory, my concern is that not all of my Geometries will use the same material. I could possibly combine Geometries if they form part of the same wall or floor though. At least some parts of each level will be prefabricated, meaning they will be small scenes made in an editor and imported in at run time. Probably not too many of those though.
So, a few questions if you dont mind:
Is there any optimization strategy or technique that would work on Geometries that dont have the same material?
If they do have the same material, do they have to be adjacent? Ie, can I build up a list of all geometries that use the same material, no matter where they are in the level, and optimize them? Will that work?
Is there anything else I need to do to enable Occlusion Culling besides setting the CullHint to Dynamic? I change the cull hint for the parent and leave the children as the default, which I believe is InheritFromParent. Anything else I need to do? With debugging information on, the number of triangles rendered still seems too high when standing right in front of a wall blocking the rest of the maze.
Your best bet is a textureatlas for all with the same shader but different textures, that way you can batch all of them into one geometry.
Annother approach would be to calculate wich ones are visible, and only render those (you could take a tlook at bsp system, as it is exactly made for mazes (you probably have to optmize it a bit for realtime use, but since the used geometrys are all simple there are probably some good optimisations possible.
Default cull hint only culls stuff outisde of cam view cone. For your case a more complex system is needed.
I thought cull hint referred to occlusion culling and not frustrum culling. Anyway, I saw a contributor made a patch about a month ago to add BSP culling, so I’ll revisit his work and see whether it will help.
I’ll have a look into a textureatlas, thanks. Its highly unlikely that the walls and floors will use a different shader, I cant think of a reason to do so, so that should work fine.
Personally, I wouldn’t worry too much about odd culling situations until it becomes an issue. There are as many strategies for that as there are game engines, I think.
For your geometry problem, start with something simple like just batching geometry together by material. They don’t have to be near each other or anything though that would help with the default culling. I think the geometry batch factory thing has a way to batch by material.
I’ll test it out soon, maybe tonight. I think I’ll build up a dictionary of Materials and Geometries. Then, for each Material in the dictionary, merge/optimize all of the Geometries. I think I’ll use two wall materials and randomly vary them, to guarantee that not all of the geometries will be adjacent.
In future, the material used, and even some of the construction details such as arches, alcoves etc, will be determined by the SubTheme allocated to the Cell. I havent implemented that yet though.
I’ll have a closer look at the texture atlas but I’m concerned that A) the necessary nvidia tool wont run on Linux or Mac, and B) this all has to be done at run time after the level is generated (which means I would have to distribute the tool with the game). I’m not sure how suitable a texture atlas is for that use case, but I’ll do some more investigation.
the atlas can be generated prior runtime, basically you give it a folder and it returns an atlas (or multiple if not enough space for one). It gives you a way to determine the right texture coordinates for the mesh then
TextureAtlas atlas;
atlas = new TextureAtlas(Gdx.files.internal("packedimages/pack"));
AtlasRegion region = atlas.findRegion("imagename");
So depending on texture wanted you just set the right coordinates then.
This allows you to batch them far more efficiently than per material, (Just batch cubes of x*y parts) While all parts outside the cam frustrum can be correctly cullled then
Ah I think I get it. I generate the atlas during the build, and distribute the atlas only with the game, because the atlas wont change. Then I just need to make sure that the geometries use the correct texture coordinates.
exactly the only thing done at realtime is the batching with the batch geometry class, since the leve does not exist before. However from my tests the batching is really fast. (In a simple test with 75k cubes it needed less than 50ms)