glsl area light (implementation)

This topic is 3452 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Quote:
 Original post by zoretan orthographic projection wouldn't have been simpler ?

Rectangular light illuminates half of the hemisphere, so no.

Share on other sites
Quote:
 Original post by zoretan orthographic projection wouldn't have been simpler ?

Any projection is not well suited to this task. Specially ortographic projections. Perspective ones can´t cover a 180 degrees fov, and you can´t change the size of the light unless you want your projection to be stretched.

You could use paraboloid projection but it is just as complicated as what i´m doing and the results would be worse because you can´t easily control light attenuation and other things (normal mapping? several lighting models? specular?).

[Edited by - ArKano22 on November 5, 2009 8:21:40 AM]

Share on other sites
FWIW, ever read this? It's mathematically correct and should be entirely feasible for real-time use. You can even do spherical and n-sided polygonal lights :)

Share on other sites
Perspective can be made 179 but it won't be uniformly stretched shadow map... So you have to use half-cube (5 faces).

[Edited by - KRIGSSVIN on November 5, 2009 11:10:04 AM]

Share on other sites
Quote:
 Original post by InvalidPointerFWIW, ever read this? It's mathematically correct and should be entirely feasible for real-time use. You can even do spherical and n-sided polygonal lights :)

Wow! I didn´t even knew that document existed! thank you very much!! I was convinced that area lights weren´t used in games today because nobody had implemented them.

With my method you can also simulate disc area lights and basically any light with a polygonal shape that lies on a plane (triangle shaped, for example). But the method described there seems much more physically accurate (altough it seems that only works for roughly spherical or hemispherical shapes, am i wrong?EDIT: yes i´m wrong xD. It can be used for polygonal shapes defined by vertices). I will study that in depth :)

Share on other sites
Quote:
Original post by ArKano22
Quote:
 Original post by InvalidPointerFWIW, ever read this? It's mathematically correct and should be entirely feasible for real-time use. You can even do spherical and n-sided polygonal lights :)

Wow! I didn´t even knew that document existed! thank you very much!! I was convinced that area lights weren´t used in games today because nobody had implemented them.

With my method you can also simulate disc area lights and basically any light with a polygonal shape that lies on a plane (triangle shaped, for example). But the method described there seems much more physically accurate (altough it seems that only works for roughly spherical or hemispherical shapes, am i wrong?EDIT: yes i´m wrong xD. It can be used for polygonal shapes defined by vertices). I will study that in depth :)

It's a woefully under-researched topic, I'm afraid. That doesn't mean that some games don't use them, but effective techniques are fairly difficult to come by.

Share on other sites
I´m thinking about a cheap-ass way to render GI in an scene (its just a rough scheme): Let´s suppose a cornell box. You would add two area lights, one to each colored wall, covering its entirety.

Then, you would modify the area light code so that the light color and intensity would depend on a projected texture.

First render the cornell box, direct lighting + diffuse, don´t use the area lights. Store the result in a buffer and project it from the camera onto the scene. Then render the scene area lighting only using the projected lighting. Add together the two results (direct+area).

This would give a pretty convincing one-bounce semi-screen space local GI at the cost of two additional lights. If you wanted global GI, you would need to render a direct light only cube map from the camera position, which i think is feasible in realtime too.

If using deferred lighting you would be able to create absurd amounts of area lights around the scene. The two downsides are that you would have to place them by hand or write an algorithm to place them automatically, ala instant radiosity (most brute force being one light per polygon face), and that backfaces would not contribute unless you captured them in a projection.. The good news is that it has no precomputation, its entirely dynamic and that for big planar surfaces like walls (which are pretty common) its enough with one light. What do you think? would it be worth to implement and give it a try?

Share on other sites
Have you tested this trick in scenes with complex objects?

Share on other sites
Quote:
 Original post by n00bodyHave you tested this trick in scenes with complex objects?

You mean the area light? Yes, i have tested it in the sponza atrium scene. It looks just like it should, maybe the transition from light to darkness between the front and back sides of the light is a bit too pronounced but it works ok. It works just like a spotlight or point light does so you can use normal mapping and all that stuff.

Share on other sites
I´ve changed the code in the first post because it had a bug and a little quirk:
-bug: nDotL is not dot(N,L), it should be dot(pnormal,-L). This takes out the hard edges and corrects an ugly artifact when the light was perpendicular to a plane.
-incorrectness: using dynamic branching to cull out the specular. It is better both visually and efficiency-wise to just vanish it out smoothly.

EDIT: specular calculations rewritten. Now they are mathematically correct, until now they weren´t proper reflections but only projection.

[Edited by - ArKano22 on November 6, 2009 6:08:03 PM]

• 16
• 9
• 15
• 13
• 60