[work in progess] introduce probe light

[richardmonette]

No description provided.

[donmccurdy]

Thank you for getting this started! :)

To point out one limitation, and an alternative – in this implementation, for a given light probe p_i, intensity is a function of distance / total_distance. This has effects I wouldn't necessarily expect from a light probe volume. Ignoring the small but important case where d≅0 for now, what happens with this layout:

p • • • • • • p 
• • • • • • • • 
• • • • • • • • 
• • v p p • • • 
• • • • • • • • 
• • • • • • • • 
p • • • • • • p 

• = empty
v = vertex
p = probe

Consider those center three objects, v, p₁, and p₂.

p₁ is the closest probe, and is correctly the strongest. But p₂ is directly behind p₁, and proximity does not imply similarity – there could be a wall or barrier between the two. Ideally, only p₁ and some much smaller blend of the corner probes should be applied to v.

This could be solved with @bhouston's suggestions (#6251 (comment)) for tetrahedral interpolation. I believe interpolation happens on the CPU (per-mesh, not per-vertex, presumably), and arbitrarily large numbers of light probes can be supported for large scenes.

The solution in this PR is simpler, and may be useful as a starting point. Do you have a particular use case in mind that this will solve? For approximating realtime GI in a large scene I would prefer CPU-based interpolation, but if there's a smaller step in that direction that still solves a clear use case I'm open to it.

[bhouston]

@donmccurdy I would strongly suggest against tetrahedral interpolation for now. There are always better solutions but aiming for perfect will basically kill PRs that will slowly get us to where we want. Thus I do want baby steps that may not be the perfect solution. This is one of them.

There are lots that we should do in the future, but we need these baby steps to get this into the system so others can build.

[bhouston]

@donmccurdy Oh, I see, this is light probe interpolation per pixel in the fragment. We do not want that. We want the weights to be passed in on a per mesh basis and those unified weights per mesh applied to the top SH's affecting the mesh.

I think I am partially responsible for this misunderstanding as I mentioned skinning as an analogy in another but in that analogy I was sort of referring to the whole object in light probe interpolation (one mesh is affected by the closed 4 light probes) as akin to a vertex in a skinning solution (one skinned vertex is affected by the closest 4 bones.)

Just change the interpolation to per mesh rather than per vertex for now.

If we were to do per vertex blending of light probes (which may be the case for ultra large objects, although one could just split them up) it may need to be done in a simpler fashion as you can not do a tetrahedral mesh look up per vertex on the GPU, would be super slow. I view this as an advanced feature.

[donmccurdy]

Thus I do want baby steps that may not be the perfect solution. This is one of them.

Just change the interpolation to per mesh rather than per vertex for now.

I do agree with that. Per-mesh interpolation, even with a naive interpolation method, should be a great basis to build from.

[richardmonette]

Just change the interpolation to per mesh rather than per vertex for now.

Will update 👍

[richardmonette]

This one kind of became redundant when #16223 was merged, but I did an update in #16270 which moves towards using the scene graph to track relative position of lights probes and objects.