PH,
I dont understand, you want it to be at most the diffuse map? I dont think thats physicly accurate. It should sum to 1 if there are enough lights. Am I wrong? I do believe thats what all the fuss was about on the gdalgorithm group.
PH I’m skeptical about that. Maybe he thinks he needs to break the diffuse & specular into separate passes in addition to the destination alpha first pass for the extra color work. It’s getting too speculative now, some things we know others… well you can roll your own lighting anyway so does it really matter? 
Zeroprey, it sounds like Carmack has already said he boosts the attenuation result and keeps the map a bit darker. This is like storing an attenuation value >1 in the framebuffer. It’s using a post modulate scale to store an extended range variable in the framebuffer and it costs you a bit or two of precision due to the scale. It’s very like the sourcedest + destsource in a texture emboss bump map implementation, you need to keep the bump map values down in the framebuffer to avoid clamping but you effectively multiply the result by two during the modulation. I think the motivation is different though. With the bump map you want to avoid clamping during the emboss, here I suspect he wants to avoid clamping of the result to avoud the post clamp modulation of his lighting result (which would look slightly strange).
I think this is quite clever, I hadn’t considered this before PH sent me in the right direction in this thread, it should mean that overexposure is very nicely handled in the engine when a light over illuminates a surface.
[This message has been edited by dorbie (edited 07-01-2002).]
Zeroprey,
To be absolutely sure we are talking about the same lighting equation: I’m using the one from the RedBook ( chapter 6 ) which is the GL model. I do this per-pixel, with shadows and colored highlights. This requires two RGB temporaires for multiple lights ( in general ). The diffusematerial term I store in a texture map ( DiffuseMap ).
Dorbie,
Yes, it probably won’t work. Besides I’m not trying to copy Carmack, simply looking for more efficient ways to solve the issue I mention previously ( which I thought was the pre-modulation he talked about ).
dorbie,
I havent heard that before. Do you know where you heard that? Seems strange he’d cut his presision in 1/2. I can see cut down on att thing but a x2 at the end doesnt make sense to me.
I heard it second hand in this thread from PH :-), but I drew the conclusion it was the attenuation the comment applied to. See the earlier discussion on clamping. This makes some sense to me it might be worth that precision to boost the levels, Remember if the screen is too dark human contrast sensitivity works against you anyway and the user probably cranks his monitor brightness up :-).
(Post 13 in the thread)
[This message has been edited by dorbie (edited 07-01-2002).]
I was about to start pulling my hair out 
. My comment about storing the number of lights in dst alpha was to support what I wrote in post 13. I have thought about this before but I think I concluded that it wouldn’t work ( unless perhaps attenuation and other brightness affecting terms are combined with it too ).
[This message has been edited by PH (edited 07-01-2002).]
just wanted to state that i like how dorbie always counts posts and refers to them by number… (how about the “quote” button? i don’t like to count myself you know… 
)
I took a look at the lighting model in the redbook. You’re not doing the whole equation are you? Heres the general equation I do:
amb+sum[ (1-d.d)spotlightcolor*((N.L)*diffusemap+((N.H)^n)speccolorgloss) ]
come to think of it now I might need 6 passes for gloss. I dont remember now. I sure hope not.
On a gf3-4 pretty sure I can do it in one pass for a static exponent and 2 passes with a exp texture using the tex combiners(also helps the precision problem). That would be done using the combiner normalization. Has anyone tryed this? How does it compare with the cubemap?
[This message has been edited by zeroprey (edited 07-01-2002).]
Yes, the whole equation. I recently added the ambient term but I might remove that ( though it does make it look more real ). The attenuation is of course different ( it has to be bounded ).
Oh, my spot effect has inner and outer cone angles and raised to an exponent ( currently a fixed value ).
I am impressed then. Does that work on gf1-2 hardware? Could you maybe tell me how many passes and stuff that takes? I hadnt seen attenuated ambeint in the equation before but that certainly fixes the changing at rooms problem I would have had with just a flat per room ambient value.
Is that spot effect created in the combiners or do you just gen a texture for it with those values?
Originally posted by zeroprey:
Is that spot effect created in the combiners or do you just gen a texture for it with those values?
A pre-generated texture ( that depends on inner/outer angles and an exponent ). I could do it with ATI_fragment_shader on Radeon 8500 but that wouldn’t be very useful ( and it would be slower ).
Originally posted by zeroprey:
I am impressed then. Does that work on gf1-2 hardware? Could you maybe tell me how many passes and stuff that takes? I hadnt seen attenuated ambeint in the equation before but that certainly fixes the changing at rooms problem I would have had with just a flat per room ambient value.
Well, I’m not trying to impress you . You did ask why rendering to a texture was required ( the equation from the Red Book where the DiffuseMap is outside the sum requires this OR some other trick ).
Oh, 5 passes on GeForce1, 3 on GeForce3 and 1 on Radeon 8500 ( I have a “new” shot of this on my site ).
An interesting thing to note: just saw recently on that gdalgorithms list the way they are doing the lighting for Malice. They have 3 buffers a normal buffer, N.H, and N.L. they do a dependent tex read of the normal buffer to make the N.H and N.L with a full screen quad. They then do another quad to do fill in the equation and slap it to the frame buffer. Its a interesting idea I think. Maybe its more applicable for the lower res of xbox. If you have to do the extra buffers might want to look into this.
[This message has been edited by zeroprey (edited 07-01-2002).]
It’s exactly the same with the interpolation problems with specular lighting - when I brought this issue up ( a post a long time ago ), only Cass Everitt immediately knew what I meant.
Here is that discussion. http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/003519.html
-SirKnight