Hypothesizing a new lighting method.

Miles Lacey · 2014-01-23T22:19:08

Hi Everybody. This is my first post so please be nice. I'm new to graphics programming with OpenGL and have only done basic tutorials thus far. After going through the deferred rendering tutorial at http://ogldev.atspace.co.uk/, I was kind of left with the impression that the process of deferred lighting is a bit backwards. Forward rendering looks great with all lights but the only problem is that rendering everything causes an absurd amount of iteration (render time = light count * mesh count). Deferred rendering shows promise (light count + mesh count) but it also means that, in some implementations, you may have to drastically increase the amount of vertices rendered. Additionally, shadows are a bit more difficult to implement. I was thinking of another approach to rendering lights with the speed of deferred rendering but the visual quality of forward rendering. Basically, there could be two cube maps stored on the GPU which could hold the color, intensity, and position of every light in a scene. The renderer would place every light of the scene into these cube maps in a first pass, then render each mesh in a second pass. The first cube map could add individual RGB and Intensity values of every light, clamped to four individual byte values while the second cube map could hold each light's position (clamped to 3 individual bytes). Next, after each light has been rendered to the cube maps, every mesh of the scene can sample them when they're processed in another pass by the pixel/fragment shader. This means that you get the speed of a deferred renderer (render time = light count + mesh count) with a drastically reduced memory footprint. Would anyone be able to shed some light as to the plausibility of rendering a scene this way? Right now, I have calculated that both buffers would be a total size of about 2.6 Mb, which seems like a hell of a lot less than what is typically required by a deferred renderer. Like I said above, I'm a graphics novice; this is all just theory and I have no idea how it would be implemented in practice, I'm just looking for feedback. My memory calculation is as follows: 4 bytes for the first cube map + 3 bytes for the second cube map = 7 total bytes per pixel, across both cubemaps (math whiz here). Each cube map is made of 6 2D textures. Each 2D texture is 256 pixels wide by 256 pixels high. Therefore, the total memory used by the entire process is 7 bytes * 256 wide * 256 high * 6 textures = 2752512 bytes = 2.6 Mb total.

Graphics and GPU Programming Programming OpenGL

Started by hamsham January 19, 2014 06:53 AM

17 comments, last by MJP 10 years, 2 months ago

MJP

20,295

January 23, 2014 10:19 PM

While I can see how image-based lighting might work great on mobile devices, how do these translate to desktops where the ALU/TEX ratio is much higher? I would guess that using literally abundant ALU to compute a dozen lights that are visible from one fragment may very well be faster than to do yet an additional texture lookup?

In console/PC games, it's standard to use IBL for background/fill/bounce/ambient lights (GI), instead of a flat ambient colour, and then compute the direct lighting analytically.

For film-quality IBL, you don't pre-convolve the probes, and each pixel has to read thousands of importance-sampled values from the IBL probes and integrate them using the BRDF (which is both ALU and TEX heavy)...

Which is why most people pre-convolve the probes. I'm not sure UE4 does, then again I'm not sure exactly what it is they're even doing. All I've gathered is "cube map array" and their ability to relight the probes in realtime.

They pre-convolve their specular probes, by convolving the specular BRDF with a given roughness assuming that V=N. They also take the standard approach of storing the results for different roughness values in the mip levels of the cubemap (higher roughnesses go into lower-res mip levels), and then selecting the mip per-pixel based on the surface roughness. They also refactored things a bit so that they can approximate the appropriate BRDF response for different viewing angles by precomputing values into lookup textures and indexing them at runtime. This sort of approach is becoming fairly common.

I'm not sure what they do for diffuse, but I would assume that they store SH probes which is what most people do these days.

The Blog | The Book

Hypothesizing a new lighting method.

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Hypothesizing a new lighting method.

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines