Implement fake AO into vertex color (or variable) by raymarching distance data.

[SigmaOrionis]

AO radius would be dependent on voxel size and world size to get desired results. There should not be much raymarching steps. There should be checkbox on voxel world to disable or enable feature with few variables to linearly control radius in accordance to voxel/world (chunk) size.

[Mr4Goosey]

Might be worth having a look at how Nvidia's VXAO was done? Marching cones instead of rays through the voxel field. (Essentially the same thing, you're just marching a MIP instead of the full-res version)

[SigmaOrionis]

Might be worth having a look at how Nvidia's VXAO was done?

Or Minecraft even...

[Mr4Goosey]

The very first step for delving into this should be to determine whether it is at all possible to inject custom AO into the renderer without a source engine build. Voxel-only AO is as good as useless, so the entire implementation is pointless if a custom engine build is needed to make it work.

[SigmaOrionis]

The very first step for delving into this should be to determine whether it is at all possible to inject custom AO into the renderer without a source engine build. Voxel-only AO is as good as useless, so the entire implementation is pointless if a custom engine build is needed to make it work.

There is no need for either.

[Mr4Goosey]

What are the alternatives? A bit more elaboration would be useful?

[SigmaOrionis]

My opinion is that if Phy already implemented it at small radius at 120 fps it is feasible. If there is larger radius with same amount of sampling points with smoothing and vertex painting you don't need to delve into rendering engine. There are few techniques that come into my mind and this subject needs research as Phy already suggested. That is, for example, one of the technique comes into my mind from the top of my head is that if you use TransVoxel, you can align dome to normal and test voxels within radius if normal is occluded according to depth of those voxels, the other one is just to take radius without using normal and see how many voxels in that radius are below isosurf and normalize it. Those are just two adhoc techniques that do not need custom rendering engine. If you already have volume data, you have big advantage.

[Mr4Goosey]

The reason I'm concerned a custom engine build might be needed has nothing to do with the actual AO computation, it has to do with the fact that I believe calculating AO is utterly useless if it's only applied onto the voxel landscape, so you need some kind of overarching AO buffer so that all objects in a scene are shaded correctly - I personally wouldn't want my cave-plants to be brightly lit compared to the voxels they're placed on. The AO stuff is likely just a compute shader, no problems there, but doing that is pointless if you can't use it as proper AO. Custom Gbuffers (and other similar things) can - as far as I'm aware - only be implemented in a custom engine build.

[SigmaOrionis]

Oh, I see, I would not worry about that. The painting of surface would only enhance overall experience IMO. And even with that in mind immediately it comes to my mind that you can always sample nearest voxel of the "plant" and ambient light it.