Today, I revisited some features in Buto’s volumetric lighting system. One feature area that I wanted to extend was our support for additional lights. Although Buto does currently support additional lights, it does not support Additional Light shadows.
My current implementation for additional light support asks users to add a component to preferred Additional Lights that should be injected to the volumetric rendering pass. This component parses some lighting data, records the light in a list of nearby light records, and is shared to the GPU.
Ideally, this would all work seamlessly. You add an Additional Light, it pops into the volumetrics.
However, I observed during initial testing some time ago that the GetAdditionalLightsCount() and GetAdditionalLight() methods behaved oddly. They work normally when tapped on any object shaders. When accessed from a post-process system like Buto, the lights flicker, jump, go missing, re-appear, and so on.
At the time, I found this post on Reddit in which CustomPhase explains that the AdditionalLightsCount() and GetAdditionalLight() methods are set per-object by Unity during rendering. Hence the approach I took for the lights.
Revisiting this today, I re-encountered the same issue and thought I would make a note of it here.
For now, I plan to hold off on extending support for additional light shadows. Apart from the additional code complexity, I think most use cases can be addressed with a little level design. Apart from that, I would really rather avoid the performance cost associated with sampling as many as 8 additional lights per step per pixel per frame.
So, be warned! :) If you are writing a post-process (i.e., not object-based) shader that depends on Additional Light data, you will need to store and pass all relevant additional lighting data yourself.
