In the past I was recalculating the rgb value per vertex and then adding it to an accumulator. It never looked right. So how do you do it realistically?
This is being done in software and not in a vertex program btw.
hi
I’m currently make some sort of research about bump mapping techniques, I’m a relatively new to OpenGL(2 months), but I am very ambitious about all the stuff related to OpenGL API, and I found in some articles on the Net that Bump Mapping can apparently increase visualization of rendering models using OpenGL…
I have read NeHe’s Tutorial #22 about Emboss Bump Mapping and I found that this “fake” technique is really ugly, so now I make an effort to learn Dot 3 Product Bump Mapping, but is quite comlicated, so in this context, would you recommend me a materials to learn, I found a lot of them on nVidia’s web site, but they seem is to experienced developers
thanx
[This message has been edited by rosentzp (edited 11-11-2002).]
Well lights are additive so basically you draw your scene, or even part of the scene if your lights are attenuated…no need to draw the whole scene there, and do the same again for each light, adding the results together. Ron Frazier’s demo shows how he accumulates multiple lights. After a while though it will saturate to white which may look bad and not be what you want, this would be a good time to use HDR or even some approximation. The technique Nutty does in one of his demos would work pretty good there, or even the technique (which is pretty similar to Nutty’s) that Halo 2 uses. Some where on this board Nutty said what that was but I forget ATM.
-SirKnight
Ok I found the page I was talking about way back in page 15.
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/007313.html
-SirKnight
Yep, it’s all multipass. One pass per light to accumulate the totals in the framebuffer. Clamping doesn’t look so bad and you can try to manage the overall total levels if you want minimize the component clamping causing changes to the color. Stuff like shadows takes another pass to fill z before your first light but you can use that for emission terms or ambient for example. The multipass is essential to get different directions on the bump map shading and different results on the shadow testing.
Is there a better way then multipass?
How about 1 copy of the bump map for each lights and then setup the combiners for addition.
Will that be faster? I think it should.
V-man
[This message has been edited by V-man (edited 11-11-2002).]
multipass is not so bad
im doing a bit here http://uk.geocities.com/sloppyturds/kea/kea.html
on my hardware (gf2mx200 little fillrate)
it is possible to draw 2 lights in one pass (and even more with better hardware gf3,radeon etc), but i only draw one light per pass the reason being u can do a better light(ie all the bells + wistles) + its simplier.
the funny thing is on better hardware gf3/radeon 8500 + where u can draw more lights per pass, u find u dont need to, cause the cards are so much quicker that they can handle all the multiple passes at greater resolutions 
anyways. the secret is restricting the amount of area each light ‘lights up’, also stick a cap to the amount of lights that ‘effect’ any mesh. i have choosen 12 (which does sound a bit of overkill but can eaily be reached with huge explosions going off), also choosen the closest/brightest lights (which i current dont do )
Could you guys define which kind of pass you’re talking about? I can draw the scene once with a bunch of lights. The slow part is when I transform the light position to tangent space per vertex. I have to transform each light and add the result to an accumulator per light per vertex. Sooooo slow. Maybe I’m just doing it all wrong and don’t see the obvious optimization?
Maybe there’s another way? I can see in your demo zed that you have colored lights. With the method I’m using it’s impossible to render with colored lights. The bumpmap generated by the DOT3 extension results in a greyscale image that is them modulated with the base texture. With a 2 texture card that’s all you can do with one rendering pass. I had this idea where I could modulate the generated bumpmap with a colored texture and for the second pass blend the two together to get a color…but again that’s sloooooooooow.
I’m going to read that thread you provided SirNight. Brb with comments . This responce is already to big…
Read it. I’m not sure how what was discussed in that thread relates to rendering lights. Maybe it does but I don’t get the 0 to 1 idea.
After reading your explanation again dorbie I see what you’re doing. I’m thinking my way would be faster because I only have to draw the scene once after generating the appropriate color per vertex per light then render the scene once. Your way I would have to calculate the colors for each vertex for every light anyway plus render the scene just as many times. Seems like that would be really slow.
I havent REALLY tried my accumilation thing yet on a large model, but it worked like it should have on a small model…but because it was small it did get pretty washed out with white.
Hopefully I’ll have what I’m talking about implimented into a demo by this weekend or possibly sooner. Then you can tell me if you think the performance is bad or not. I’m guessing the performance will be pretty good for software.
Heh, it’s taken me a long time to even undertand anything involving color. I’m getting better though .
[This message has been edited by WhatEver (edited 11-11-2002).]
Sure you can do multiple lights in a single pass, but it
-
limits the complexity of your lighting equation, complex material descriptions, local lights, specular highlighting attenuation etc all eat up texture stages, and
-
as I already said shadow testing needs to be specific to a light source, if it’s stencil then you’re stuck with a single light per pass, if it’s texture again you’re eating texture stages.
[This message has been edited by dorbie (edited 11-11-2002).]
P.S. Are you doing the Cass ortho illumination maps instead of dot3 bump maps or emboss height maps? That would let you accumulate light contributions at vertices for all lights then apply the ‘totals’ but I think you really start to suffer from the accumulated approximations and you still clamp at 1 which would be a disaster for trying to accumulate the component contributions. I think what you need is to fake out extended range for multiple lights with this method. So half the component contributions at the vertices and multiply by two in a combiner later (or quarter then quadruple). I don’t think anyone had the ortho illumination component maps in mind when responding to your question. Again the approximations will still bite you I think.
[This message has been edited by dorbie (edited 11-11-2002).]
You can do multiple lights in 1 pass, but making an algorithm generic so it works with any number of passes becomes more complex trying to squish it down to multy lights per pass. New hardware is highly optimized for lots of passes, so you’re prolly better off limiting number of textures used and doing multi-pass.
Note that on gf4, 2 passes with 2 textures is alot faster than 1 pass with 4 textures. I suspect NV30 will also be like this.
Maybe you wanna take a look at; http://opengl.nutty.org/bumpy_spec.zip
Which was a generic lighting algo, which works with any number of lights.
‘A’ increases lights. ‘Z’ decreases. Supports upto about 64 lights I think.
Although it does the lighting equation wrong. It sums the lighting values, then modulates with texture. Whereas (according to davepermen) each light should be modulated with the texture and then summed, but that was more expensive.
With regards light blooms, I tried doing the dest-alpha approach, but my algo seemed to have it’s overbright values capped off, which made the plumes look almost white. No huge splashes of color like the previous one. Although I noticed the halo2 trailer, its plumes were nearly all white too.
enough rambling… I’m off to bed…
Nutty
It’s set then. My method doesn’t even work, just tried it . It was a hack just to see what it would look like…sucked bad. Everything was full intensity.
I’m going to digest what you guys have told me. Rendering the scene for every light seems crazy, but I guess that’s the only way 
.
dorbie, I’m using GL_DOT3_RGB.
Nutty, I will check out your code.
I still have a lot to learn before I get bumpmapping with multiple lights to work. Gah!
I’m going to put it off once again. For now I’ll just support one light. I’m off to implimet tri-stripping.
OK, it makes sense that it wouldn’t work, There’s nothing you could accumulate per vertex to make DOT3 lighting work for several lights. Your rgb is either one of several vectors or a base material color.
The only sceanrio where this makes some semblance of sense is Cass’ orthogonal illumination maps which store the partial derivative component illumination results in separate textures. With this approach you could in theory accumulate multiple lights at the vertices and at least have a result consistent with single lights computed individually and accumulated with multipass. It’s an interesting approach for many lights in fewer passes I think.
[This message has been edited by dorbie (edited 11-11-2002).]
>>>With regards light blooms, I tried doing the dest-alpha approach, but my algo seemed to have it’s overbright values capped off, which made the plumes look almost white. No huge splashes of color like the previous one. Although I noticed the halo2 trailer, its plumes were nearly all white too.<<<
OK, once again for those of us who get confused easily
what’s light bloom or light plume???
V-man
http://opengl.nutty.org/effects/index.html
The bottom one. I should probably re-name it. I didn’t know the proper name of them when I wrote it.
Nutty
Those bright flare looking thingys (heh what a description eh?) that Nutty is rendering in his demo. Check it out to see what I’m talking about.
-SirKnight
Originally posted by Nutty:
Note that on gf4, 2 passes with 2 textures is alot faster than 1 pass with 4 textures. I suspect NV30 will also be like this.
Are you sure about this Nutty? It would really surprise me if this was true. You’re cutting out a bunch of redundant transforms, rasterizations, etc by doing 1 pass with 4 textures instead of 2 passes with 2 textures.
Although it does the lighting equation wrong. It sums the lighting values, then modulates with texture. Whereas (according to davepermen) each light should be modulated with the texture and then summed, but that was more expensive.
I wouldn’t say that’s “wrong”. The two methods you describe would be mathematically equivalent if values didn’t clamp. The algorithms will only behave differently when the sum of a color channel would become greater than one.
Adding then modulating will limit your brightness to that of the modulating texture.
Modulating as you add can allow you to go brighter than the modulating texture, however, you will start to get color shifting as different RGB components will clamp to 1 at different times. It depends on what you want the final result to look like.
– Zeno
I’m pretty sure unless I messed something up. I’ll have to try it again as I can’t remember the circumstances. But I lost about 10 frames a second switcing to 4 textures and half the passes.
Yeah its wrong cos of the clamping.