Vkguide 2 thread

[kind ferry]

yes i know theoretically they are all infinite i dont give a shit

[lilac oak]

Have you seen Real-Time Stochastic Light Cuts by Cem Yuksel?

you slap lights into a perfect binary tree, you coopearatively look them up, keep descending until difference in node influence is tiny and choose random light in subtree

[kind ferry]

no, but i was reading the hypehype presentation on stochastic tiled lights

[lilac oak]

thats slightly different tho

I think Hype Hype still has ranges

[kind ferry]

i kinda like the idea and seems super simple to implement, devolving lights into rng to keep a constant cost when they overlap too much

[lilac oak]

yeah but they still build clusters

or tiles

[kind ferry]

you want tiles for scalarization reasons

if every pixel has different light all your stuff cant be fully wave wide so nicely

the binary tree stuff is nice tho, i have thought of doing that instead of tiles

but it has that issue of lights not being wave wide

the bonus is of course that you stop giving a shit about tiles

pretty nifty for rays where your stuff is noncoherent to begin with

[lilac oak]

Real Time Stochastic Light Cuts use tiles too

https://www.cemyuksel.com/research/stochasticlightcuts/realtime_stochastic_lightcuts.pdf

[kind ferry]

reading

[lilac oak]

so its like every k x k pixels you traverse the Light Tree cooperatively

and 8x8 is suffient to get nice perf, but you can do 4x4 too

[lapis isle]

isn't there a thing where you have 3D tiles in depth buffer space (so I guess ndc space)

[lilac oak]

the nice thing here is that you can also do a Light Tree thats less retarded like 8-children instead of 2

[lilac oak]

thats clustered

[lapis isle]

yeah, would you not wanna do that

[lilac oak]

and you can use a subgroup cooperatively

cause every time you descend

you compute some metrics for a node

to determine if descent is worth it, or you throw a random dart at the lights in the subtree

so if you do 4x4 pixels sharing a cut

blergh

if you do 4x2

then you can have 8 invocations load 8 children

compute the metric in parallel

and also share a single stack for the traversal

[lapis isle]

worth it is a distance thing, right? if you're not raytracing can't you just return some kind of weighted average of the lights in a subtree at that point

[kind ferry]

thats the one im thinking of doing

the bonus is that it works for transparents just fine

and fogs

[lilac oak]

you can but determining the cut sucks

[kind ferry]

normal tiled looks into the depth ranges so its surface-based

most games end up doing both, or some sort of adaptive system

[lilac oak]

this is 100k lights btw

[lapis isle]

clustered forward is the one that I've had in my pile of things to check out, it seems like the best hobbyist tier realtime lighting thing you'd want

[lilac oak]

with zero ranges

[kind ferry]

where they check the depthmax of a given tile and then split the clusters accordingly

[lapis isle]

good perf without crazy data structures

[kind ferry]

to avoid the bullshit with compute and sync, i was thinking of doing cpu side

[lilac oak]

clustered is a crazy data structure

[kind ferry]

what you saying its just a 3d array 🤔

[lilac oak]

also it doesn't mix well with deferred or visbuffer

[lapis isle]

it just requires a depth pyramid though, right?

[kind ferry]

nah, thats tiled

[lilac oak]

doi you know why Clustered is good for Forward+ ?

and why Forward+ got popular

[kind ferry]

memory bandwidth usages vs deferred

and msaa

only really relevant for VR these days

[lapis isle]

probably multisampling and transparency issues right

[kind ferry]

maybe mobile too

[kind ferry]

forward plus executes shading in triangles, not in screenspace tiles, so the cluster stuff works fine

in a deferred clustered has more mismatched lights within a 8x8 tile

[lilac oak]

yeah in deferred clustered you can't just dumb-scalarize your light loads

like you can't just grab your workgroup and coalesced load your lights into groupshared

@kind ferry if you did Stochastic Light Cuts, your GI chapter could just be "render GBuffer from sunlight point of view and splat lights everywhere"

[lapis isle]

so it's like RSM?

[lilac oak]

no

but you can feed RSM into Stochastic Light Cuts

[kind ferry]

so, RSM

[lilac oak]

RSM -> VPL gen -> GPU BVH builder (just a dumb morton code sort and merge) + Game Lights -> Stochastic Light Cuts

[kind ferry]

wait what if i just do a normal bvh for the lights

[lilac oak]

you forgot KHR_Acceleration_structure for shadows between bruteforce and many lights 😛

[lilac oak]

you can, but you can't use a HW BVH

[kind ferry]

i wasnt going to

this is a tutorial

i aint going to do rays

[lilac oak]

shadow rays are simpler to teach than shadowmaps imho

[kind ferry]

that would be for another one

and im not going to be doing shadows in chapter 6

maybe, very maybe, i can slot in sunlight shadows

[lilac oak]

shadowmaps that don't suck require depth offset, slope offset, knowing not to use D32F with them or constant offsetting in geo shader, also PCF to not suck but PCF needs Grandient Shadow Mapping

and thats for basic tier Sun shadows without Acne (before you even get to CSM)

whereas good sun-shadows require just offsetting your ray origin by the geometrical normal away from the surface

[kind ferry]

there are pipeline-side offset mechanics in vulkan

i have alright shadows in my voxel game

[lapis isle]

you can also do the offsets on the receiver in the shader

[lilac oak]

not slope offsets

slope offsets you need to put in when rendering the shadowcasters

[lilac oak]

btw @kind ferry all timings are 1080p with RTX 2080 with SHADOW RAYS

[kind ferry]

fun

[lilac oak]

and I'm not sure if they used Raster+Ray-Queries or RT pipeline

[kind ferry]

ray queries for sure, they work a million times better for this sorta thing

[lilac oak]

researchers

[kind ferry]

specially on a 2080

[lilac oak]

they may have been like.. fuck rasterization

[meager flume]

Is there something for coalescing lights? If you have a city with thousands of lights 10km away each of those lights is negligible on their own, but combined they turn into considerable light pollution.

[lilac oak]

isn't picking one stochastically the correct thing ?

I mean just at random

I mean Light Cuts used to replace a whole Light Subtree by one representative light, but thats dumb

because you get correllation = aliasing

so its just better to decorellate

and grab a random light

[lapis isle]

why would you do it stochastically in realtime rendering

[lilac oak]

from the subtree

[meager flume]

Technically correct I suppose, but feels noisy. You're evaluating more or less the same integral many, many times

[lilac oak]

I don't see people testing every Shadowmap Texel for large radius PCF in realtime rendering

so thats why

[lilac oak]

if its truly more or less the same, then choosing a random integral shouldn't reveal any noise 😊

[meager flume]

No it just means you can filter a lot

Except it does change with the surface normal which can be high frequency, compared to change in position when evaluating a light 10km away

[lilac oak]

there's REgularization btw

where you roughen surfaces with high per-pixel curvature

[kind ferry]

@meager flume the rng is when you have overlaps

[lilac oak]

it reduces specular aliasing

[kind ferry]

if you have 1 light here and 10k on the other side

the first branch of the tree is going to flip to the close light at 100% rate

[lilac oak]

yeah you definitely traverse the subtree

[kind ferry]

the rng choice is when the aabbs are overlapped

if they dont overlap no rng

[lilac oak]

well actually there's also RNG because you need to pick 8 spp or whatever spp per frame

[meager flume]

Then that's biased because those 10k never get evaluated no?

[kind ferry]

why woudl you evaluate lights that are out of range

[meager flume]

What is this "range" you speak of?

[lilac oak]

no it works like this

without Light Cuts

you grab your tree

and you stochastically descend

like you don't even use a stack

you choose one child RANDOMLY

depending on some metric of how good that node is for your current shading point

so it could be as simple as taking the distance to the centroid of the subtree OBB and the surfacce area of the subtree

and picking with random value proportional to that

[meager flume]

I was responding to vblanco but yes

[lilac oak]

but most papers

have you descend all the way till you hit a leaf

which means you do K*logK(LightCount) nasty solid-angle approximation evaluations on your way down

which as you can imagine, makes the sampling quite a bit expensive

I mean you can kind-of amortize by having subgroup invocations do 1spp each indepenently and then you trade their choices and artifically get 2^N samples

but

[meager flume]

And with the light cuts you can decide it's not worth splitting the 10k lights further and pick one randomly? Still proportional to intensity I hope rather than completely uniformly.

[lilac oak]

what the Light Cut paper does

is it lets you go "fuck it" once the child nodes below a subtree root aren't that much different

and you go "fuck it"

and just pick one of the leafs in the subtree without evaluating their distances and stuff

[lilac oak]

I think you can use Alias Method

to get proportional to size and intensity

hmm actually you can also use CDF inversion

[meager flume]

I'll need to think more about it when the time comes, right now it's just a thing at the back of my mind

[lilac oak]

its just that alias is O(1)

cdf invert would be O(log(N)) due to binary search