Ok… I can accept why Epic wouldn’t want to officially support custom lighting (and lighting data isn’t available in deferred etc), but I see this as more of a case like Mesh Distance Fields (just useful static data that we can access) - isn’t the volumetric data essentially 3D texture that gets generated at build time? That would be very useful to access for all sorts of uses… and wouldn’t affect how you integrate other features… or am I underestimating the complexity of the data?
For example (ignoring for a moment the practical possibilities for optimisation or stylization) the volumetric data could be used to have moss grow on materials where it is well lit, or change the appearance of vegetation in different lighting, so it could help workflow or consistency too.
If it’s just the principle of not allowing access because it’s considered lighting data… I dunno… It’s kinda like if you hard-code-prevented users in UE3 from doing “fake lighting” with unlit materials, simply because materials “shouldn’t define lighting”… when in reality it’s just a useful thing to be able to do and probably 100% of projects did that either for optimisation or artistic reasons… you know what I mean?
I get that we could implement it ourselves too, but I love to help this engine be as generically useful as it can be. Personally I only ever suggest a feature if I think it’s useful for more than 50% of projects out there / improves the baseline possibilities in the engine without too much effort. And I just think this is one of them.
Thanks for your time!