I am making a puzzler game based on blocks, so I suppose you could call it a voxel engine of sorts but that’s not really what I’m shooting for.
I have a problem with my rendering, when I do a normal level with many blocks I get 60 fps tops and I have a pretty good computer. However on a level with 81 blocks I get ~200. Yes, I am rendering Boxes (Don’t kill me please). I have ~44k triangles in the regular level with ~80k vertices and ~35 objects.
I’m using a BatchedNode so that I can edit the terrain easier. Here is a screenshot of the game with the stats:
Not using a texture atlas, I only have 2 textures, one for the ball and one for the blocks. However I am using the electricity effect from shaderblow. Would it help at all?
Since I am not making an actual voxel engine I don’t have any Chunks or anything like that. Any given level will be at most 60x60. Should I go and make a faces thing to only render visible faces? If so, how hard is it and what steps should I take?
Thanks a lot for any help guys, it’s really appreciated.
If you have a pretty good card then your FPS should be much better than that based on the stats shown. Try it with the regular lighting shader (or even Unshaded) to see if this is where your performance is going.
Basically, start temporarily removing stuff until you can figure out where your performance is going. If you have physics or another potentially expensive update loop then that might be the first thing to try turning off. If you are using bullet and every one of those boxes is a physical object then you might lose a lot of performance there, for example.
Or… run your app in the profiler.
Also, what graphics card are you using and what AppSettings paramters were you using in that pic?
It’s the physics for sure then. I’ll disable that real fast and come back to show performance. Any way to batch them together in a similar fashion to the BatchNode?
I have a Radeon HD 7670m on Ubuntu using the fglrx proprietary drivers.
EDIT:
Disabling physics did nothing…
I called setEnabled to false and removed all of the calls to main.getBulletAppState. Would that do it or would I have to not create the rigidbodycontrols?
EDIT 2:
My BlockSuper class extends RigidBodyControl so to get rid of them is to get rid of the blocks. Is it a mistake to extend RBC?
EDIT 3:
Setting the material to unshaded does nothing either. This is very suspicious.
EDIT 4:
Apparently com.bulletphysics.collision.broadphase.assortedletters takes up 20% of the objects allocated and 9.5% of the bytes allocated.
@Slyth said:
It's the physics for sure then. I'll disable that real fast and come back to show performance. Any way to batch them together in a similar fashion to the BatchNode?
I have a Radeon HD 7670m on Ubuntu using the fglrx proprietary drivers.
EDIT:
Disabling physics did nothing…
I called setEnabled to false and removed all of the calls to main.getBulletAppState. Would that do it or would I have to not create the rigidbodycontrols?
EDIT 2:
My BlockSuper class extends RigidBodyControl so to get rid of them is to get rid of the blocks. Is it a mistake to extend RBC?
EDIT 3:
Setting the material to unshaded does nothing either. This is very suspicious.
EDIT 4:
Apparently com.bulletphysics.collision.broadphase.assortedletters takes up 20% of the objects allocated and 9.5% of the bytes allocated.
Ubuntu has a bug with catalyst reducing everything to a crawling halt (at least for me and a few others), thas why i switched distros with 13.10.
Btw if ubuntu were more uptodate/dev you could test the new mesa drivers, they are nearly equal in performance now and don’t create such a ton of problems. Also they are more rigid with shader compilation, so for being a dev this is good.
Just a s a test dual boot into something else and run it there.
@pspeed said:
With these settings:
newSetting.setVSync(true);
newSetting.setFrequency(60);
…it’s strange they you ever see more then 60 FPS.
setFrequency(0) as you don’t need to set the frequency.
setVSync(false) to test FPS performance.
Okay now I’m pretty freaked out… Disabling that did nothing either, still a constant 60-65. I started to think that my hardware is limiting it, but when I disabled those settings on the 9x9 test level it went to up to 200 like it did with those enabled. What the heck? So I suppose it’s a problem with my drivers or something.
@Empire Phoenix said:
Ubuntu has a bug with catalyst reducing everything to a crawling halt (at least for me and a few others), thas why i switched distros with 13.10.
Btw if ubuntu were more uptodate/dev you could test the new mesa drivers, they are nearly equal in performance now and don't create such a ton of problems. Also they are more rigid with shader compilation, so for being a dev this is good.
Just a s a test dual boot into something else and run it there.
I’ll check out the mesa drivers. I was planning on installing Arch/Crunchbang soon anyways.
Anyways, I would still like to know if there are any ways to improve performance with the actual game, such as the faces and stuff?
Alright I did some research on the topic and I’ve done some things. Okay, one thing, I’ve set cullhints to always and that actually seems to help a bit.
I saw many topics regarding faces, however I never saw how they actually rendered it efficiently. My thinking is this: You create a different geometry for each face and then hide some if they are not visible. That may be less triangles being rendered however there are still more Geometry objects being created. Now, you could batch them however as I’ve discovered that doesn’t exactly get rid of that problem completely. Is there a different method than this? I’ve been going from the “Custom Mesh” tutorial so I may be reading the wrong things.
Also, for lights: I have as many as 10 different point lights in my game at any given time, only one of them being dynamic, the rest static. That hits performance quite a bit, by about 10-15 fps. I’m guessing that this is because the engine has to re-render the scene for each light? If so, are there any workarounds for this or do I just have to limit the number of lights I put in my game?
I’ve heard of light baking, however I’m not loading models so I don’t see how that could be applied.
I’ve discovered that my post processing effects are quite a killer obviously. If I remove bloom, ssao, and DOF I gain about 10-20 fps. Is there any way to optomize these effects or should I somehow write some scaled down versions of them?
Also, about the physics sequential/parallel, what does that mean? I did a search and didn’t come up with anything. I suppose it has something to do with threading/multi processing?
Thanks for the help guys, it’s really appreciated.
@Slyth said:
I saw many topics regarding faces, however I never saw how they actually rendered it efficiently. My thinking is this: You create a different geometry for each face and then hide some if they are not visible. That may be less triangles being rendered however there are still more Geometry objects being created. Now, you could batch them however as I've discovered that doesn't exactly get rid of that problem completely.
You only create the visible surfaces and you create them as one big mesh of quads.
To the last part, as said, you should be having much better performance than you are so no regular tricks are going to fix the problem. We’re at the point where we’ve taken the car to the mechanic to work on the engine but all four tires are flat. No matter how much you fix the engine the car is not going to drive any faster because it’s not the engine that is broken.
Still, this algorithm is not only covered a few times there is actually a whole block world plug with source available. Essentially:
for each cell in the array
-if the cell is not empty continue
-if the cell is empty check the neighbors to see if they are empty… for each empty neighbor add a quad to the mesh
You then are only drawing the surfaces that are visible, ie: the quads between solid and empty cells.
Actually, your comment about “cull hint always” concerns me. We may have been making assumptions about the structure of your scene graph. This is something that the stats screen doesn’t show us as it only shows visible stuff.
You might want to write a little routine to traverse your scene graph from the root and dump it to the console.
My scenegraph is really simple, I just have a level node attached to my rootnode. I attach my lights and my player and my blocks to that level node. Maybe this is inefficient, I’m didn’t read anything on how it should be set up.
@pspeed said:
-if the cell is not empty continue
-if the cell is empty check the neighbors to see if they are empty... for each empty neighbor add a quad to the mesh
If the cell is empty and a cell beside it is empty why should I add a quad? I suppose you meant if the neighbour is occupied. Or that if the cell is occupied and a neighbour cell is not occupied add a quad.
My scenegraph is really simple, I just have a level node attached to my rootnode. I attach my lights and my player and my blocks to that level node. Maybe this is inefficient, I’m didn’t read anything on how it should be set up.
If the cell is empty and a cell beside it is empty why should I add a quad? I suppose you meant if the neighbour is occupied. Or that if the cell is occupied and a neighbour cell is not occupied add a quad.
What was wrong with the cull hint always comment?
Yeah, I mistyped.
re: your scene graph, so you only have like four objects in the root node or do you have 100s of objects with cull hint played with. What about when you batched?
From this point you may have to struggle on your own unless you can provide more info or make a simple test case illustrating the issue.
@pspeed i have an other approach to build my block world : i have a collection of face, and it’s a “xor” collection. When i add a face to the collection, if a face is already here (i don’t take into account the direction of the face), then i remove the “face already here” from the collection instead of adding the new one. Things are a bit different when you remove a cube, as you need to be able to question adjacents cubes.
About performances : you’ll go nowhere with a “one quad=one geometry” approach. You need to create one and only one mesh (per chunk if it’s an open world. If it’s only a “small” level you can skip the “chunk” part).
For the texture, i don’t think that a texture atlas is a good idea (yeah, kill me pspeed). Instead of that, you can use normals texture and don’t use quad. You can replace big rectangle of quads that share the same texture with only one quad and cheat with the texture coordinate.
This is really a huge boost for the number of quads when you have large uniform areas (and you have this kind of areas in a puzzle game). Hey, sometimes you even don’t need textures, you can use colors .
It’s what my bloxxl lib does.
However, everything you’ll do about this is pretty pointless in 99% of case. For a puzzle game, except if you want to have some dynamically generated level you’ll have better results with a real 3D software.
Voxel are interesting only for big and automatically generated and modifiable worlds.
@bubuche said:
@pspeed i have an other approach to build my block world : i have a collection of face, and it's a "xor" collection. When i add a face to the collection, if a face is already here (i don't take into account the direction of the face), then i remove the "face already here" from the collection instead of adding the new one. Things are a bit different when you remove a cube, as you need to be able to question adjacents cubes.
Seems to me those adds and removes would be more expensive than a simple neighbor check. Also, in a world with multiple block types you will need to look at the cell to determine which face to use anyway… but I’m glad it’s working for you.
@bubuche said:
@pspeed i have an other approach to build my block world : i have a collection of face, and it's a "xor" collection. When i add a face to the collection, if a face is already here (i don't take into account the direction of the face), then i remove the "face already here" from the collection instead of adding the new one. Things are a bit different when you remove a cube, as you need to be able to question adjacents cubes.
About performances : you’ll go nowhere with a “one quad=one geometry” approach. You need to create one and only one mesh (per chunk if it’s an open world. If it’s only a “small” level you can skip the “chunk” part).
For the texture, i don’t think that a texture atlas is a good idea (yeah, kill me pspeed). Instead of that, you can use normals texture and don’t use quad. You can replace big rectangle of quads that share the same texture with only one quad and cheat with the texture coordinate.
This is really a huge boost for the number of quads when you have large uniform areas (and you have this kind of areas in a puzzle game). Hey, sometimes you even don’t need textures, you can use colors .
It’s what my bloxxl lib does.
However, everything you’ll do about this is pretty pointless in 99% of case. For a puzzle game, except if you want to have some dynamically generated level you’ll have better results with a real 3D software.
Voxel are interesting only for big and automatically generated and modifiable worlds.
You can use this combined with a texturearray, as then the z coord determines the used layer, and wrapping is still possible.
