PDA

View Full Version : Ambient light



Tandy
05-05-2002, 11:25 AM
I have been playing with per pixel lightning.
Now my question is how do u guys handle ambient light.I have read Ron Frazier's paper about the issue.
How ever that solution to ambient is not good.
Coz the bump mapping only appear if it shine a light over the surface.And in the ambient part of the world it looks completly different.

/Tandy

/Tandy

davepermen
05-05-2002, 11:47 AM
http://tyrannen.starcraft3d.net/ambient.jpg

dont use a constant color, but lerp (depending on dot of normal to light)

hope you got the inspiration..

Tandy
05-05-2002, 12:16 PM
I think i got the idea.

Here goes, abmient light vec is always parallel to the normal vec right? so i just put the normal in tangent space.

That would be:
ambient = Basemap*(N'.N)*ambient color

where N' comes from the normal map and N is the normal vec transformed to tangent space

Or am i way off here http://www.opengl.org/discussion_boards/ubb/wink.gif

Thanx for the reply davepermen
/Tandy

[This message has been edited by Tandy (edited 05-05-2002).]

LordKronos
05-06-2002, 03:33 AM
I dont really think a bump map makes sense for ambient lighting. The way a bump map works is that it adds shading/shadowing to portions of a surface that are not orthagonal to the light vector. The odd thing about ambient lighting is that there is NOT a light vector because ambient light has NO DIRECTION. Ambient light, by definition, comes equally from all directions. Thus, all surfaces are lit equally and uniformly, a concept which is contradictory to the purpose of a bump map.
I believe my solution to ambient lighting is indeed correct.


Ron Frazier

Nutty
05-06-2002, 03:41 AM
The reason bump-mapping looks wrong in pure ambient conditions, is because ambient is a fudge. There is no such thing as ambient in the real world.

I think Dave's picture illustrates something that looks alot more realistic.

LordKronos
05-06-2002, 04:37 AM
You know, somehow when I read this thread the first time, I didnt look at dave's picture (not sure why). After looking at it, I can see why you would want to do bump mapped ambient lighting, and N'.N seems like a reasonable approach to this.

davepermen
05-06-2002, 07:54 AM
why he wants this is simple:
yes ambient has no bumps
but world has no ambient
everything in shadow would be black, not ambient

so why then ambient and not black?
not in light means not black in realworld because of:
indirect illumination/global illumination

well.. your approach (N.N') or my approach (N.Point_to_Light)*.5+.5 to find some ambient lighting value are ways to get some pseudoglobalillumination.. wich looks bether.. well.. play around and you'll see

(my one is ambient = lerp(n.point_to_light*.5+.5,lightenedcolor(yellow) ,darkenedcolor(blueish)) http://www.opengl.org/discussion_boards/ubb/wink.gif

LordKronos
05-06-2002, 09:24 AM
Not having actually done this, Im trying to picture this in my head and on paper, so indulge me here for a moment.

First, with regards to your (N.Point_to_Light)*.5+.5 formula, how did you come up with this? Do you have some sort of reasoning, or did you just pick it out of thin air?


Second, the odd thing about your ambient calculation is that the bumps will change when the position of the light changes. Im not really convinced that would look correct. Of course, my imagination doesnt really do the best bump mapping, so maybe Im just not picturing it right.

Its all a big hack anyhow, so I gues one hack is as good as another?

Tandy
05-06-2002, 09:39 AM
I dont agree with u guys that ambient light has no bumps.Bumps are just a way of adding detail with out increasing poly count.

Dave i dont really get ur solution.But u need a cube map if the light is close right?

in N'.N you wouldnt need one.So everything can be done in one pass on a GF1.

But i really like the way ur ambient light look.(Really nice)

/Tandy

davepermen
05-06-2002, 11:20 AM
lord cronos:
the whole lighting sheme you're refering to is a _VERY BIG HACK_
it is _BY NO MEANS IN ANY WAY RELATED TO REALITY_
its just one thing:
fast

as the gpu's get bether programable and faster in rendering, you can do bether approaches to simulate lighting..

and yes, bumps do change on parts where there is no lighting. why? cause there is INDIRECT lighting surrouding it. and even if its quite smooth distributed, _EVERY_ lightray has a direction so you get for a more correct ambient term direction of the indirect lightsources that affect the object.. so yes, if you rotate, your bumps are enlightened differently..

from where my approach is?
from nvidia i think, but i'm not sure anymore..
the base idea was to do image based lighting, wich is done yet for the specular term of the equation. result: perpixelbumpmapped reflections with cubemaps.. they are by no means correct reflections, but assuming you have some environment info you can generate a cubemap from it you get quite good results with this..

now the diffuse term and ambient term are in fact the same, ambient just does not exist..

how to do the diffuse then? say you have an envmap surrounding your object, then you can look up the whole hemisphere "above your surfacenormal" to get the lighting (with convolutionfilters on cubemaps, heavy math http://www.opengl.org/discussion_boards/ubb/wink.gif)

now this means if the normal faces to some very lightened part of the cubemap it will be bright there, else not..

now for the "diffuse" we use normally we can simply use this for pointlights like before.. max(0,L.N) where L = normalized point to light and N = normalized surface normal..

now the ambient is resulted by all those not that bright "lightsources" from the cubemap, wich are not direct pointlights (else we would have millions of those to calculate)..

say for a landscape engine this means every normal facing up, will see blue, every normal facing down will see.. well.. depends.. say green for a nice landscape http://www.opengl.org/discussion_boards/ubb/wink.gif.. that means you have to dot the normal against the point_to_sky vector (wich is straight up) to find an interpolationvalue from blue to green..

now because the dotproduct is signed you have to map it to some unsigned range.. *.5+.5 this is for..

for arbitary lightsources it works quite well to say in direction of the light, our ambient term gets more bright.. bright means warm colors, like the yellow of the bunny

dark areas mean cold colors, like the blue of the bunny..

this means that if the normal is looking in direction of the lightsource, it will catch more of the warm part, cause the lightsource will "warm up" the whole environment map hemisphere in this direction..

of course, this is a VERY ROUGH approximation..
but the results are awesome good if you take a look at the bunny (the pic is not by me but from some pdf about this whole topic but i dunno from where it is again.. i'll take a look around when i find the file on the hd.. google should be smart enough http://www.opengl.org/discussion_boards/ubb/wink.gif)

but i like your approach as well.. saying if the normal is straight up the face normal it will get full light, the more it faces away from it the less light it can catch..

your's is independend on lightdirection, so it could be precalculated at normalmapgeneration btw

well.. just grab the blue component out of your normalmap and you have it (GL_BLUE in the registercombiners http://www.opengl.org/discussion_boards/ubb/wink.gif)

davepermen
05-06-2002, 11:37 AM
can't find it anymore except a japanese paper where you can find the ambient = n dot l * .5 + .5 in http://www.opengl.org/discussion_boards/ubb/wink.gif (can't display the japanese font so i get a looooooot of dots representing chars http://www.opengl.org/discussion_boards/ubb/wink.gif)

LordKronos
05-06-2002, 04:46 PM
Its Lord Kronos!!!! Get it??? With a "K"!!!! Not a "C"!!!! OK??#$*#)@@

(sorry...just had to pick on you after all the perman/permen posts) http://www.opengl.org/discussion_boards/ubb/smile.gif

Thanks for your additional insight. I guess I would have to see both ways in motion to see which would be better (Im having a hard time picturing it).

About the GL_BLUE thing, I didnt even think the whole issue through like that, but your right, thats it...already right there for you. And the register combiners even let you select that component individually. Im always impressed by how complete their design was. Its like they accounted for practically everything. Seemingly any time I come up with an idea like this, I can always somehow just squeeze it right into there.

I came into this thread originally thinking it was a pretty useless topic. Quite the opposite. Thanks.

jwatte
05-06-2002, 06:45 PM
If you have shaders, you can simulate a slightly better form of ambient light by doing some things to your diffuse.

For example, you can map your diffuse such that normals pointing straight away from the light source cause light at level A, and normals pointing straight at the light cause light at level A+L. In this way, diffuse light will "wrap around" the entire object, making ambient look a little more distinctive, but the entire scene lighting looks as if it was taken in dense fog.

You can also get fancier by adding the two together, making for a flexible lighting solution:





Lout = A + La * (max(N dot L,0)) + Lb * ((N dot L)+1)/2;



This can be done in a vertex shader, or on regular fixed-function hardware by burning a texture unit (NORMAL_MAP texgen, and an appropriate texture matrix + texture bound).

davepermen
05-07-2002, 01:42 AM
Originally posted by LordKronos:
Its Lord Kronos!!!! Get it??? With a "K"!!!! Not a "C"!!!! OK??#$*#)@@

sorry

Thanks for your additional insight. I guess I would have to see both ways in motion to see which would be better (Im having a hard time picturing it).

look at the bunny and you have it pictured yet http://www.opengl.org/discussion_boards/ubb/wink.gif i'm currently ill caused by fever and influenza so i dont have the power to code it myself.. sorry.. but i will.. sometimes.. in far future.. (when i got such a thing: http://www.chaintech.com.tw/IMAGES/VGA/HR/agt61b.jpg http://www.opengl.org/discussion_boards/ubb/smile.gif)


About the GL_BLUE thing, I didnt even think the whole issue through like that, but your right, thats it...already right there for you. And the register combiners even let you select that component individually. Im always impressed by how complete their design was. Its like they accounted for practically everything. Seemingly any time I come up with an idea like this, I can always somehow just squeeze it right into there.

well.. then you're in luck.. here on my gf2mx i always wanted to do this, or that, and always some funny restriction of the combiners dropped any change to implement it (found sometimes about 4 ways of nearly doing something but all the time something was in my way.. grmbl.)
just for an example: i would have gotten perfect perpixellighting inclusive specular power 32 with selfshadowing in 2 passes with ALL VECTORS NORMALIZED PERPIXEL (normal,point_to_light,halfangle) but then i got the [0,1] rangeclamping between general combiners to feel.. so i _could_ do it with the scene at half brightness.. haha http://www.opengl.org/discussion_boards/ubb/smile.gif (now when i think about it i _could_ do much more after seeing there is no need for normalizing halfangle anymore (found a hackaround http://www.opengl.org/discussion_boards/ubb/wink.gif), finding the brighterthanone glowing idea (implemented successfully by richard nuttman on www.nutty.org) (http://www.nutty.org)) etc.. but who wants to code for a gf2 anymore if he can look at such a golden board? and who wants to code for this if you can see the opengl2.0 specs.. and who wants to code for this if he can raytrace.. oh well.. http://www.opengl.org/discussion_boards/ubb/smile.gif


I came into this thread originally thinking it was a pretty useless topic. Quite the opposite. Thanks.
just one thing:drop everything you know about blinn and phong and that stuff.. go on for papers about global illumination and all that, learn how correct lighting _would_ work. then you see where and how and why blinn and phong in some cases do make sence, but that _if the power is there_ it is bether to look for a more accurate solution..

just one thing.. as long as we can't illuminate our scene by about 100 billion particles every frame moving around in the whole scene (our lights you know http://www.opengl.org/discussion_boards/ubb/wink.gif), we have to use some statistical approach.. means looking at how it would be, and find a nice fast solution looking near to it..

there i found some bethers than blinn and phong in my eyes.. used successfully in my raytracer for example.. but oh well.. i need to upgrade my p3 500 as well http://www.opengl.org/discussion_boards/ubb/smile.gif

zed
05-07-2002, 02:40 AM
>>Its Lord Kronos!!!! Get it??? With a "K"!!!! Not a "C"!!!! OK??#$*#)@@<<

hehe

my take on the whole issue
we all know ambient light doesnt exist in the real world, right.
the addage of 'treating every light/surface as a diffuse light' is the way to go.
its as slow as hell BUT its how the world around us works (at least in the big details ie perhaps subparticles dont work this way but bugger them mate), for a while now ive been exploring this method, its not quick (it can be improved though) BUT personally the results are really worth it ie a 10,000 polygon object with only diffuse + reflected light looks better than a 100,000 polygon object with stencil shadows + ambient.

(btw davepermen the bunny looks cool, who cares if its a hack this is why i say as long as the brain saiz hmmm that looks realistic then it doesnt matter)
(also for the cats out there if u wanna see blue light come to central otago, blue hazish shadows on the hills the whole day) i though that was only a joke or something u only see in twilight afore i came here, mindblowing man the scale of it all

Tandy
05-07-2002, 09:58 AM
Well i have read a little more about lightning.How far away do u guys real time raytracing is. Now that would be cool.If u start working on a engine now u should take a look at real time raytracing.

It could be possible within a year or two.

Dave u said u have made one how complex is it to do it in real time?

/Tandy

davepermen
05-07-2002, 10:06 AM
it is simple c(+-++ http://www.opengl.org/discussion_boards/ubb/wink.gif) so not very fast
it is only planes and spheres so not that useful
it is only 160x120 so not that big..

but you know what? its acceptable to run on my old system.. http://www.opengl.org/discussion_boards/ubb/smile.gif p3 500 about 3 years old now..

i would love to rewrite this for an athlonxp2200+ or something like that..

i've written one for triangles.. could get some triangles in realtime on small res as well (even at 320x240 on the athlon1.4gig of my friend..yeah http://www.opengl.org/discussion_boards/ubb/wink.gif)

and this with c++ only!

realtime raytracing is opengl2.0 away..

realtime raytracing is directx9 away..

its about one year..

technique for doing it on gpu's is yet there, but as they are not designed for this programability they are a) slow
b) very unpresious.. 8bitcomponent per vector is simply not that useful for representing rays.. http://www.opengl.org/discussion_boards/ubb/smile.gif

here, running on a ati radeon8500 (never seen in realtime.. would love to see an exe, i know one with radeon..)
http://tyrannen.starcraft3d.net/loprecisionraytracingonatiradeon8500.jpg

there are papers of siggraph2002 about how to implement rtrt on gpu's..

it will be here, soon..
and it will rock

and it will have the very same lightingproblems as we have yet now..
it will have perfect sharp shadows (at the beginning.. the faster the spu's, the more stochastic can evolve => softshadows)

i guess its 10 years till global illumination

if one gets metropolis raytracing into hardware, even sooner.. in about 5 years then..

well.. for static scenes.. dunno how fast to set up the scene for the gpu yet.. dunno dunno.. we'll see..

oh, spu is no fault.. its streaming processor unit.. as we have to drop the current
vertex-processor->rastericer->pixelprocessor architecture and replace it by some more general one..

Tandy
05-07-2002, 11:34 AM
Ok maybe realtime raytracing is a bit to expensive for real time.But how about BRDF-based lightng now that look very nice to.Thats a lightmodel i will try.

Everything can be done on the GPU.
In a vertex shader, and reg combiners.

But i cant see where i can apply bump maps in BRDF.Maybe someone can tell me? http://www.opengl.org/discussion_boards/ubb/wink.gif

/Tandy

[This message has been edited by Tandy (edited 05-07-2002).]

davepermen
05-07-2002, 11:59 AM
brdf needs 4 input angles.. to represent the directions to the eye and to the light..

if you take a close look you'll see that those angles are dependend on surface, means they are in tangentspace..
or the other way, they are dependend on the normal as well..
that means you need perpixeltangentspace.. well thats not that easy possible but i think you can get the angles according to the perpixelnormal and the pervertex tangentspace quite good.. (hoping http://www.opengl.org/discussion_boards/ubb/wink.gif)
result should be bumpmapped brdf's..

davepermen
05-07-2002, 12:04 PM
and brdfs don't solve this problem at all.. this problem is caused by indirect lighting..and indirect lighting is independend on the lightingequation for each point and for each lightsource.. its the problem that we have infinite amount of lightsources http://www.opengl.org/discussion_boards/ubb/smile.gif (lots of passes..)

PH
05-07-2002, 12:04 PM
Tandy,
Try a search on shift-variant BRDFs.

Tandy
05-07-2002, 12:17 PM
Yeah i see that know, ambient light or global illumination hard to get right (or impossible)

Just ran into BRFD paper on Nvidia thats way the post.
Hey look at these! http://www.opengl.org/discussion_boards/ubb/wink.gif
http://www.mpi-sb.mpg.de/~jnkautz/projects/anisobumpmaps/

Anisotropic Shift-Variant BRDFs seems to look pretty good http://www.opengl.org/discussion_boards/ubb/smile.gif

/Tandy

JD
05-08-2002, 06:15 PM
N dot L gives you intensity, so just modulate it with light's color then add ambient color to the result, I would think. I clear everything to ambient then render my point lights on top of that adding in ambient, I think. Look at the pic at my site http://forged3d.tripod.com

What I plan to do in my game is to give each room an ambient color so that for example you have three rooms. In first room is point light which will have strong ambient component, then in the second room the ambient drops off and in third room it drops even further almost to black. That will simulate the light bouncing around walls and lighting each one a bit less as distance from light increases. I don't want my point light to shine thru all three rooms. Just in the last room with small attenuated radius then have ambient take over in the other rooms. I think this will look nice. Granted a real-time dynamic radiosity solution would be the best thing since slice bread, well maybe in year 2050 when I'm on my death bed http://www.opengl.org/discussion_boards/ubb/smile.gif

V-man
05-09-2002, 06:12 AM
Originally posted by zed:
[Bmy take on the whole issue
we all know ambient light doesnt exist in the real world, right.
the addage of 'treating every light/surface as a diffuse light' is the way to go.
ll[/B]

BUt why do you say that? Ambient light just means secondary light rays. It is a stupid way to do ray tracing.

IMagine you have a room in which you have a few of those lights that project high beams onto the ceiling. There will be reflected rays having the color of the ceiling bouncing
all over the place.

If you dont use ambient, where diffuse is zero will look perfect black. NOt good!

Anyway, raytracing will be the future. radeon has a kind of demo, right now. Dont knwo how it works.

V-man

[This message has been edited by V-man (edited 05-09-2002).]

davepermen
05-09-2002, 11:20 AM
Originally posted by V-man:
Anyway, raytracing will be the future. radeon has a kind of demo, right now. Dont knwo how it works.

yep, the link i posted above.. would love to see the exe http://www.opengl.org/discussion_boards/ubb/smile.gif

zed
05-09-2002, 12:28 PM
V-Man im not sure what u mean, i was talking about ambient in the standard equation as used by ratyracers opengl lighting etc
ie shade = ambient + diffuse + specular ...
raytracing (traditional sense) bah

V-man
05-09-2002, 05:09 PM
zed,

I was just saying that the ambient component is a kind of fix for old slow machines, where it can simulate secondary rays.

A surface area will receive approximatly equal amount of photons from every direction except for the 180 or 0 degree angle. Those photons represent the ambient component of the opengl equation. That also means that bumpmaps dont matter for that.

Inreality, we have specular rays, (no color change to light), diffuse (ray is absorbed and reemitted, so light color is changed. Also depends on the depth penetrated by the photon), transmitted with color filtering.
What else am I missing? Phosphorescence? fluorescents?
GL lighting is fake, not because of the ambient component, but because it doesn't care about light frequency and material composition.

V-man

davepermen
05-10-2002, 02:43 AM
Originally posted by V-man:
GL lighting is fake, not because of the ambient component, but because it doesn't care about light frequency and material composition.

well.. its a fake because of the ambient as well http://www.opengl.org/discussion_boards/ubb/smile.gif

the whole equation is wrong, the rgb model is wrong. but well.. we can't change the rgb model (and fit an infinite amount of frequencies in http://www.opengl.org/discussion_boards/ubb/wink.gif), but we can change the equation, to fit our higher needs..