armory3d
Microshadowing ssr
Concerning microshadowing and ssrs, when a point light is present in the scene, the sampleLight() function is used, which takes extra parameter in this case but that were not passed.
Same than for the water_ssr branch, I've deleted changes on top of commited changes, that's why original files appear on the changes list.
that's why original files appear on the changes list.
Not only the files appear, but also the original changes, so this PR still includes changes to the water etc. Depending on which PR is merged first this doesn't matter, but otherwise this will lead to PRs with no changes if this one is merged first.
Ok, I did not manage the commit list as well as with the water pass pull request, but it's readable.
It is fixed for me. The last Issue i'd like to deal with is about tesselation active and a translucent material with no textures. Also I changed the title since when using clustered lighting, it's not only point lights that cause problems.
I don't get it why sample light is called inside make_mesh and make_clusters when there is a deferred_light_frag.glsl that seems to do the work. I tried deleting the statements from the code and the result is that there are not crash and the materials still get the correct lighting. I'm closing this.
I don't get it why sample light is called inside make_mesh and make_clusters when there is a deferred_light_frag.glsl that seems to do the work.
Because there is also a forward render path for example that makes use of this (in make_mesh.make_forward_base()).
Ok, but the translucents materials are calling make_forward_base() even though the deferred renderer is used. Should it not check for rp_renderer before writing sampleLight() to the shader ?
So I understand translucent is treated apart from the other shaders when using deferred renderer. I don't get it why the written shader has precedence over the deffered_light_frag.glsl, I did not really dive into Iron code.
I picked the normal from the deferred_light, since the default one cannot be used for microshadowing,
frag.write('n /= (abs(n.x) + abs(n.y) + abs(n.z));')
frag.write('n.xy = n.z >= 0.0 ? n.xy : octahedronWrap(n.xy);')
Not setting it this way for microshadowing in forward render does a strange thing like the parts that are supposed to be lit get darker instead.
Last commit to this is:
if '_MicroShadowing' in wrd.world_defs and (transluc_pass or rpdat.rp_renderer == 'Forward'):
vert.add_out('vec2 texCoord')
vert.add_out('vec3 viewRay')
Forward default shaders don't get texCoord nor viewRay needed for microshadowing. This clause is needed only for the translucent pass with deferred renderer.
I also fixed the tesellation issue with translucent materials and deferred render, and with forward render (wvppositon undeclared). Since they are kind of intricate with this pull request i'll wait for you to merge before presenting it.
I don't get it why sample light is called inside make_mesh and make_clusters when there is a deferred_light_frag.glsl that seems to do the work.
Because there is also a forward render path for example that makes use of this (in
make_mesh.make_forward_base()).
So why using make_forward_base for translucent materials when in deferred mode ? Could check for renderer and use make deferred ?
I don't get it why the written shader has precedence over the deffered_light_frag.glsl
So why using make_forward_base for translucent materials when in deferred mode ? Could check for renderer and use make deferred ?
No, because translucent materials are forward rendered even when deferred rendering is used for all other materials. If it wouldn't be that way, objects behind translucent materials would not be rendered correctly, since an translucent shader would override the fragements/pixels of objects behind it on the gbuffer.
In forward rendering, each object calculates the lighting in its own shader, whereas in deferred rendering all objects draw their normals, colors, etc. to a gbuffer that is then used by the deferred shader to calculate the lights (so the deferred shader is usually only executed once). This reduces the computational complexity by a lot.
Ok, got it ! Also I'd like to raise the matter about IOR, which seems uneffective.
Also I'd like to raise the matter about IOR, which seems uneffective.
Can you please elaborate? If you are talking about the IOR input of one of the shader nodes, then I think it's simply not supported right now (see https://github.com/armory3d/armory/issues/1526).
Also I'd like to raise the matter about IOR, which seems uneffective.
Can you please elaborate? If you are talking about the IOR input of one of the shader nodes, then I think it's simply not supported right now (see #1526).
No, I think the principled shader's IOR field is not taken into account when alpha is not set to 1.
Ok I got your wrong ? So only the fresnel input is supported ?
Sorry for my late answer, the linked issue is specifically about the refraction shader node, but in general there currently is no refraction support independent of the shader node used. So yes, I think only Fresnel IOR is supported right now.
Sorry for my late answer, the linked issue is specifically about the refraction shader node, but in general there currently is no refraction support independent of the shader node used. So yes, I think only Fresnel IOR is supported right now.
Ok, I'm assigning myself to it.
I'd like to work with the old files containing voxel GI and merge with main while done. But I'm facing various issues, specifically because blender is too new and some functions changed. It's a matter of tweaks but for the python syntax (from 2 to 3) it's harder for me.
I have already done all the necessary corrections to run branch 19 on blender 2.93lts but it renders a black screen #2549. So I am trying with blender 2.79 which doesn't need any changes save for the armory.py script. And this error is blocking me:
found bundled python: /snap/blender/20/2.79/python
Traceback (most recent call last):
File "/snap/blender/20/2.79/scripts/modules/addon_utils.py", line 331, in enable
mod = __import__(module_name)
File "/home/i20/.config/blender/2.79/scripts/addons/armory.py", line 153
sdk_path: StringProperty(name="SDK Path", subtype="FILE_PATH", update=sdk_path_update, default="")
^
SyntaxError: invalid syntax
I don't know what these columns ":" are used for in python3, I replaced them with an assign symbol "=" and it'd be running if not stuck on these same columns in a function declaration's arguments. In anyway I just want to see the voxel gi in action and I know you can't roll back to 2.79, but I'm clueless about the black screen, it's like a iron error with no log (maybe regarding irradiance).
Ok my issue is with the function getFloat32 from Float32Arrays, It doesn't want to be called and states that it is not a function I guess the square bracket calles .get() which calles the master static class' getFloat32() and is wondering if not declaring these Arrays static are the issue.
I'm leaving this thread and am awaiting for answers on #2549
About IOR, I am still trying to unearth voxelgi, and the refraction should come with it. But maybe i'm lazy and postponing this part of work I auto assigned to.
What did you want to fix with this PR? Maybe you can open an issue for it so that we don't forget about it. Also the glsl error from https://github.com/armory3d/armory/issues/2520 is still not fixed since you closed https://github.com/armory3d/armory/pull/2531. Should we reopen #2520 then?