Brushing in the Far-lands | Voxel Dev Showcase

Ever since adding chunk wrapping (illusion of an infinite world), voxel interaction (brushes) has been broken. I finally got around to fixing brushes.
You'll notice that with the recent FSR2 addition, there are some pretty bad disocclusion artifacts when modifying the terrain. This'll have to be fixed
This video was previously unlisted, but I made it public because I want to be able to show more content without the necessary effort that comes with making videos with commentary. I talked about this in this video: • What has changed in my... .
The Public Codebase:
github.com/GabeRundlett/gvox_...
If you want to chat with other community members and me, join my Discord!
/ discord
My website:
www.gaberundlett.com
GPU: RTX 3070 (8GB VRAM)
CPU: AMD Ryzen 7 5800x (8 core/16 thread)
RAM: 16GB 2667 MHz DDR4

[@sugar2000galaxy]

Precision issues could be mitigated if the world move instead of the player, which will remain at origin. Since the range of values needed to be represented during rendering has been reduced, memory stored for meshes can be reduced further by using 32, 24 or even 16 bit floats to represent vertex position vectors. Although, this would be a huge timesink, and require a massive codebase refactor to implement.
I also noticed you generate chunks from bottom to top, even though the players won't see the bottom chunks from the surface. You could probably speed up chunk generation by utilising a flood fill algorithm and only generate visible chunks (from the player's POV). You could cache height maps to be used if more than 1 cubic chunk in a "chunk column" is being generated at the same time.
But what you're achieving now is already really cool! I especially like the per-voxel normal maps you've implemented. Keep up the good work!

[@GabeRundlett]

Thanks Sugar2000galaxy! So it's actually the case that the world already moves instead of the player and the world has no mesh as it's raytraced in compute shaders! The imprecision comes actually from the noise-generation function, which doesn't repeat, and takes into account the massive offset. So it's actually just the generation code that causes these artifacts, not the rendering! The player position is represented by splitting the floating point component up by its integer and fractional parts, meaning the player is only ever positioned from 0 to 1 in "render world space". The chunks actually aren't generated in any specific order at all - instead elected for generation by fighting for an atomic queue on the GPU and therefore ordered by the NVIDIA warp scheduler 😅. I've been preparing for a complete (partially CPU-driven) version of the voxel world, which will be coming soon, and will actually have ordering for the chunks when generating, as well as visibility culling, and more.

[@snail-with-tea]

Usual floating point distance error I'd say if it weren't in only one direction. What happens if you move world and camera stays at (0,0,0)?

[@GabeRundlett]

So the world actually does move in a sense, as the camera is only ever positioned from 0 to 1. The generation code where I do the brush sampling is actually where these artifacts come from. The reason it's only in one direction is because as you may have noticed in the code, I set the position to be really high only in the X direction!

[@snail-with-tea]

@@GabeRundlett so this is a brush/world generation error. Does it use floating point or fixed point/int in generation? I have not yet seen an error like this, do you have any ideas of how this might be fixed or worked around? Anyway this is really cool project! Hope you are having fun with it!