PH,
I have. Full bumpmap lighting in 5 passes on gf2 with volumetric shadows. It all seems to work fine for me and I still don’t see what the problem is. Do you know what the topic was in which you discussed this so I could find it? Either that or maybe explain it to me now.
Maybe you mean a color gloss map instead of just in alpha. I dont see why youd need that though.
Yes, for one light it works. For 2 or more lights on a single specular surface ( that reflects the lights color - some materials do that ) with shadow volumes for all lights, the implementation is not that straight forward.
I don’t remember when I posted about this but I think it was in a thread about pbuffers.
Oh, do you have some screenshots of your work that you could post somewhere ? I’d just like to see what other people are doing ( not that I doubt you, just curious ).
PH,
Yeah one surface with spec and however many lights you want that all shadow. You just add them up in the frame buffer. Its 5 passes each light for mine full effects. The only color the spec has is that of the light which is what your saying. I’d show some pics but I’m at work now. Anyways I’ll take a look at the pbuffer thread and see if I can see what your saying there.
It really just boils down to requiring two RGB temporaries. You can solve this by drawing your shadow volumes twice, once for diffuse and once for specular. Or you could save the affected stencil region to a texture ( one for each light ) and restore the shadow infomation when time comes to sum specular RGB. If you only have white lights, you can use destination alpha as the second temporary. Note that materials such as metals will have a reflection that is somewhat the color of the material ( so a white light on a gold surface, will have a golden highlight ).
Or you might be able to do some so tricks to avoid rendering to a texture:
Pixel = sum( DiffuseLight*Shadow )DiffuseMaterial + sum( SpecularLightShadow )
The shadow term is required in both sums, so if you dont want to draw you shadows twice, you need a second temporary ( a texture, pbuffer or something else ).
If you could get the DiffuseMaterial into the sum ( without clamping ) then there wouldn’t be any problems. I’m looking into this at the moment.
PH,
Since I use the alpha of the diffuse tex I can mul by the diffuse color for the spec calculation too if I wanted. Why would your stencil get overwriten? I just do it once at the beginning and enable stencil test. I do save stuff in the alpha channel such as att and things but this doesnt touch the stencil. I could run through the passes if you want.
The stencil will be overwritten by the next lights shadow volumes as you sum the diffuse contribution. Shadows from two seperate lights that occupy part of the same area ( affecting the same surface for instance ). You need all these seperate shadows in the second sum but you sum all the diffuse light first, then modulate by the surfaces diffuse material, then add all specular contributions ( all the previous shadows terms are required here ). Is that not what you are doing ?
Originally posted by zeroprey:
I could run through the passes if you want.
Sure, that might help in seeing what you are doing.
Nope thats not what I’m doing. I cant remember the passes off the top of my head cuz its been a little while and I dont have the code in front of me. I tryed to write them out. I can write them down when I get home if you want. I’ll tell you the jist of it.
shadow to stencil
attspot->alpha
specpassalpha->rgb(might be 2passes dont remember)
diffuseshadingalpha->alpha
diffusecoloralpha->rgb
I dont redo things and split up the dif and spec. You just have to make sure the passes always add to the frame and nothing else.
zeroprey, you need the destination color to accumulate the lighting result. So there is no simple way to pass color information between passes in a lighting calculation. When you calculate specular you need to do this. The only thing left right now is destination alpha in the framebuffer or render to texture (which I don’t think will be a favoured path).
2 factors should be prominent in your thinking, 1) destination color (the framebuffer) is reserved for total accumulation (except on the first light) and 2) a full lighting calculation with diffuse & specular bump map attenuated etc cannot be done in a single pass on some of the highest end current hardware (GF3 & GF4).
The conclusions follow easily from this. The only other significant point of debate is does the engine support render to texture or render to destination alpha for the first pass. Remember that the first light can use destination color (for simplicity it may not)
from Carmack’s latest .plan
Doom needs more than 2 bits of
destination alpha when a card only has four texture units
Hmmm… I think that’s a bit of a giveaway, destination alpha for attenuation storage followed by source * destination alpha on multipass lights it is.
another problem youd get doing it the way you are by doing mul diffusemap last is that in the end the lights cant sum to white. That is unless youve found some trick around that.
Check out that link I gave earlier cuz I just do a reduced version of that. I think I just sacrifice color light maps but I dont remember. Its been almost a year since I’ve fooled with that part of the code.
P.S. Since a smart implementation would render stuff like emission (glowing stuff)during the depth fill pass I think even the first light will be unable to use destination color because it will already have color information from the depth fill pass.
zeroprey, w.r.t. your latest comment, I think that’s what we’re talking about with clamping earlier in this thread.
zeroprey,
Of course the lights can sum to white. If you had the diffusemap inside the sum, everything would eventually be completely white ( that is a completely white surface, which is probably not what you want ).
emission is just ambient really. The ambient pass(havent coded yet) would just be done when you render the depth for the shadows. That would be once per object instead of per light.
It can be rendered the same for our purposes. W.r.t. the rest that’s what I just said. It is significant because it instantly reserves destination color so NO lights may use it between passes. Not even the first.
[This message has been edited by dorbie (edited 07-01-2002).]
dorbie,
Another big hint from one of his .plan files, is that the GeForce3 requires 2-3 passes depending on the number of color components in a light. You could probably use destination alpha to store the number of lights that affect a certain pixel ( and use that to pre-modulate the diffusemap and bring it into the sum ). This might not work or be efficient but anything is better than rendering to a texture ( I would assume ).
PH,
I dont see how you can get a surface with 0.0 spec to go to white. The diffuse all adds to no more than 1 cuz of the frame buffer. 1*diffusemap wouldnt be 1 unless the diffusemap is one. The only way is if you sum the diffuse each time.
dorbie, yes this is the clamping problem. It was recently discussed on the gdalgoritms group.
[This message has been edited by zeroprey (edited 07-01-2002).]
Originally posted by zeroprey:
PH,
I dont see how you can get a surface with 0.0 spec to go to white. The diffuse all adds to no more than 1 cuz of the frame buffer. 1*diffusemap wouldnt be 1 unless the diffusemap is one. The only way is if you sum the diffuse each time.
Which is exactly why I do it last 
.
Edit:
That is Pixel = sum( DiffuseLight )*DiffuseMap
[This message has been edited by PH (edited 07-01-2002).]