adding some postprocessing in #godotengine some grain vignette and flairs already make it feel more grounded
May 11, 2025 at 6:27 AM
adding some postprocessing in #godotengine some grain vignette and flairs already make it feel more grounded
the addition of SSIL also does not do a lot help here. it is good for other scenes with small scale Illumination though.
May 3, 2025 at 8:23 AM
the addition of SSIL also does not do a lot help here. it is good for other scenes with small scale Illumination though.
looking at SDFGI in godot, the overall brightness of the scene is correct but the resolution is very low, and i could not find a way to give it more sample points.
May 3, 2025 at 8:22 AM
looking at SDFGI in godot, the overall brightness of the scene is correct but the resolution is very low, and i could not find a way to give it more sample points.
i tried different denoising and sampling settings, but when looking inside the boxes, light seems to stop one layer later than in cycles. this prevents overdarkening, but creates leaking
May 3, 2025 at 8:07 AM
i tried different denoising and sampling settings, but when looking inside the boxes, light seems to stop one layer later than in cycles. this prevents overdarkening, but creates leaking
the most notable downside of godots baking is light leaking. especcially under the boxes we get too much light that lacks the darkening expected from corners. this makes the boxes look floaty.
May 3, 2025 at 8:02 AM
the most notable downside of godots baking is light leaking. especcially under the boxes we get too much light that lacks the darkening expected from corners. this makes the boxes look floaty.
if we crank up the settings of the LihtmapGI, we start to get a result very close to cycles. there seem to be only small differences in results. very usable. plus we will get probes and can do a directional bake. although bake time is longer than in blender.
May 3, 2025 at 7:52 AM
if we crank up the settings of the LihtmapGI, we start to get a result very close to cycles. there seem to be only small differences in results. very usable. plus we will get probes and can do a directional bake. although bake time is longer than in blender.
now, inside godot we will try the default settings. for this bounce-heavy scene, the default settings are too low. but we already can see that the overall brightness is in the correct range.
May 3, 2025 at 7:48 AM
now, inside godot we will try the default settings. for this bounce-heavy scene, the default settings are too low. but we already can see that the overall brightness is in the correct range.
BONUS ROUND: baking. i will be looking at the classic cornell box here. first, i will set the ground truth with cycles. when baling in cycles, we get pretty much perfect matching of the diffuse materials here. both when baking combined and when baking direct+indirect only.
May 3, 2025 at 7:47 AM
BONUS ROUND: baking. i will be looking at the classic cornell box here. first, i will set the ground truth with cycles. when baling in cycles, we get pretty much perfect matching of the diffuse materials here. both when baking combined and when baking direct+indirect only.
this is very consistent for low roughness metals. the rougher the metallic surface, the darker godot is compared to blender cycles. (0.25, 0.5, 0.75, 0.9 roughness in the images)
May 2, 2025 at 1:56 PM
this is very consistent for low roughness metals. the rougher the metallic surface, the darker godot is compared to blender cycles. (0.25, 0.5, 0.75, 0.9 roughness in the images)
this can be worked around by using a sky with a grey texture instead of the background-mode. now, we have the same metallic result in both apps
May 2, 2025 at 1:46 PM
this can be worked around by using a sky with a grey texture instead of the background-mode. now, we have the same metallic result in both apps
now another pitfall: when testing metallic materials, even though the background is set to be visible in reflections, it does not affect metallic surfaces in godot. instead, the reflection appears black.
May 2, 2025 at 1:39 PM
now another pitfall: when testing metallic materials, even though the background is set to be visible in reflections, it does not affect metallic surfaces in godot. instead, the reflection appears black.
PLOT TWIST! godots GGX is actually super close to blenders cycles GGX. so we get more consistency between godot and cycles than between eevee and cycles. unexpected!
May 2, 2025 at 6:07 AM
PLOT TWIST! godots GGX is actually super close to blenders cycles GGX. so we get more consistency between godot and cycles than between eevee and cycles. unexpected!
the specular highlight is consistent with a perspective camera, but there are still some differences, especcially in the backlit area. godots specular GGX tends to be sharper at glazing angles than blender eevee's GGX
May 2, 2025 at 6:00 AM
the specular highlight is consistent with a perspective camera, but there are still some differences, especcially in the backlit area. godots specular GGX tends to be sharper at glazing angles than blender eevee's GGX
now, to the specular. at first i was confused as the highlight were in different places, and there were wildly different roughnesses at glacing angles. this seems to be an issue with orthographic cameras in godot.
May 2, 2025 at 5:52 AM
now, to the specular. at first i was confused as the highlight were in different places, and there were wildly different roughnesses at glacing angles. this seems to be an issue with orthographic cameras in godot.
the most used shader is the Pricipled shader though. here, blender matches the godot burley diffuse model closely
May 2, 2025 at 5:19 AM
the most used shader is the Pricipled shader though. here, blender matches the godot burley diffuse model closely
also colors seem mostly consistent although there is a small difference in saturation.
May 2, 2025 at 5:10 AM
also colors seem mostly consistent although there is a small difference in saturation.
as long as we use hex albedo values, brightness is consistent.
May 2, 2025 at 5:06 AM
as long as we use hex albedo values, brightness is consistent.
if we change it to "lambert", we get the same falloff as in blender
May 2, 2025 at 5:03 AM
if we change it to "lambert", we get the same falloff as in blender
lets start with a diffuse sphere: a pure blender diffuse shader import as "burley", which has a different falloff
May 2, 2025 at 5:03 AM
lets start with a diffuse sphere: a pure blender diffuse shader import as "burley", which has a different falloff
Day 2! today i want to go over the material, and compare how the PBR shaders in the 2 engines react. first, i want to create consistent environment lighting. i use hex values for background here, and will use the same sun light.
May 2, 2025 at 4:55 AM
Day 2! today i want to go over the material, and compare how the PBR shaders in the 2 engines react. first, i want to create consistent environment lighting. i use hex values for background here, and will use the same sun light.
for spotlights, the same multipliers for energy and attenuation are correct. but the falloff is not really reproducible as blender has a linear falloff, godot a smooth falloff. the difference is best visible in the curve view.
May 1, 2025 at 10:40 PM
for spotlights, the same multipliers for energy and attenuation are correct. but the falloff is not really reproducible as blender has a linear falloff, godot a smooth falloff. the difference is best visible in the curve view.
my best attempt at matching point light is: divide energy by 2000 again and set attenuation to 2. this gives us a similar falloff to blender in godot. to note: the lambert diffuse model with no specular seems to match blender's diffuse shader the best.
May 1, 2025 at 10:33 PM
my best attempt at matching point light is: divide energy by 2000 again and set attenuation to 2. this gives us a similar falloff to blender in godot. to note: the lambert diffuse model with no specular seems to match blender's diffuse shader the best.
let us try a point light: the default godot import is again far too bright. 100W in blender convert to 5435 in godot
May 1, 2025 at 10:27 PM
let us try a point light: the default godot import is again far too bright. 100W in blender convert to 5435 in godot
this holds true for bigger values: a blender sun of 10 imports as 6830, and will be consistent around 3.415
May 1, 2025 at 10:22 PM
this holds true for bigger values: a blender sun of 10 imports as 6830, and will be consistent around 3.415
instead, we have to reduce the imported value to around .34 to get the same result, a factor of 2000 smaller. this can be part of a post-import script.
May 1, 2025 at 10:19 PM
instead, we have to reduce the imported value to around .34 to get the same result, a factor of 2000 smaller. this can be part of a post-import script.