Right now the voxelization algorithm operates on the CPU and the resulting texture is upload to the GPU.
This makes it fast on low-end GPUs because the texture is only updated if light source changes (involving a transfer between GPU and CPU).
What I'm proposing is to implement a voxelization algorithm on the GPU. It is actually simpler to do so than to do that on the CPU and there is no need to transfer the new 3D texture each time something changes. This would allow for the texture to be updated each frame reflecting the changes in the scene. This has few advantages:
Here is a paper on voxelization. It's based on DIrectx but GLES3 supports all the required functionalities:
https://developer.nvidia.com/content/basics-gpu-voxelization
(as you can see from the paper the algorithm is really simple)
Here is a 3D engine that uses this technology:
https://youtu.be/siui7gLxcIQ
Thoughts?
@reduz has already planned for this! If you look on the roadmap it says "make GI probes real time" which will mean a move to the GPU. Personally I am really forward looking to having more than 1 bounce, as it will make voxel reflections on metallic surfaces look much better (currently you can really only see the illumination sources only). It is also very hard to get enough light into indirect areas with only 1 bounce, and have to crank up other values to compensate. Presumably this will happen for 3.1 or 3.2 . Would also help if another dev got onboard to help reduz with rendering features, as he has done it all by himself so far!
https://github.com/godotengine/roadmap/blob/master/ROADMAP.md
Wow, 3D textures are amazing... I wonder how much memory they take.
Also the ability to make it dynamic around the viewer with LOD would allow really good-looking larger environments :)
Voxelization in real time is still very costly, even for high end GPUs.
This is something that will have to improve in the future, but definitely
not a priority now. The next step (after 3.0) is doing the voxel lighting
in GPU… as well as adding anisotropy
On Sep 18, 2017 9:55 AM, "Marc" notifications@github.com wrote:
Wow, 3D textures are amazing... I wonder how much memory they take.
Also the ability to make it dynamic around the viewer with LOD would allow
really good-looking larger environments :) (thought maybe depending on the
world, you would prefer higher resolution horizontally than vertically)—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/11364#issuecomment-330210563,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z26945Xu2rpJlOOLD4ibE_uV5MTbxks5sjmhNgaJpZM4PaOeK
.
Yeah that's pretty high-end^^ (voxels are future! :p)
The Armory dev is doing some very cool things with voxel tech in his engine. In addition to voxel GI he has AO, shadows and even refraction working with voxels. He also has temporal AA and signed distance fields shadows. We need to entice him over to help with Godot :)
http://forums.armory3d.org/t/build-12-is-out/424
https://github.com/armory3d/armory
The work done in Armory is great, but checking their code, its very high end oriented. Keep in mind Godot has to focus on on working and achieving the best quality possible in the low end.. so we cant just go all out implementing the most complex effects just for those with high en hardware.
Getting the best out of the quality/performace tradeoff is where the real challenge of making a renderer is..
Is the voxel AO or shadows viable for your vxgi solution? One of the main problems with the current GI I am having is strange occlusion-like dark patches on floors/wall and ceilings that are hard to hide. Can hide them to some extent using the 2 bias controls. Not sure if more than 1 bounce will solve the problem or not?
That is why I thought that having the vxgi calculate AO and shadows along with the GI could potentially be very useful. Though the voxel resolution might have to be crazy high to get a usably clean result.
I wonder how costly the voxelization of a cube around the player would be. The problem is that right now GI can't be easily applied to larger scenes. I'll try to compile that engine and see how it performs to have a better idea.
Work on this has started :slightly_smiling_face:
Added in 4.0 so closing the issue. :)
Most helpful comment
Work on this has started :slightly_smiling_face:
https://twitter.com/reduzio/status/1179355190555807745