I've skimmed the paper now, and they definitely have made some great contributions! This really fleshes out the light tree method. I'm especially pleased to see that they've accounted for non-omnidirectional lights.
I helped to mentor Petra Gospodnetić (who they also cited) when
she implemented light tree sampling in Appleseed for last year's GSOC, and in the process we figured out a couple of additional things that I didn't see mentioned in this paper (at least in my skimming).
Shading points inside light tree nodesThe first is how to handle importance weighting when shading points fall inside the volume of a light tree node. In the paper they appear to side-step this with their splitting approach, so that shading points are never inside nodes. However, you can get significantly improved results in other ways too.
In both Psychopath and Appleseed we use the projected solid angle of the cluster X it's total power to determine the importance of the that node to the given shading point. However, doing things that way leaves quite a bit of noise for scenes where the scene geometry is significantly intermixed with the lights of the scene. This is because the nodes higher up in the tree then have spatial extents that encompass the shading points, in which case the importance then simply becomes the node's total power, since the projected solid angle is equal for all points inside it. Rendering that way looks like this:

However, Petra stumbled across something really interesting: if instead of using the (constant) projected solid angle for points inside a node, you transition to an inverse square equation from the node's center, you get this:
Significantly reduced noise. It also introduces some very bright fireflies, but if you clamp the inverse square factor so it doesn't approach infinity, that eliminates the fireflies while largely preserving the reduced noise:

Neither of us are
entirely sure why this works. My theory is that it better approximates the fact that the lights under each node are generally more of a cloud than a surface. I suspect that the clamped inverse square is accidentally approximating a different function that should actually be used. But I haven't investigated what that function would be.
It's not clear to me how this would be incorporated in combination with how this paper accounts for light direction, but it would be interesting to investigate!
Tree arityIt turns out that tree arity makes a really big difference. Compare the last image above with this:

The only difference between the two images is that the previous one uses a binary tree whereas this image uses an 8-arity tree. Although the higher arity does have some performance impact (61 vs 66 seconds in this case), the reduced noise due to better sampling more than makes up for it. Increasing the arity further gives even further noise reduction.
This is also something that is somewhat addressed in the paper via their splitting method. However, their splitting process actually samples additional lights (as I gathered from skimming, at least). It would be interesting to explore using their splitting approach not for taking more samples, but instead as a kind of adaptive tree arity selection. For clusters that are far away, using binary selection is almost certainly fine. But for nearby clusters, switching to higher arity gives a much better approximation of the lights, and therefore results in better sampling.
I'm guessing (hoping?) that doing this adaptively based on the paper's splitting heuristic could give the benefits of a very high-arity tree with minimal performance impact.
One last noteIn the paper, they said about my post (and other citations) "[...]though to our knowledge no publication discusses in detail their approach to tree construction or traversal." While that is technically true, it feels a little misleading to me because
Psychopath is open source and published on github (and was at the time as well). Anyone is free to examine the code to see how it works! Granted, that isn't as convenient as a well-crafted explanation. But I wasn't hiding any details.
