Render too bright?

Hello Armory community,

I just noticed lately by playing with the last SDK, the objects seem to be rendered a bit too bright since the lasts SDK…

Here’s a simple sphere in the viewport looking like this:
viewport

Looked like this in the SDK2105
SDK2105

And look like this since the SDK2106
( Here rendered with SDK2108 )
SDK2108

I thought that something changed with the way the “occlusion” or the “world_environement” work, but I couldn’t find any notification… Is this supposed to look like this ?

I found that by reducing the “world strength” to 0.1 ( in Blender or by editing this file ) I could make it look like the previous version, but it’s a bit odd having to do that…

Has anybody found this strange too, or knows why the render changed?
Thanks a lot.

(Tested on Linux and Windows with Blender 2.93.2)

2 Likes

Could you please share the blend file you tested it with. That way the lighting, materials and settings are also same when we test.

Best,
QC

Hi QuantumCoderQC, thanks for the reply.

It’s the default scene from Blender. I just replaced the cube with a sphere and turned the viewport mode to “Rendered”, but I didn’t touch anything else.

Untitled.blend (1.0 MB)

Hi, I just installed Armory again from itch.io (so no funky stuff that could break my results), did not mess with any settings, and even my default cube is too bright


So yeah I definitely think this is an issue, it looks like there are no shadows and no light falloff (?).

When using a Sun Lamp the results are as follows:


Enabling Shadow Map Atlasing does not change anything.
Updating to the latest git version shows the same results.

1 Like

Thanks Simonrazer for checking on your side,

I wanted to add some details.
It seems like the Object is too much affected by the “World”, making it looks like it’s emitting light. Which makes the light falloff difficult to see.

Here’s a test with NO “Light”, but a “World”:
(Blender LEFT / Armory RIGHT)
World_ON_light_OFF WorldON_LightOFF

Here’s a test with a “Light”, but NO “World”:
(Blender LEFT / Armory RIGHT)
WorldOFF_LightON World_OFF_Light_ON

Maybe I search at the wrong place but, I tried to compare the code of the two versions, and I noticed some changes were made in the “make_world.py”, but it’s a bit beyond my skills to understand how it affects the code…

1 Like

Yes, that is most probably the issue, the problematic commit seems to be https://github.com/armory3d/armory/commit/656b018e5f73240074f7bbf08514617f6d95f94b.

Originally, (ir)radiance probes were only correctly exported for environment maps, the hosek/wilkie sky model and color-only worlds. This became problematic when Armory got support for more complex world shaders, so now the probes are quickly rendered with cycles in the background and then exported and converted with cmft. There were issues with the brightness and I already made it a bit darker so that it looked correct for colorful world shaders. But it’s still too bright.

I’m not entirely sure how to solve this as I don’t understand much of the spherical harmonics math that is used for the environment probes (thankfully cmft does most of it), but we can probably tweak the brightness here. The old code is still around and I think is even used in some cases. For Hosek/Wilkie skies the coefficients are also divided by 2, for color-only worlds the floats are even multiplied with 1.13. A bit more background information can probably be found in the 2.9 update thread.

But maybe it’s not that easy to just multiply every coefficient by some value, maybe the brightness is not linear at all, I don’t know unfortunately.

The shader code for irradiance can be found here and IIRC it’s directly implementing formulas from some scientific paper. So I don’t think we should do adjustments there.

Edit: According to this vizualization and this blog article it could actually be sufficient enough to multiply band 0 with the wanted brightness.

1 Like

Whoa, Thank you very much timodriaan for this very detailed reponse and explanation :slight_smile:
It’s a lot of info to digest, but I will study those links very carefully.
It’s much complexier than what I was imagining, and way beyond my comprehension yet…

That’s what I thought. I just hoped I could find a value to play with in order to tweak the brightness.
Seems like you found it :slight_smile:

I’m looking forward to see the results.

1 Like

Feel free to play around with the brightness yourself in the code, as I wrote in the “edit” part above it is probably much simpler than I thought at first. There’s also a small chance that something is wrong with the gamma values that are passed to cmft. Unfortunately I don’t have much time until next wednesday but then I can also give it a try :slight_smile:

1 Like

Sure I will.
I don’t have much time either, but I’ll play with it this weekend.
I would like to understand what I’m playing with instead of multiplying band 0 with random values.

Thanks a lot for your help. :slight_smile:

1 Like