GPU Gems: Image-Based Lighting

Started by
2 comments, last by Litheon 12 years, 4 months ago
Hi everyone,

I'm playing around with reflections and cubemaps but I'm having problems with flat surfaces and nearby objects.
So basically, I also want to take the fragment position into account instead of only a direction vector.

Therefore I was reading Chapter 19. Image-Based Lighting of GPU Gems.


Cube maps are typically used to create reflections from an environment that is considered to be infinitely far away. But with a small amount of shader math, we can place objects inside a reflection environment of a specific size and location, providing higher quality, image-based lighting (IBL).[/quote]

and further in the document:

In addition to the standard coordinate spaces such as eye space and object space, we need to create lighting space— locations relative to the cube map itself.[/quote]

but I don't really understand what he means with "lighting space".

Can somebody explain me this? Or can point me to some other resources?

I've also seen Reflection with billboard imposters of graphicsrunner but that seems so much work to create imposters for all objects.

I was also thinking about Real Time Local Reflections (raytracing in view space in your depth buffer), but that is something I want to try next :)( looks really easy to do so ) 
Advertisement
Chris Brennan's 2002 paper details a method whereby you can correct the lookup vector using the pixel position and the position from which the cubemap was rendered to improve reflections/refractions.

It can be done more accurately by calculating where the lookup vector from the reflecting/refracting point actually intersects the cubemap, then subtracting the cubemap centre (the point from where the cubemap was generated) to get a final, 'corrected' lookup vector:

corrected cubemap lookup = p + (v * h) - c;

Where p is the fragment position (point receiving reflection), v is the original lookup vector (i.e. reflected view vector), c is the cubemap centre and h is:

dot(v, (c - p)) + r

r here is the 'radius' of the cubemap (we'll assume the texels in the cubemap are all fixed distance from the centre).
By default environment map reflections assume that the surface being reflected is an infinite distance from the object being rendered. Obviously this assumption is not so great in practice. If you really wanted proper reflections you would have to render out the reflected surface depth along with the cubemap, and then raymarch through it to find the intersection. A much cheaper option is to map the reflections to a sphere or bounding box, and use that to correct your reflection vector. That paper linked above shows how to do it for a sphere, and there was a thread on this forum that showed how to do it for an AABB.
Thanks a lot MJP and johnchapman (nice projects on your website by the way) for your explanation.

I first tried to map it to a sphere with johnchapman deriviations but eventually I went for the AABB method explained in this thread (this is the one MJP was thinking of i think)Box Projected Cubemap

And this gives good results if I compare it with real planar reflections.

The other methods, also storing the surface depth of the cubemap and raymarching, non pinhole camera's, layered distance maps etc sounds to expensive for what I'm trying to accomplish.

A special thanks to MJP, you are really doing a lot for this community and I'm learning everyday from you, from all your posts and your blog.
Please keep doing that! :)

This topic is closed to new replies.

Advertisement