Deferred renderer

[Brutile]

Leadwerks is using a deferred renderer right?

I'm just wondering what kind of performance impact this is having, and whether it is necessary to be used for every game. I remember back when I first bought Leadwerks, I was getting 1000fps in a small scene, but it seems to be dramatically less now-a-days.

Is this something that can be made a setting, so we can use deferred rendering for graphically intense games, but turn it off for games that require high amounts of geometry?

[nick.ace]

No, that's how the renderer is built. More geometry is actually what deferred renderers are good at computing. That, and a lot of lights.

 

Deferred renders perform poorly on weak hardware because of the amount of VRAM they use. In fact, the time complexity of a deferred renderer is fairly good in comparison with forward rendering:

http://gamedevelopment.tutsplus.com/articles/forward-rendering-vs-deferred-rendering--gamedev-12342

 

Actually, on second thought, you can kind of turn off the deferred renderer, but you can't disable the render targets, so I don't think you would get any performance gain unless the lighting shader is poorly optimized.

[Brutile]

Interesting, thanks for that explanation.

[Brutile]

Would you say that 50,000 tris is a lot for a scene? I'm getting 150fps, but it just seems like it should be getting a lot more. That's even after removing the lights and using just the ambient light.

[nick.ace]

No, not at all. You could render scenes with millions of triangles provided you use a lot of instancing and are smart about it. Could you post the scene so we could take a look at it?

[Brutile]

You can try it here https://www.dropbox.com/s/tn43uw52mn11quc/Voxel_Terrain.zip?dl=0 but it's procedurally generated, so I don't have a map file you can look at. F4 will allow you to see the verts. It's using one material with a texture atlas, so it only has one draw call per model, which is 16x16 blocks.

[nick.ace]

Ok I see what you are doing. If you are using that many entities, I think you are going to have performance issues regardless. Also, I wouldn't consider 150 FPS low, especially for this type of scene. I mean, you are using a huge number of blocks and still getting that framerate. It would probably be the shadows that cause the biggest slowdown.

[Brutile]

Ok I see what you are doing. If you are using that many entities, I think you are going to have performance issues regardless. Also, I wouldn't consider 150 FPS low, especially for this type of scene. I mean, you are using a huge number of blocks and still getting that framerate. It would probably be the shadows that cause the biggest slowdown.

There are only 256 entities, and there are no shadows being drawn.

[nick.ace]

I know there aren't shadows. BTW, I don't think Minecraft does shadow rendering or lighting at all. It seems to use some sort of neighborhood analysis (kind of like SSAO) to determine the lighting, which is really cheap.

 

I thought each box was an entity until i reread your description. That means you have 256 unique entities though. That's a lot of unique entities. It's possible every frame 256 entities are coming from CPU to the GPU. You're going to run out of bandwidth at a certain point by doing that since you aren't taking advantage of instancing.

 

I might not be right on this being the issue though.

[Josh]

The speed seems fine. 256 unique meshes are going to be slower than 256 instances of the same model. I would experiment with the chunk size and see what gives optimal performance. Maybe you can even cache subchunks (like 16x16) and then merge them into larger chunks (maybe 64x64) if you want the best combination of performance and rebuild times.

 

Cool demo!

[Brutile]

I would experiment with the chunk size and see what gives optimal performance.

I did this previously. 32x32x32 seems to be the largest size without stuttering when rebuilding the chunk.

Maybe you can even cache subchunks (like 16x16) and then merge them into larger chunks (maybe 64x64) if you want the best combination of performance and rebuild times.

Is there a way to merge meshes without needing to create a whole new mesh? I know I'd probably need to recalculate the AABB, but if I could easily merge meshes and even collision shapes, that would be awesome.

Cool demo!

Thanks!

[Brutile]

My original question was due to the fact that I made a similar demo with a much bigger size (double, or even tripple) on another engine and was getting something like 2000-3000fps and there was no stuttering at all. I just felt that something was hindering the performance somehow.

[Josh]

The deferred renderer involves an initial performance hit due to rendering to the gbuffer, but stays faster as more lights and geometry are added to the scene. Normally an empty scene will start at 200-1000 FPS depending on what kind of hardware you are using.

 

Framerates of 2000-3000 are pretty much meaningless because the timer in your computer doesn't have that kind of precision.

 

Is there a way to merge meshes without needing to create a whole new mesh? I know I'd probably need to recalculate the AABB, but if I could easily merge meshes and even collision shapes, that would be awesome.

No, just use an intermediate hidden model. This is sort of an advanced optimization idea, and I wouldn't worry about it right now.