Realtime Deferred Arealights in Internal-Prepass

Hi,

a while ago we created a WebGL-demo showing an implementation of deferred arealights, that was based on this article. If you are interested, you can check it out here.

Over the weekend I started porting the whole thing over to Unity and got a basic implementation working (see screenshots below). However, in order to integrate it into Unity, I had to abuse the #if defined (DIRECTIONAL) || defined (DIRECTIONAL_COOKIE) condition inside the Internal-PrepassLightingShader, as I couldn't figure out any other way to place custom lighting code in that shader. So right now there are basic arealights, but there are no directional lights anymore.

Is there any way to define custom light types within the Internal-Prepass? If so, how would I define what kind of proxy geometry is to be used for this custom light type? Right now the arealights are rendered as fullscreen quads (same as directional lights), but a box geometry might be more suitable.

I'd like to do something like that:

#if defined (AREA)
// area lighting code...
#endif

Is it possible at all?

Cheers

 

This may sound weird, but for now why not just replace normal spot lights with them? Honestly, who would use spotlights when you can use area lights (unless they're horrific when it comes to performance, which they shouldn't be)?

Unity's guts at that level don't seem that well exposed, at least as far as I've seen. There was some talk at the Unite conference recently (last year? the one with the Strumpy Shader Editor guy, to do with lighting) where they said something about improving Unity's lighting methods for more accesability, possibly including opening it up for (ideally / among other things) sticking SSAO into the AO pass, making it possible to have negative values for lights, etc.

Can you post up the current version of the area lights you've got going on now? You never know, maybe there's something else in this specific implementation that can half with integration.

 

Replacing spotlights is problematic, as they are rendered as cone geometries. Arealights need to be rendered as box geometries or fullscreen quads, same as directional lights. That's why I placed it into the directional lights part.

Furthermore I don't really like to replace any of Unity's light types, as this arealight implementation does have some limitations on it's own, for example it is really quite complicated to calculate shadows properly.

I didn't do any detailed measurements regarding performance, yet, but the same algorithm runs fine in WebGL/JS, so I'm guessing it will also run just fine in Unity.

I'm sure, that I can post the code once, however right now it is still quite messy and I need to clean it up a bit first.

 

Small progress.

Arealights now work together with Unity's light types. The custom code is now placed within the DIRECTIONAL_COOKIE flag inside Internal-Prepass. That means, directional lights, that have a cookie texture set, will be rendered as arealights, which is fine for me, as I don't really need directional cookies right now.

However, this is all so very hacky, and I'm still missing the possibility to pass custom parameters down to the shader such as width and height of the light.

Any ideas? Or am I completely barking up the wrong tree here?

 

Well, it's definitely the right subforum, and I like seeing the work you do.
Unfortunately there are only a few people who actively reply to ShaderLab forum threads. And I'm afraid I don't have enough experience with custom lights to help you.

So I don't know if you have enough access to integrate new light types into the existing surface shader system, instead of modding them in, or only having them for objects using a custom lightingmodel and passing parameters as material properties. And I don't know if the 'Keywords' blocks in compiled shaders, which seem to be used for this conditional stuff, are set by the Unity Engine, by the Cg compiler or by something else, and how they're linked to the light objects.

 

Looks like this can be used to fake some nice GI.

 

Ok, that's a pitty. However, thank you for your feedback.

And, sorry, I didn't mean to sound harsh. I was just wondering, if the current approach made any sense.

Cheers

 

The ability to customize light behavior or add new light to Unity would be really neat. Another example beside the Area light would be to customize the light's falloff. Another example would be to encode light into spherical harmonics. Unity rendering design is great, it would be even better if developer can further customize it and experiment with new algorithms.

 

I use a data texture for passing additional light data.
Index it by shadowstrength or another unused parameter.
Works quite well - doing physically based rendering and area lights in an heavily modified prepass shader

But I would like to do a custom pass after the prepass and before the finalpass to add custom lighting to the buffer ...

 

Any chance to get that ability ASAP?
The custom parameters would be the more important part.

One solution to make it doable for us, (and possibly minimally work for you), would be to send a callback after the prepass or lighting pass, but after light buffer has been set, and before it's copied for using in the final pass?
I don't care if unity recognizes it as a light, as long as I can write to the Light Accumulation Buffer before it's used.

When it comes to parameters, being able to attach a script to a light and get a callback from that light before it renders into the light buffer would be enough to allow custom parameters! (Using global shader variables). However currently I don't know when a specific light is rendered and thus disallowing that.

That together with allowing us to choose what render target the camera should render the back/light buffer to would be insanely helpful.
(Allowing colored specular reflections!)
What that would allow us to do is have a double sized texture, and in the vertex shader double the geometry so it draws into both halves, one half for specular, and one half for diffuse... Same thing with back buffer, a single larger texture could do that work. Downside of this instead of multiple render targets would be performance.

A better alternative might be to allow us to set how many back-buffers we want (MRT), and same with light buffers?

If it's a possibility this will be implemented a guess as to when would be awsome!