Why is there significant difference in the rendering result, if I use glBlend(GL_ONE, GL_ONE) and rendering one light in one pass, than rendering all lights in one pass?
Can I somehow reduce this difference?
If needed, I can upload some pictures.
Csikido you mean you have 2 methods of rendering, both using additive blending:
Originally posted by knackered:
[b]do you mean you have 2 methods of rendering, both using additive blending:
- render all geometry with all enabled standard opengl lights enabled
- render all geometry once for one standard opengl light, and repeatedly render for all remaining enabled lights (enabling/disabling one light at a time)
?
In which case, the summing up of the light contributions is being done at the vertex level in method 1, while at the pixel level in method 2.
I’m surprised it makes much difference.[/b]
Yes…
Rendering 2 pass, 2 light (normal + ambient), with shadows: www.fazekas.hu/~csiki/pictures/Clipboard01.png
Rendering 2 pass, 2 light (normal + ambient), no shadows: www.fazekas.hu/~csiki/pictures/Clipboard02.png
Rendering 1 pass, 2 light (normal + ambient), no shadows: www.fazekas.hu/~csiki/pictures/Clipboard03.png
Rendering 1 pass, 1 light (normal), no shadows: www.fazekas.hu/~csiki/pictures/Clipboard04.png
Csiki
It seems to me you have ambient lighting that you do not switch off in the second pass.
So you get A+L1+A+L2 instead of A+L1+L2
Originally posted by tfpsly:
It seems to me you have ambient lighting that you do not switch off in the second pass.
So you get A+L1+A+L2 instead of A+L1+L2
No. I have only L1 and A (this is the L2).
I render first L2, than L1 (blenging).
The other just simply render at once L1+l2.
The code looks like this:
void Renderer::rdRenderEntities(LightArray* pl, EntityArray* pe)
{
mrdContext->conlDepthFunc(false, true, base::sEqual);
mrdContext->conlBlend(true);
uint32 fb=0;
while (fb<pl->arrGetLength()) {
uint32 fr=math::umin(pl->arrGetLength()-fb, MAX_LIGHT_UNITS);
for(uint32 idx=0; idx<fr; idx++)
mrdContext->conlAddLight(idx, (*pl)[idx+fb]->ltsGetLightData());
if (fr!=MAX_LIGHT_UNITS) mrdContext->conlLightDisableFrom(fr);
fb+=fr;
rdObjects(pe);
}
/* More pass algorithm. Should give the same result...
*/
/*for(uint32 idx=0; idx<pl->arrGetLength(); idx++) {
mrdContext->conlAddLight(0, (*pl)[idx]->ltsGetLightData());
rdObjects(pe);
}*/
Csiki
i think the difference is due to the color buffer. it have limited resolution (0…255) for each channel. when image is computed with all the lights at the same time, the color is computed using float which have more precision.
Very true. But would that result in something really noticeable?
Originally posted by knackered:
Very true. But would that result in something really noticeable?
Would somebody so kind to make an independent test? 
Csiki
I’ve never noticed the difference even with 8 lights. You can get different results because with 1 pass the light result may be clamped prior to texture multiplication and multipass you sum the texture multiplied lighting results - so you can burn past the texture values.
Here this is definitely not the case, there must be an error in Csiki’s code.
Csiki, What’s your global ambient light parameter? Make sure to set it to black in all but the first pass.
glLightModelfv(GL_LIGHT_MODEL_AMBIENT, pcolor)
Originally posted by Madoc:
[b]I’ve never noticed the difference even with 8 lights. You can get different results because with 1 pass the light result may be clamped prior to texture multiplication and multipass you sum the texture multiplied lighting results - so you can burn past the texture values.
Here this is definitely not the case, there must be an error in Csiki’s code.
Csiki, What’s your global ambient light parameter? Make sure to set it to black in all but the first pass.
glLightModelfv(GL_LIGHT_MODEL_AMBIENT, pcolor)[/b]
Should bee always (0, 0, 0, 0), but I’ve to see it.
Originally posted by Csiki:
Should bee always (0, 0, 0, 0), but I’ve to see it.
Arrgh. Thank guys.
I’ve thought I turned off any idiot default light. I’ve wrong.
Originally posted by Csiki:
[b] Arrgh. Thank guys.
I’ve thought I turned off any idiot default light. I’ve wrong.
[/b]
So, once again.
I’ve thought I turned off all idiot default light. I was wrong.
I will never learn this language.
I shall attempt to rephrase your sentence:
“I thought I’d turned off all the idiot default lights. I was wrong.”
It’s a bugger isn’t it? OpenGL’s global ambient is set by default to a very dark grey. I used to be thankful of this, because if it defaulted to absolute black I would have torn my hair out thinking that my drawing code was wrong…guess that’s why it defaults to dark grey.
Maybe defaulting to purple or bright green would be better.
Originally posted by knackered:
[b]I shall attempt to rephrase your sentence:
“I thought I’d turned off all the idiot default lights. I was wrong.”
It’s a bugger isn’t it? OpenGL’s global ambient is set by default to a very dark grey. I used to be thankful of this, because if it defaulted to absolute black I would have torn my hair out thinking that my drawing code was wrong…guess that’s why it defaults to dark grey.[/b]
I think it’s for beginners, who want to see something very quickly and don’t want to set up everything.
But when you step one forward you have to be very carefull because of this things…
It would be very good to have a doc about the default values which aren’t normal (like this ambient light).
(0.2, 0.2, 0.2, 1.0).
that’s the default.
This is why I explicity setup every (most anyway) GL state.
Why? Because you don’t know the defaults?
Seriously, of course one should explicitly set the opengl states at initialisation - your state manager should do this automatically.