wumpf / blub Goto Github PK

Right now the solver(s) just guess how long they need to run. Could compute error every couple of steps and decide if it should keep going or not - this way the performance will be adaptive to factors like turbulence, resolution and more!

maybe it's time to try temporal techniques.
I know, water is splashy and everything, how should that work out? But I reckon "still quite well" and I never tried it.
Note that we also know the motion vectors of the fluid at excruciating detail!
It could give a more unified path than fixing sampling issues one by one (like refraction,reflection, etc. .... which still needs to be looked into I suppose) and opens other possibilities for accumulating samples. Also, it makes high quality renderings easy as it provides the framework for super sampling (i.e. "just stare at every image longer, it will get better over time")

just thought I'd leave my error:

   Compiling blub v0.1.0 (/Users/ajtj/rust_projects/blub)
warning: field is never read: `sky`
  --> src/renderer/scene_renderer.rs:40:5
   |
40 |     sky: Sky,
   |     ^^^^^^^^
   |
   = note: `#[warn(dead_code)]` on by default

warning: 1 warning emitted

    Finished release [optimized] target(s) in 2m 56s
     Running `target/release/blub`
[2020-10-23T23:29:18Z INFO  blub::render_output::screen] creating screen with PhysicalSize { width: 3584, height: 2150 }
[2020-10-23T23:29:19Z WARN  naga::front::spv] Unsupported builtin 4
[2020-10-23T23:29:19Z WARN  naga::front::spv] Unknown decoration ColMajor
[2020-10-23T23:29:19Z WARN  naga::front::spv] Unknown decoration MatrixStride
[2020-10-23T23:29:19Z ERROR gfx_backend_metal::device] Error compiling the shader CompilationFailed("Compilation failed: \n\nprogram_source:33:270: error: invalid type \'long\' for attribute index expression\nkernel void main0(constant PushConstants& _51 [[buffer(0)]], constant SimulationProperties& _26 [[buffer(2)]], device ParticlePositionLlBuffer& _43 [[buffer(3)]], texture3d<uint> LinkedListDualGrid [[texture(0)]], device atomic_uint* LinkedListDualGrid_atomic [[buffer(4294967295)]], texture3d<float, access::write> MarkerVolume [[texture(1)]], uint3 gl_GlobalInvocationID [[thread_position_in_grid]])\n                                                                                                                                                                                                                                                                             ^~~~~~~~~~\n")
thread 'main' panicked at 'Compute pipeline creation error: Err(Other)', /Users/ajtj/.cargo/git/checkouts/wgpu-53e70f8674b08dd4/7ac706f/wgpu-core/src/device/mod.rs:3356:26
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Git LFS is not supplied by default by some package managers. Mention in the readme that the LSF subcommand must be installed to upload background images.

P.S.: Works fine on linux. 3-5 fps on weak GeForce MX130

Right now world coordinates are nothing particular. want them to be meters. Show some measurements. Make gravity realistic

Related to #9

this blue background gets boring. Let's load some HDR cubemap
(it's tempting to compute some athmospheric model and use that.. but need to FOCUS!)

Can water approximate double refraction (i.e. refract on entering and leaving (ignoring extra layers))?

so GPU doesn't unnecessarily run hot when we're not benchmarking. Quite annoying and unnecessary with warm weather ;)

Refraction looks a bit buggy. Should we do signed distance field marching now that we can?

SIGGRAPH 2015, Jiang et al., The Affine Particle-In-Cell Method

caught my attention for its continuous volume loss counteraction & handling of bounding conditions
https://animation.rwth-aachen.de/media/papers/66/2019-TVCG-ImplicitDensityProjection.pdf

When I was running cargo run --release, I got the error message:

error[E0597]: `desc_set` does not live long enough
    --> G:\rust\cargo_home\git\checkouts\wgpu-de6245268e4c8054\14491d9\wgpu-core\src\device\mod.rs:1792:26
     |
1792 |                     set: desc_set.raw_mut(),
     |                          ^^^^^^^^^^^^^^^^^^ borrowed value does not live long enough
...
1813 |     }
     |     -
     |     |
     |     `desc_set` dropped here while still borrowed
     |     borrow might be used here, when `write_map` is dropped and runs the `Drop` code for type `BTreeMap`
     |
     = note: values in a scope are dropped in the opposite order they are defined

For more information about this error, try `rustc --explain E0597`.
error: could not compile `wgpu-core` due to previous error

Could anybody helps me?

looks like this is easy enough to do with imgui :)

fast forward is nice, but looking at it while it's happening is even better

solids that move the water

Requirements

• realtimeish, or at least configurable to be realtime
• want to see more than one layer of fluid (typical shortcoming of screenspace methods

Things to consider:

• already have a datastructure for which particles are close to certain grid cells, can reuse that!
• good old brute force raymarching?
• extract mesh?

pressure solver runs a fixed number of iterations now. Literature (and all cpu solvers) usually compute the norm of the residual and continue or stop depending on the error.
Computing that norm is a bit expensive for my gpu solver, but it's not outrageous. Could do it all every n iterations?
Hope is to speed up/slow down dynamically, be more stable for high quality video scenarios and get a better idea of the error in general

Software version:
3f5be1e

Issue:
Panic at startup (executing in release mode) with the following error:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Decoding(DecodingError { format: Exact(Hdr), underlying: Some(RadianceHdrSignatureInvalid) })', src/renderer/background.rs:110:68

In debug mode I have this different error:

ERROR wgpu::backend::direct] wgpu error: Validation Error

    Caused by:
        In Device::create_texture
          note: label = 'Cubemap'
        Dimension X is zero

thread main panicked at Handling wgpu errors as fatal by default

System details:
OS: Arch Linux 64 bit (Kernel 5.18.16)
GCC: 12.1.1
Windows manager: i3
Hardware: NUC8I5BEH2
Rust: 1.62.1

don't need do do this on all, but for some settings it would be quite convenient. e.g. #27

have various scene settings loaded from json files

what's tweakable or not at runtime should be seen as a orthogonal problem - ideally everything is built in a way that makes easy runtime tweaking possible but let's not make this a requirement as not only is it not worth the effort, it also makes ui hard to navigate and makes easier code designs sometimes too hard

Related to #20 #9

simplifies draw/compute calls and I might need to list out less resources in the renderer structs as the bundle will keep them alive

cargo run results in the following:
The following warnings were emitted during compilation:

warning: System installed library not found. Falling back to build from source

error: failed to run custom build command for shaderc-sys v0.6.3

Caused by:
process didn't exit successfully: C:\Users\vadim\Downloads\blub-master\blub-master\target\debug\build\shaderc-sys-ad6ce452982fe3d6\build-script-build (exit code: 101)
--- stdout
cargo:warning=System installed library not found. Falling back to build from source

--- stderr
thread 'main' panicked at '

couldn't find required command: "cmake"

', C:\Users\vadim.cargo\registry\src\github.com-1ecc6299db9ec823\shaderc-sys-0.6.3\build\cmd_finder.rs:50:13
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed

Working on APIC showed that it's not always clear when something was implemented correctly. Even right now I'm not entirely sure if my APIC implementation is entirely correct.
Adding visualizations will at the very least improve confidence.

• velocity volume
• divergence
• (pseudo-)pressure
• volume confines

Let's do #10 first ofc

of some sorts because it makes everything so much more fun:

• apply force
• add/remove fluid
• ?

right now screen capture waits for all gpu work to be finished
need to grab buffer asynchronously
probably want to look into having faster image encode as well for fluid video capture

As an alternative to queue.write_buffer. Could be more efficient (probably doesn't matter) and nicer to use.

expecting higher fidelity and faster gradients
velocity transfer expected to be slower (ideas?)
should be faster overall

need to confirm or disprove all of the above

There's plenty of data that wants caching for fast startup (and thus fast iteration!)
Should introduce a more intelligent/unified caching scheme that allows automatically removing outdated cache files.

Uses so far:

• compiled shaders
• signed distance fields
• hdr cubemap

should have a subfolder in a .cache folder for each of those. Instead of file hashing, just always rely on file modified date (good enough!). Evict old objects on cache miss

want to be able to see things in slow motion or speed up
a bit nasty to express the simulation vs rendered time thing there again, but essentially it's just the "renderered time" clock go faster and hope that simulated time keeps up!

that is things both out of Screen.rs (recording logic) and main.rs (bookkeeping)

could lead to much better surfaces

probably just something like "run simulation as fast as possible to t=x", then write out screenshot and timing for that.
Timer queries are not available in WebGPU as of writing.

Real/existing benchmark frameworks like criterion could be used but are a bit of a missfit because we need more gpu syncing then

Various sources, old and new, claim that on Nvidia hardware 3D textures are actually 2d slices!
http://www-ppl.ist.osaka-u.ac.jp/research/papers/201405_sugimoto_pc.pdf
https://www.sciencedirect.com/science/article/pii/S2468502X1730027X#fig1
https://forum.unity.com/threads/improving-performance-of-3d-textures-using-texture-arrays.725384/#post-4849571
For Intel this is directly documented
https://www.x.org/docs/intel/BYT/intel_os_gfx_prm_vol5_-_memory_views.pdf
Wasn't able to find anything on AMD, but there is sources implying the layered nature
"Two bilinear fetches are required when sampling from a volume texture with bilinear
filtering"

It stands to reason that making the layering explicit by using 2d texture arrays there should be some room for optimization!

I just git cloned this and tried to run cargo run --release

blub » cargo run --release
    Updating git repository `https://github.com/wumpf/wgpu.git`
error: failed to resolve patches for `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to load source for dependency `wgpu`

Caused by:
  Unable to update https://github.com/wumpf/wgpu.git?rev=4ada8587e5eb0bb67599f1400b68b137f3e3d070#4ada8587

Caused by:
  object not found - no match for id (4ada8587e5eb0bb67599f1400b68b137f3e3d070); class=Odb (9); code=NotFound (-3)
blub »

grid chunks that are not fixed in space. Some extensive work here:
Eurographics 2018, Wu et al., Fast Fluid Simulations with Sparse Volumes on the GPU
(probably want something easier, but gotta read up at least!)

Looks like there's some things in the shaders that have trouble being converted to MSL!