itch.io

I need to dig back into it.  I started feeling burnt out, so I took a break.  Conceptually, I think I've got some of cone traced GI figured out, but not sure how correct it is...

Thank you for asking!

Thank you.

Done.  I subscribed to your channel on YouTube and am now following you on Itch.

Thank you!

The level of detail equation in cone trace lighting (this is different than voxel level of detail) will be adjustable in game settings.  Default will be set to yield best performance to light quality ratio.

I'm still working on my C++ prototype cone trace progressive frustum app (for lack of a better description) to get algorithm and math right so I don't have to struggle so much when writing the shader code based on the app's code.

Thank you!

Very cool!

These are awesome!  I loaded each one up in my voxel engine and they look great!

Thank you!

Very cool!

Thank you!

I may be able to release one or more single-player mini-advanture/quest game versions with my voxel engine in the 4th quarter of this year.  Barring anything unexpected, I'll be releasing something next year if this year doesn't happen.

https://teknologicus.itch.io/hantverkn

Micro-voxel adventure & exploration game with an open "sandbox" world.  Game play will include removing and placing blocks (made of voxels or even individual voxels), ores, item crafting, monsters and varied terrains by biome.

P.S. Sunlight intensity and color also should change at sunset and sunrise.

Thank you!

Direct sunlight definitely needs more work...  I discovered direct sunlight isn't working correctly with levels of detail (mipmaps).  I would also like to ray march light from voxel faces instead of from voxel centers for more accuracy.  Furthermore, direct sunlight doesn't take into account lighting angle of incidence between voxel face directions (normal) and sunlight direction.

Once I've addressed what can be improved with direct sunlight, I will work on cone traced global illumination.  That will both propagate sunlight indirectly as well as handle per voxel emissive lighting (and propagation of emissive lighting).

Hantverk'n

The part that changed everything is about using atomic operations to query and/or update a hash map and add voxel hits to a list of voxel hits if not already present based on hash map query.  I've implemented it in my voxel engine's ray march code and it works well to build a unique list of voxel hits (voxel world space coordinates).  I also had to use an atomic operation to add to the list to avoid race conditions.

I will have dynamic direct sunlight working soon...

Maybe the second one would be the commander of the evil triangles that arrive from outer space in their giant triangle shaped spaceship.  ;)

Thank you!

Thank you!

Hantverk'n

My understanding is that it's due to incomplete Vulkan driver implementations.  I have an old laptop that has an Intel integrated (non-discrete) GPU and when my code requests the fragment shading rate extension with logical device creation, Vulkan reports that the extension is unsupported.

P.S.  Same laptop doesn't support GLSL uint64 nor float64.

Thank you!

P.S.  Decreasing ray march compute shader workgroup size local_size_x has improved frame rates.

P.S.  I've now switched to 15-bit RGB voxel color because I noticed some time ago in procedural block generation where a noise function it uses to modulate brightness of colors was slightly shifting voxel colors.  The noise function modulates the RGB channels equally but because green had more bits (6), red (5) and blue (5) didn't have an even distribution with respect to the green channel.

Thank you!

Thank you!

These procedurally generated blocks support Hilbert Curve grooves which are scaled. In the above screen shot I'm using a scale of three, which means there are two voxels between each voxel groove. To calculate the the ideal "order" for the Hilbert Curve function based on the bounds of the block (or world selection bounds) I use the following math/code: 

int order = log2i(clampMin(pow2Ceil(divCeil(max(bounds.width(), bounds.height(), bounds.depth()), scale)), 2))

FYI, all of these nested function calls are of functions in my C++ (template) math library.

And the inverse Hilbert Curve function I wrote is based on code from here:
https://people.math.sc.edu/burkardt/cpp_src/hilbert_curve/hilbert_curve.html

Hantverk'n

Excellent!  I've been looking into using a gbuffer with the ray marching version of my compute shader...  :)

Thank you

Hantverk'n

After overhauling host/device buffer use, voxel level ambient occlusion bits generation is now down to 0.62 seconds for test scene nuke.vox

Amazing!