Light Probes

[The_Glitch]

I've been looking into adding light probes to help bring my static radiosity mapping lighting for my dynamic objects like characters and vehicles. I use shader pipeline and while reading up on light probes.

My question is this will this not be a feasible solution for me because currently shader pipeline does not support cubemaps. Do cubemaps have to be used can they not be used in a 2d texture?

Everything I've read they always use a cubemap texture.

[kornwaretm]

hi The_Glitch, i also read a lot about cube maps for shadowing reflection and refraction etc, and yes it is all what the online resources say whenever i search about those, i think the key of cube maps "involvement" is because it can be sampled with one shader instruction (correct me if i'm wrong), or at least the code are one function call . so for hardware advantage yes we should have cube maps, there are known hacks for 2d textures which are works fine, but again no hardware advantage because of the extra math we must do. there is one other thing i read which hard to prove for me, some one with eagle eye might see it perhaps?, it is said that cube maps are more accurate than spherical textures (i saw an article in nehe production covers the spherical texture). these are two things i know for now, so in my opinion cube maps is a must have.
irrlicht wise, i see driver->addCubeMap when i was walking through the code recently, irrlicht version 1.9 (the header says this) in the git repo. do you use the repo 1.9 or the official release 1.8x ?

[devsh]

actually it all depends on the kind of lighting you want

Diffuse Radiosity is often very acceptable (and the norm) and for that a cubemap is overkill, I'd use spherical harmonics instead

Proper radiosity would require you to calculate mip-maps for the probe anyway (you use the more blurred one for more diffuse/less shiny materials)

[The_Glitch]

I'm a little confused do spherical harmonics not need to render there result into a cubemap?

All I'm trying to do is figure a way for my dynamic objects to be able to pick up some of the lighting of the lightmaps.

I thought about maybe passing one of the lightmaps as a sampler to the dynamic objects and maybe getting there world position to look it up in the lightmap.

Though this may not work.


And no I'm using shader pipeline branch so I don't think cubemaps were ever added.

[REDDemon]

SPherical harmonics are just a "frequency based" approximation for a infinitely far cubemap of light coming to a point. The code for using spherical harmonics in shader is pretty efficient and short, even though the reasoning behind it is very complex, you will be fine copypasting and mentioning the author. (you can find SH light shaders everywhere).

Baking a cubemap into a spherical harmonic is not very easy, there are a lot of research papers about the topic and best ways to bake and avoid bad artifacts, it is still a Work In progress field. Basically you can find code also for that, but if you are unlucky you may incurr in that bake algorithm that once everywhile have some minor artifacts. Another way is to just do an average of cubemap faces and use each average as a single directional light, not very accurate, but better than nothing.

Baking lights into spherical harmonics is much simpler, chance are high you can understand that code yourself, but also for that procedure you can find ready code.

Another alternative to cubemaps is using a polar projected texture,that will work even without cubemaps: the only downside is that it has slower memory access because of "random like" texture access for distorted textures (I think you can neglect the math instructions on modern GPUs, the main problem now is memory access).

Anyway you should use Spherical Harmonics, in that way you will not need to use Cubemaps/PolarTextures, here's some usefull stuff (be sure to check stuff like license and do credits to original authors.)

Example of baking cubemap + downloadable WebGL source:

http://simonstechblog.blogspot.it/2011/ ... hting.html

Realtime SH where you can play with parameters:

http://hybrid0.github.io/SHL-WebGL-Demo/

Working code that projects a cubemap over a SH:

https://github.com/TheRealMJP/LowResRen ... ics/SH.cpp

[devsh]

The real way to do an environment map for diffuse lighting is horrifically expensive.

Essentially every pixel in your cube map can be treated as a small area light (for simplicity a point light with direction vector towards the center of the texel).
It works for specular reflection because your materials are super shiny and have tight (narrow) specular lobes which have high values only in a few discrete directions so you can point sample the cube map.

If you want something either more rough, or worse Lambertian (diffuse) youd need to blur/average/integrate over large portions of the cube map (hence the need for mip maps resulting from gaussian blur).

These two will explain it
http://http.developer.nvidia.com/GPUGem ... _ch19.html
http://http.developer.nvidia.com/GPUGem ... ter10.html

Contrary to what REDDemon says, generating SH from a cubemap is piss easy every band coefficient is simply a sum of all texels weighted by their solid angle and the band's basis function value in the texel's direction (basic integration of a piece-wise constant function on a sphere). Obviously if you start taking into account the linear, cubic or sinc interpolation between individual texels this might become more complicated but with large enough resolution this doesn't make a difference, just make sure you use RGB 32bit float textures for the SH band calculation.

Best part is that SH dont need filtering down for rougher materials, they already have the mip-map data inside themselves.

To evaluate lighting you need to simply calculate the SH coefficients of you lighting distribution (diffuse plus specular lobe oriented in the right direction), these can be precalculated fairly easily and because they are rotationally symmetrical they are a zonal harmonic which can be rotated out to match the lobe direction.

Since the lighting function should be an integration (convolution) of the lighting distribution against the enviornment incoming light distribution, in the frequency space its merely a dot product of the SH band coefficients.

The problem stems from the fact that most applications limit themselves to 3 band (9 coeff) or 4 band (16 coeff) spherical harmonics, while the diffuse material lobe's SH band expansion decays very quickly past the 3rd band and futher bands contribute less than 1% towards the final value, the specular doesn't behave anywhere near as nicely. Cutting off frequencies (assuming the farther bands are 0, and hence not using them) can introduce ringing, that's where the research comes in on either filtering your lighting function distribution or filtering the environment map to obtain nicer SH coefficients.

P.S. Best part is, if you're projecting the lightmap of a level into a spherical harmonic at point X, you only need to consider the parts of the lightmap which:
A) Have light value higher than 0 (since SH is a sum of weighted values)
B) Are visible from point X (rendering into a cubemap first solves this problem in a naive way, but visibility can be precalculated)
C) Are large enough when viewed from point X (you can combine this with (A) to cull certain contributions)

[REDDemon]

Contrary to what REDDemon says, generating SH from a cubemap is piss easy every band coefficient is simply a sum of all texels weighted by their solid angle and the band's basis function value in the texel's direction (basic integration of a piece-wise constant function on a sphere). Obviously if you start taking into account the linear, cubic or sinc interpolation between individual texels this might become more complicated but with large enough resolution this doesn't make a difference, just make sure you use RGB 32bit float textures for the SH band calculation.

Let me dissent . In some cases the naive approach may lead to artifacts, of course if we use everyone a blurrier approach, everyone is happy without making life a hell XD:

http://www.ppsloan.org/publications/StupidSH36.pdf

[The_Glitch]

My main goal is I just want my characters when they move around to pick up the static lighting. I don't even care if it's not that accurate. Would it be possible to pass the lightmap texture to my objects and maybe get there position somehow and have that position correspond to a position in the
lightmap and use that?

Also I'm using shader pipeline which does not support cubemaps so will I be able to use any of these techniques you guys linked?

[REDDemon]

Yes you will be able to use both tecniques, however I think it is better you read more information about Light Probes and lightmaps because those are 2 different things.

Irrlicht is capable of both rendering tecniques, but you have to implement some stuff yourself. You don't need cubemaps support for Light Probes because you can Bake cubemaps into Spherical Harmonics.

Light Probes = Precompute lighting from all directions coming to some points, then interpolate SH coefficients on CPU to determine lighting for a moving object

Lightmaps = Precompute lighting averaged in a flat Surface, No CPU interpolation here, the color is taken by sampling the lightmap texture on the GPU.

[The_Glitch]

I already have a lightmapping solution. http://irrlicht.sourceforge.net/forum/v ... =2&t=50404

I'll see if I can figure how to get a lightmap and light probe to work together.

[The_Glitch]

Here's what I'm trying to do http://www.gamasutra.com/view/feature/1 ... hp?print=1

Except for the ground map use one of the lightmaps instead.

[Mel]

http://www.valvesoftware.com/publicatio ... Engine.pdf
You could use Valve's approach. Esentially they don't use a cubemap per-se, but an array of 6 color representing a cube map that they pass as a vertex shader constant. I.E. you look up your probe in the world which consists only of 6 colors and pass it to the shader, There is no cubemap support needed, nor (very) complex math involved

[The_Glitch]

Thanks Mel always look forward to your replies.

I'll look into it.