Development Blog

Nice example here:

Here's the indirect lighting isolated.

Higher resolution voxels look cooler.

I turbo becoming a voxel engine? I'm confused by all the voxel stuff.

16 minutes ago, Rick said:

I turbo becoming a voxel engine? I'm confused by all the voxel stuff.

It's used for real-time GI calculations. I'm going to take this 3D texture and use it in the regular rendering to lookup the indirect lighting component. The voxels are just so you can see what's going on.

The high resolution scene look awesome.  Is that all from a single point light?

yes

I am pretty confused about what to do with the texture allocation.

It's best to have six lighting values for each voxel, one for each direction. I suppose you could drop this down to four that are all 129.5 degrees apart, with less accuracy.

We want at least three voxel grids cascading out around the camera.

That means 18 textures, and I am only counting on support for 16 textures, total!

Since we are doing a depth pre-pass, I suppose we could calculate GI in the same pass and write it into a color texture, at the cost of adding a fragment shader (the pre-pass shader doesn't have one right now).

Or we could make a rule that says GI requires 32 textures. Since only 16 is guaranteed that means we definitely need some backup solution for indirect lighting (probably light probes like we use now).

Or we could store just one GI value per voxel, which means the cone step tracing needs to be performed per-pixel in the main pass. Or maybe in a downsampled buffer afterwards.

There are a lot of different ways to do this! Unlike all the academic examples out there, I am required to actually make a good working commercial product that runs fast, so I am pretty much on my own to determine the best approach. Literally no one to date has made a commercial version that includes specular reflections.

If you were to make a rule that GI requires 32 textures, does it drastically change what cards the engine will work on?  I'm not sure how 16 can be guaranteed and not any more.  Is it a memory issue?

Are there other ways to store and manipulate data on the GPU that doesn't use texture slots?  Like Buffer Objects or something...?

Quote

It's best to have six lighting values for each voxel, one for each direction. I suppose you could drop this down to four that are all 129.5 degrees apart, with less accuracy.

Maybe you could bring it down to four to keep it within limits but have the option to use more if the end user wants too use up to 32?  Maybe..

It's a conflict between memory consumption, quality, and speed. This is one of those times when it is nice to have an overarching design goal. In our case, we care about speed, particularly on high-end GPUs at high-frequency displays.

By eliminating the cone step tracing in the final pass and just using six 3D texture lookups, I can make the actual rendering cost of this neglible. It looks bad without six separate directional values. So that really does require 18 256x256x256 RGBA textures(!), equaling 1152 MB. In order to render that you need a full 16 slots of just GI data, so 32 texture slots are required, and you have to cut into the guaranteed texture slots and steal 2.

This gives us texture allocation something like below. You can really only have access to five textures because I need the rest:

• 0: diffuse
• 1: normal
• 2: metalness / specular
• 3: roughness / gloss
• 4: emission
• 5: Skybox
• 6: BRDF
• 7: shadow map array
• 8: cube shadow map array
• 9: decal texture array
• 10: GI voxel grid 2 -Z or probe cubemap array fallback
• 11: GI voxel grid 2 +Z
• 12: bone data
• 13: instance IDs
• 14: Light info
• 15: Entity matrices
• 16 GI voxel grid 0 -X
• 17 GI voxel grid 0 +X
• 18 GI voxel grid 0 -Y
• 19 GI voxel grid 0 +Y
• 20 GI voxel grid 0 -Z
• 21 GI voxel grid 0 +Z
• 22 GI voxel grid 1 -X
• 23 GI voxel grid 1 +X
• 24 GI voxel grid 1 -Y
• 25 GI voxel grid 1 +Y
• 26 GI voxel grid 1 -Z
• 27 GI voxel grid 1 +Z
• 28 GI voxel grid 2 -X
• 29 GI voxel grid 2 +X
• 30 GI voxel grid 2 -Y
• 31 GI voxel grid 2 +Y

That's a lot of textures... but for great graphics at fast speeds it'll probably be worth it.  I'm not familiar with 3D textures but can you store 4 of them in one slot like what can be done with a 2D texture, and then access the appropriate one with UV coords.. or however you access 3D textures?

Side question; would GI only be useful for indoor scenes?

5 minutes ago, SpiderPig said:

That's a lot of textures... but for great graphics at fast speeds it'll probably be worth it.  I'm not familiar with 3D textures but can you store 4 of them in one slot like what can be done with a 2D texture, and then access the appropriate one with UV coords.. or however you access 3D textures?

You can pack them into an array texture, but they have to be the same size and format. So we are talking about increased complexity of the art pipeline, which I know people would not like.

Yeah I guess people can do that to the 2D textures themselves if they want too, depending on their GLSL skills.  So the 18 256x256x256 RGBA textures for GI can't be packed?  We won't need to access those will we?

7 minutes ago, SpiderPig said:

Yeah I guess people can do that to the 2D textures themselves if they want too, depending on their GLSL skills.  So the 18 256x256x256 RGBA textures for GI can't be packed?  We won't need to access those will we?

How would you pack that? There is no 3D texture array in OpenGL, and the guaranteed max size for 3D textures is 256, so you can't be sure they can be placed in a bigger 3D texture.

Ah okay.  32 it is

Not that I know a ton about this but 256 may be guaranteed but what is the reality for most cards? I have to imagine it's higher.I mean there is the OpenGL spec but then there is the reality of the most popular gfx cards on the market.

 

Did a quick search and was seeing that in OpenGL 3 this size was 1024. What version does LE use again? 4 right? I would think that size would be larger than 256.

Page 363 here says the minimum guaranteed size is 256:

https://www.khronos.org/registry/OpenGL/specs/gl/glspec40.core.pdf