[Vulkan Dynamic Rendering]

That's what the final effect looks like. Something like that, probably a bit better.

My initial implementation used a volume texture and lately I've been moving it into a sparse voxel octree. This uses much less memory and should provide faster performance. It's hard to implement, so my screenshots probably look like they are taking a step backwards, but the final result will be better than the earlier work.

[Vulkan Dynamic Rendering]

@WhoLebVoxels are only being used for lighting. Any voxellization you see in screenshots is just to visualize the data so I can see and show what is going on.

[Direct Lighting with Sparse Voxel Octrees]

I expect to have several octrees around the camera, each one twice the dimensions of the previous. So there will probably be a limited shadow range, but how that compares to CSM I don't know yet.

[Direct Lighting with Sparse Voxel Octrees]

Looks interesting when resolution is higher.

[Direct Lighting with Sparse Voxel Octrees]

And here it is with the lighting taken into account. Shadows are blocky and low-res, but that's fine at this point. This is the equivalent to using a low-res shadow map with no filtering.

[Direct Lighting with Sparse Voxel Octrees]

Here you can see the normal geometry with texture combined with shadow. There's no actual lighting, just full-bright or black:

[Direct Lighting with Sparse Voxel Octrees]

@klepto2This will make everyone's life a lot easier:
https://www.gamingonlinux.com/2021/11/the-khronos-group-officially-announces-the-dynamic-rendering-extension-for-vulkan/

The VK_KHR_dynamic_rendering extension allows me to get rid of render passes, so I don't have to know in advance the exact format of a texture attached to a texture buffer.

[Direct Lighting with Sparse Voxel Octrees]

 

[Sparse Voxel Octrees]

Thin walls can be a problem, but the same is true with shadow maps. Light leaks can and do happen with the GI calculation, but I've got a good balance of settings that is nearly perfect.

The hardest thing to do is very dark interiors with bright outdoor lights. The buildings from the Zone are actually perfect for testing, because they have a lot of thin walls and interior spaces that see no light.

[Sparse Voxel Octrees]

I found with shadow maps, the shadows must be updated every single frame or you get a flickering effect. I think what I can do is store a small voxel octree for each dynamic object, instead of adding it into the voxel octree of static objects. The lighting shader will transform each ray to local space around the object and calculate a raycast for each object it intersects.

[Sparse Voxel Octrees]

It just occurred to me that since only the terminal nodes store color data, and have no children, the colors could be stored in the child member, bringing the data structure size down to 32 bytes. So multiply all the SVO memory consumption values by 2/3.

struct SparseVoxelOctreeTreeNode
{
	uint32_t child[2][2][2];
};

 

[Sparse Voxel Octrees]

The more empty space there is, the more memory the SVO saves. When I changed the grid resolution from 256 to 512 in the above scene, so the entire building was enclosed in the grid area, the SVO used 42 Mb, but two 512x512x512 RGBA images would require 1 Gb of VRAM.

[VXRT Progress]

The problems of image-based techniques go away, like shadow acne and adjusting the resolution of the shadow map. Transparency and particle shadows would be easy to implement. Voxel lighting will probably end up being faster, since you are only calculating shadows along surfaces at a low resolution. No matter what, you distribution of lighting data is much more efficient since it is following the scene surfaces instead of rendering to an image and then gathering pixels from that image.

Right now I am storing all voxels in a DXT5 compressed texture. I need to create an octree structure and send that to the GPU instead. Then data size and raycasts would be very efficient.

I can't think of any reason not to do it this way, other than it is hard to implement. Moving objects will be a little tricky because I am not sure how fast the polygon-to-voxel step will be.

[VXRT Progress]

The funny thing is that if we have voxel shadow data,  then we don't actually need shadow maps. This shot is using voxels for shadows, and is not using the shadow maps.

[VXRT Progress]

In the shot above of Leadwerks, I could have made a probe volume and it would look okay, but the problem is they have to be made by hand so in most development shots they aren't present.

[VXRT Progress]

[VXRT Progress]

Here's a nice comparison.

Leadwerks:

Ultra:

[VXRT Progress]

Very shiny metal:

[VXRT Progress]

Anything metal will look amazing:

[VXRT Progress]

It's getting there....

Notice the interior is much darker than the shaded exterior walls.

[SALVATIONLAND is coming! (early access) 12/28/21]

The big question is, will there be Chosen One cola?

[SALVATIONLAND is coming! (early access) 12/28/21]

здесь много русских пользователей. Меня это устраивает. 

[Editor Scripting API]

Here I relocated the console into a new tab in the side panel:

[Editor Scripting API]

If you want to play a funny joke on someone, tell them to run this script:

function f()
Notify("You cannot close the program!")
return false --cancels the event
end

ListenEvent(EVENT_WINDOWCLOSE,editor.mainwindow,f)

You can even paste it in all as one hilarious line:

function f() Notify("You cannot close the program!") return false end ListenEvent(EVENT_WINDOWCLOSE,editor.mainwindow,f)

Your coworkers will love it!

[Editor Scripting API]

Here is a simple example that adds new functionality:

function myfunc() Notify("HI!") end
ListenEvent(EVENT_WINDOWCLOSE,editor.mainwindow,myfunc)

When you close the window a message box is shown.

So you can actually code new features into the editor, as you are using the editor.