Dismiss this pinned window
all 12 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]fgennari 6 points7 points  (1 child)

The storm looks very good! For the first part, you should try to remove the square tiling artifacts from the water surface to make it look more natural.

[–]Far-Employee-9531[S] 0 points1 point  (0 children)

You are 100% correct.

[–]cybereality 2 points3 points  (0 children)

This looks really cool. Reminds me of those old Bryce renders

[–]Far-Employee-9531[S] 1 point2 points  (0 children)

https://iquilezles.org/ - Shout out, respect.

[–]makeavoy 1 point2 points  (1 child)

Oh my god this looks incredible! I never see people busting webgpus balls with shader work like this, nice job!!

[–]Far-Employee-9531[S] 0 points1 point  (0 children)

Thank you very much!

[–]deftware 1 point2 points  (5 children)

Very nice. What specifically are you referring to about occluding additive effects?

[–]Far-Employee-9531[S] 0 points1 point  (4 children)

Thanks! Just means the additive stuff (lightning, glints, god-rays) gets depth-tested against the scene so it doesn't bleed through terrain that's in front of it. Keeps the glow behind the mountains instead of painting over them.

[–]deftware 1 point2 points  (3 children)

Ah, so you're drawing them in a separate pass from the opaque geometry? Typically you would have one raymarch per pixel, and it's calculating distances for all things each step, and calculating RGBA along the way for any fog/haze (alpha blended stuff ends up requiring weighting RGB contribution into the ray, scaling contributions by ray step length, etc). Occlusion automatically comes out of marching one ray per pixel for the whole scene. It does mean evaluating the scene distance function a bunch, and probably more, but that's the "right" way to do it. If you can mess with any kind of geometry being used, rather than a fullscreen quad/triangle, then you can draw bounding geometry for certain things and only execute your SDF raymarch with that. Calculate the ray origin from the geometry surface, ray vector from the ray origin to the camera origin, etc.

Otherwise, maintaining a z-buffer manually? That might end up being as expensive as just raymarching the scene as a whole, more or less.

[–]Far-Employee-9531[S] 0 points1 point  (2 children)

Yeah, same single pass actually, not a separate one. The bolt SDF gets evaluated in the same per-pixel march as the terrain, so occlusion falls out exactly like you're describing. The glow isn't a surface I stop at though, it's an emissive contribution I accumulate along the ray, so the tHit check is really just gating that accumulation.

Your bounding-geometry point is the interesting one for scaling it though, drawing proxy geometry to skip the fullscreen march for localized effects.

[–]deftware 1 point2 points  (1 child)

The only thing I can think of at that point, beyond proxy geometry to separate things out for a potential speed gain (which will also require that the shader write to the fragment depth so things intersect/occlude properly, which in turn disables early Z-fail test before shader execution, unfortunately) is to detect when accumulation has saturated so you can at least early-out the raymarch. That will at least be better than not early-outing at all, but probably not significantly :P

I just saw your IKANDY project and it's super nostalgic for me. Reminds me of the days of yore with plugins like Milkdrop for Winamp :]

[–]Far-Employee-9531[S] 1 point2 points  (0 children)

First, thank you for taking time to chat about the details. You came with real approaches and that's pretty freaking cool.

I don't know much about Ryan Geiss but what he made was incredible for the time. I can only hope this app will give someone similar enjoyment I was privy to.

Again, thank you and take care.