Voxels and SDF

[QuantumEntangledAndy]

WIP Voxels

This is my in progress voxel implementation.

Design

• Voxel crate
• grid and voxel .rs hold the generic design of the voxel, it is kept separate from its potential uses
  • Has two values per voxel one for density and another for material ID
    • These are stored in the 3D texture at the R and G channels
• sdf/* holds components to compute the SDF of the voxel and render that SDF

Future Additions

• Add a marching_cubes/* to compute the marching cubes representation

[QuantumEntangledAndy]

Thought I'd post an update to show how it is currently working.

Currently

• Voxels are converted to a distance field using the jump flood algorithm
• Distance fields are rendered directly using sphere tracing
• Soft Shadows are calculated
• Ambient occulsion is also calculated

Not yet

• Materials and textures

Changes to Core

Here are some of the changes to core that I added to get everything working

• Required changes
  • Add Texture3D and its bindings
  • Add TextureArray and its bindings
  • Use correct sample methods when binding integer textures
• Optional changes
  • Add MAP buffer for reading gpu buffers to the CPU
  • Add copy methods for copying a texture to a buffer on the gpu
    • Combined with the MAP buffer it makes it possible to read textures from the gpu (I used this for debugging)

Video

(Jerkiness is mostly due to how I am capturing the video)

voxel_sdf.mp4

[voxelias]

I can not compile it with latest rust:

error[E0658]: destructuring assignments are unstable
   --> dotrix_voxel/src/sdf/jump_flood.rs:379:48
    |
379 |                     (ping_buffer, pong_buffer) = (pong_buffer, ping_buffer);
    |                     -------------------------- ^
    |                     |
    |                     cannot assign to this expression
    |
    = note: see issue #71126 <https://github.com/rust-lang/rust/issues/71126> for more information

[QuantumEntangledAndy]

I can not compile it with latest rust:

error[E0658]: destructuring assignments are unstable
   --> dotrix_voxel/src/sdf/jump_flood.rs:379:48
    |
379 |                     (ping_buffer, pong_buffer) = (pong_buffer, ping_buffer);
    |                     -------------------------- ^
    |                     |
    |                     cannot assign to this expression
    |
    = note: see issue #71126 <https://github.com/rust-lang/rust/issues/71126> for more information

Hmm I thought this was now in stable with the merge of this rust-lang/rust#90521

Perhaps I misunderstood. I can probably do it with a three way swap instead but it's not as pretty

[QuantumEntangledAndy]

Destructuring assignments were stabalized on 15 Dec 2021 so perhaps we should bump up our version of stable rust

[QuantumEntangledAndy]

Just to confirm I updated my rust with rustup to current stable stable-x86_64-apple-darwin unchanged - rustc 1.59.0 (9d1b2106e 2022-02-23) and it compiles and runs fine

[voxelias]

Yeah, I had a default setting to 1.57. But now It panics on linux with Intel Iris XE card.

MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0

Voxels: [[[0, 0, 1], [1, 1, 1], [1, 1, 0]], [[1, 1, 1], [0, 0, 0], [0, 0, 0]], [[0, 0, 0], [1, 1, 1], [1, 0, 0]]]
Compute Seed
Compute JumpFlood: n=12, k=8
Compute JumpFlood: n=12, k=4
Compute JumpFlood: n=12, k=2
Compute JumpFlood: n=12, k=1
Compute JumpFlood: n=12, k=1
Compute JumpFlood: n=12, k=2
Compute JumpFlood: n=12, k=4
Compute JumpFlood: n=12, k=8
Compute DF
thread 'main' panicked at 'not implemented', /home/elias/.cargo/registry/src/github.com-1ecc6299db9ec823/naga-0.8.0/src/back/spv/block.rs:347:30
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[QuantumEntangledAndy]

Interesting it is panicing in naga, might need to see the backtrace to find out what is not implemented.

[QuantumEntangledAndy]

spv/block.rs around line 347 is this

crate::BinaryOperator::Add => match *left_ty_inner {
    crate::TypeInner::Scalar { kind, .. }
    | crate::TypeInner::Vector { kind, .. } => match kind {
        crate::ScalarKind::Float => spirv::Op::FAdd,
        _ => spirv::Op::IAdd,
    },
    _ => unimplemented!(),
}

Apparently one of the add operations in the shader is not supported, perhaps something is more relaxed on metal when not converting to spv. Do you know which shader file this is? I can try and run naga-cli to cross-compile to spv and trace it down that way.

[voxelias]

Sorry for long response. Too many things happens around...
If we want to merge it, it should be rebased. There were many changes in rendering part already.

I still don't have full understanding of the algorithm, but I like the simplicity of use.

[voxelias]

[question]
Will it react on change of the grid in runtime?

[QuantumEntangledAndy]

Not yet but it should not be hard to implement. All we need to do is delete the sdf texture and seed texture when changes occur.

It is setup to recalculate them when they are missing.

[QuantumEntangledAndy]

Live reload is now working checkout the randomize button in the demo

[QuantumEntangledAndy]

Yeah I understand I really want to work on this more too but I haven't the time either.

The algorithm at its core is:

• March a ray from the camera for each pixel
• use the sdf to estimate how far to march the ray in each iteration
• stop marching when we hit a surface then Color in the pixel with the point the ray hit

Additional algorithms:

Shadows

• From each point found from the ray march
• march a new ray towards each light.
• If we hit an object before the light then we are in shadow
• if we almost hit an object before a light we are in partial shadow (pure crisp shadows only happen in space because of the way light diffuse through air)

Ambient occlusions

• From the point a ray hits
• march n more rays in a hemisphere from the contact point
• if we hit (or come close) to another object we are occluded

[QuantumEntangledAndy]

Here is it with materials now :)

material_voxel.mp4

[voxelias]

So cool! Have you though about how this functionality can be used for terrain spitted into chunks with loading/unloading?
Meanwhile I've extended Texture module a bit and added possibility to render image and depth buffer to textures in #161. As a result I plan to implement shadows there.

[QuantumEntangledAndy]

Yes I'm going to optimise this as best I can. (Will probably use that render to texture to render shadows and ao in a different pass) Then I'll doing some terrain with it.

There are some bigger hurdles with terrains as the render speed decreases the more rays need to be marched and terrain takes up the whole screen.

When that's working I plan to take on dynamic clouds you can do some great looking clouds with volumetric rendering techniques.