expenses.bsky.social

Great, thanks for the info! I suspected it was done by hand.

I'm trying to build a similar model but I haven't found many leads on generating the spiral arms correctly outside of downloading a bunch of Gaia data and mass processing it somehow. Any suggestions? :)

@drkay.gay Dr Kay, hi, I watched a presentation you did for the space game and I'm curious about how these luminosity and dust images were created.

Cool tattoo ideas:

- Satoshi's private key
- A proof that P != NP
- Instructions on how to build a faster than light warp drive
- Algebraic solution to Kepler's equation
- Chemical structure of a non-neutotoxic empathogenic drug

I've been working on a high quality GPU voxelizer recently

expenses.github.io/voxviewer-wa... I've completed the switch to 64-trees, changed to a sponza model and added metallic/roughness as material settings.

File sizes take a slight hit. This model is 12.7mb as a zstd-compressed array, 16.2mb as a SVO DAG in the previous implementation and 23.4mb as a 64-tree. Leaf data deduplicates easily and is about 2mb here. The rest is for the node storage which is harder to compress.

Switching to 64-trees has worked pretty well so far. The ray tracing algorithm from dubiousconst282.github.io/2024/10/03/v... seems to be quite a lot faster, and scales better to larger scenes (500^3 here).

Okay, latest version is up!

Okay, I got it rendering a proper model. Performance on my laptop with a max bounce count of 2 (max 3 normal rays + 3 shadow rays). Not sure how best to go about profiling things, but I'll give amd's GPU profiler a go

And that's good though for materials and small scenes. I could use uint textures for larger scenes.

I'd have to use a full screen triangle instead of the compute shader, but I'm already doing one of those because your can't write directly to the framebuffer in a compute shader. The lack of (unlimited size) storage buffers would be more of an issue, but webgl2 gives you 64k for uniform buffers

I'm in a slightly awkward position where WebGPU feels so limiting that restricting myself even further but by using webgl2 wouldn't be that much of a stretch...

You can modify materials now! Tonemapping is fixed. There's an issue where if you set the emission factor super high and leave samples to accumulate, the result starts to look a little funky as the 16-bit floating point buffer starts to loose precision. Switching to a 32-bit buffer would fix this.

expenses.github.io/voxviewer-wa... I've fixed the lighting, added emissive materials and basic tonemapping. Think I should be using a slightly different sampler for the tonemapping. I'll fix that later!

expenses.github.io/voxviewer-wa... now with pathtracing! The shadow banding issue seems to have been solved - think it was an issue with floating point errors accumulating? I think there might be issues with bounces going through walls or something. But good progress regardless.

expenses.github.io/voxviewer-wa... now with soft shadows and sample accumulation! There's some banding going on at the moment, presumably because I'm using a low quality rng sampler as the standard one doesn't compile for wgsl (it uses 64-bit ints). I'll try fix this next time.

New day, new shader compilation issue 😅😅 I think I should be able to work around this fairly easily? I really want to see how far I can take this Nvidia shading & sampling code. Multiple importance sampling would be nice to have, so stuff like environment maps can be quickly integrated

Falcor/Source/Falcor/Rendering/Materials/BSDFs/DisneyDiffuseBRDF.slang at 9dc819c162b2070335c65060436041690b7937f8 · NVIDIAGameWorks/Falcor Real-Time Rendering Framework. Contribute to NVIDIAGameWorks/Falcor development by creating an account on GitHub.

github.com/NVIDIAGameWo... oh sick, Nvidia has a bunch of nicely parameterized BXDFs here that I should just be able to import into my slang code.

Oh, vec3<bool> & vec3<bool> works. Maybe it's a naga issue then?

T_T ran into a shader inconsistency problem. wgpu supports vec3<bool> && vec3<bool> but Chromium/dawn doesn't.

expenses.github.io/voxviewer-wa... demo as promised. There's not much functionality so far, but you can adjust the lighting and move the camera around by dragging. Requires a browser with webgpu enabled (just displays a white screen without one).

In my case, I mostly want read-write storage buffers so I can have an accumulation buffer for raytracing. At the moment I'd have to have two buffers and do a texture sample from one and a write into the other.

WebGPU continues to be problematic in terms of it's feature set. The thing I've run into today is that you can't have read-write storage textures unless a specific extension is enabled, and this extension seems to only be in chrome currently, and as it's not in Firefox, it's not in wgpu.

Progress on a web voxel renderer is coming along well. I've had to ditch bevy as it was making things way too complicated and wasn't providing many benefits on the rendering side (I'll have to write my own http fetch asset loader and post processing passes but that's NBD). Demo tomorrow hopefully?

It's really weird that shader compilers and optimizers still can't precompute normalizing a constant vector.

Nice, the shadertoy code ran through slang more or less works without any logic (these were a few compilation problems) fixes.

Let's see how much of this I get done haha. At least 50% would be a success in my book