hehe, i had scene without light, but it anyway was looking like there was little light, just because of pbr lightprobe.
Yeah it is slightly, but if there’s a brighter light probe around, then it seems like the brightness of the DirecionalLight is irrelevent and the scene will always be as bright as the LightProbe - unless you manually scale the Light Probe down with the FilterColor based on the time of day
I’m just guessing from my own tinkering around with the PBR shader, but it seems like the shader mainly uses the DirectionalLight’s direction to provide a reflective glare when you look at the sun from certain angles and to darken triangles that are facing away from the sun. And then the majority of the lighting color and brightness comes from the light probe.
Yeah, in my case I only had one generic light probe called “studio”. A general purpose indoor light probe.
…but I easily was able to get everything to be pitch black if I wanted.
I’m curious how you achieved this with the light probe still around, I could not get my scene to be pitch black until I modified the shader to use the FilterColor and set a value of (0,0,0,0) to essentially turn off the light probe
I set directional light to black set my ambient filter to black. I could not see anything except my debug shapes.
I will try to see if I can duplicate it again in space bugs where I tested it.
Oh my bad I must have misunderstood, I thought you meant that you got the scene pitch black before you added support for the ambient filter in your shader.
Can you please share the code for this ?
Yeah I can, although my shader is a bit messy and has lots of things commented out that I’m working on, so I’ll highlight the relevent parts in regards to scaling the light probe’s color and brightness.
The important part here is assigning the
probeColorMult based on the ProbeColor
And then finally using those values to multiply the computed value for inderect lighting
I also played around with setting a minimum value for the timeOfDayScale (which is why it turns into a new variable called factoredTimeOfDayScale at the end). That way I was also able to adjust the minimum brightness depending on wheteher shadows are on/off so that players can’t gain an advantage in the darkness by turning shdaows off
Here is my PR based on Paul example:
Note, I changed FilterColor type from Vector4f to Color.
I wonder if the name is ok. As implemented, it’s technically just an ambient color or ambient filter.
I went with the name “ProbeColor” since the value is used solely to scale the LightProbe and no other lights
My previous PR swapped with a more neater solution which does not use a new material parameter, instead it uses the AmbientLight color.
Here is the new PR:
Thanks so much from dear @nehon for his helps.
as i see it was material paremeter before named FilterColor and now its AmbientColor. (i agree much better name)
if not defined, do nothing because of “#ifdef AMBIENT_COLOR”. so noone need to worry.
well done sir.
Note, this was in my previous PR (which was dropped) , in the new PR we do not have any of those (user do not need to set any parameter on material). One just need to add a JME AnbientLight to scene and that’s it. By changing color on ambient light you will be able to control the brightness and color of the light probe. This is very useful for simulating day/night light and any use case where you don’t rebake the probes every time the ambient color needs to change.
then its wrong imo. i think Nehon or whoever designed it, i think it was intentional to make AmbientLight dont affect PBR things by default.
i understand i can have 2 nodes, one for PBR things, and one for non-pbr and add ambient only for non-pbr.
but imo it sounds wrong, because PBR material, when it will receive default ambientLight will just be too bright(because it also receive color from envmap + DL specular). Also depends how people use ambient light - someone might make it main light, other would make it almost black.
imagine now person, who make ambientLight his main light source. so he add PBR material → it receive bright envmap metalness color → already bright → it is now multiplied by ambient → even more bright → specular → even more.
so after this update, everyone who use ambient and PBR will wonder why PBR models are so bright.
i dont say its totally wrong, but there should be at least additional parameter for PBR like
“receiveAmbientLight” that would be default set to false(not defined)
this is just my opinion, i played with PBR material a lot last time and was thinking why it was designed this way.
anyway i would need test it and check if im correct.
Note, Nehon himself suggested to use this way, You can read our discussion here, you can also ask there if you have a question:
So if you want some models get ambient light and some not you can just use separate nodes for them as you already mentioned.
Not sure what you mean by this,
this is how ambient color is applied in PBR :
#if USE_AMBIENT_LIGHT color1.rgb *= g_AmbientLightColor.rgb; color2.rgb *= g_AmbientLightColor.rgb; color3.rgb *= g_AmbientLightColor.rgb; #endif
So if you add a white ambient light (1,1,1,1) there wont be any change in lighting as it will come 100% from probe.
ah, ok, then sorry. I misunderstood this.
but do this mean when i use AmbientLight 0.2,0.2,0.2 it will scale pbr overall color brightness to 20%?
i already use low ambient brightness and higher directional light. will there be any problem?
as i look at code it just Affect metalness color? it is main color source for pbr.
anyway if you say Nehon suggested this, then it need to be fine
I believe yes. (only the indirect lighting which comes from probe not the directional lighting)
so looks like mixing Phong and PBR using ambient light will be like impossible without using separate light nodes.
because 0.2f is ok for phong, but too dark for PBR, while 1.0f too bright for phong, while normal for PBR.
i already have separate nodes for pbr and phong, so no problem for me. but i assume some people could not know what going on with their PBR models that are too dark.
anyway its ok for me. this sounds fine. just need split light for both nodes