MilchRatchet
Cache points
I just saw you started implementing the cache points, super cool : )
How are you going to go about it? Strictly following what Disney is doing or with some changes of your own / making things a bit more friendly for the GPU?
I am definitely going to deviate a lot from what Disney is doing in pursuit of something that is GPU friendly.
The cache points will not directly sample lights but instead will be used to sample children of the light tree root node. This is a generalization of what Disney is doing since constructing a tree with as many children in the root node as there are lights in the scene would give you what Disney is doing. Main reason behind this is that I can keep the memory footprint of the nodes small since I will need less entries per cache point and I can easily restrict the indices to 2 bytes (limiting myself to 65k children in the light tree root node at max).
Further, instead of having multiple lists per cache point, I want to only have one list but instead I will have importance values for each axis direction.
I have no idea yet if/how I can do visibility learning, it would be cool though.
This is all just me exploring ideas for now.
Hm so this is going to use the light tree as a clustering structure to reduce the "overhead" of a cache point having all the lights in its list. Assuming the clustering isn't too imprecise (which it should be pretty good since your root node is a special case that has 128 children iirc. Or is it variable since you mention that 65k children limit?), this should give really nice savings both in time and memory.
I will have importance values for each axis direction.
The goal being to sample from the right "distribution" of the cache point depending on the orientation of the surface when doing NEE?
I have no idea yet if/how I can do visibility learning, it would be cool though.
Maybe you could accumulate visibility as Disney is doing and recompute distributions every N frames. With your root-node-children-clustering, I expect building the light distributions should be very fast so recomputing the distributions every N frame to account for the accumulated visibility information should be doable?...
As long as you don't have 5 millions cache points :D How are you going to decide on the density of the points? Shooting rays everywhere as Disney is doing and then merging similar distributions?
(which it should be pretty good since your root node is a special case that has 128 children iirc. Or is it variable since you mention that 65k children limit?)
I had used 128 so far as any more than that is not efficient with respect to the cost it incurs. With the cache points, I expect to easily be able to do, say, 2048 children or more. It could easily also be turned into a variable at that point.
Also I will follow a similar strategy to Disney in that each cache point only stores a small subset of the children, so that the sum of the importance of the subset is some very large fraction of the sum of the importance of all children.
The goal being to sample from the right "distribution" of the cache point depending on the orientation of the surface when doing NEE?
Yes. I was considering just storing "omnidirectional" importance, but I want to avoid losing sampling quality so I figured this would be a decent compromise (Disney clearly had success with using the 6 axis directions iirc).
Maybe you could accumulate visibility as Disney is doing and recompute distributions every N frames. With your root-node-children-clustering, I expect building the light distributions should be very fast so recomputing the distributions every N frame to account for the accumulated visibility information should be doable?...
As I said, I didn't actually put much thought to this yet. My main concern is memory (I will have to store direct lighting samples) and having to update such structures in a massively parallel fashion. For every cache points, there could be N>=0 samples and I need to somehow efficiently figure out which samples those are. I am sure people have tackled such problems before (since there are other learning based world space data structures) but I have never read this part of research.
As long as you don't have 5 millions cache points :D How are you going to decide on the density of the points? Shooting rays everywhere as Disney is doing and then merging similar distributions?
I don't know yet, I will have to experiment with this. Though with the much reduced memory cost, I am definitely aiming for more than 1 million cache points, possibly even 5 million if the scene requires it. I will initially just generate stratified points in world space and see how well that works. I want to avoid making the point distribution dependend on the camera as that would be ugly for interactivity.