Thank you for the report. This might be a shot in the dark, but could you please try disabling SSS and SSRS if it were enabled in the render path?
Also, what might help is if you could share the project file. You may choose to remove any of your models and node logic. But retain the render path settings and lights. As long as the file has minimum data to reproduce this issue, we can still debug it 
@QuantumCoderQC
Good hypothesis but it didn’t work… I’ve also disabled all the compositor effects and didn’t work either.
Here’s the project file:
https://drive.google.com/file/d/1C6OO7Y-2XtcNaHP0_HrCYOD8dluc1vFL/view?usp=sharing
It’s exactly what I have 
Interesting, for me it works when I completely disable SSS in the renderpath settings, so maybe it’s caused by https://github.com/armory3d/armory/pull/2450. Unfortunately I can’t test your files with SDK commits before that PR since then the export fails with an SSS related error when SSS is enabled. @ QC how did you come up with your hypothesis?
256[.WebGL-0x153400ad7100] GL_INVALID_OPERATION: Feedback loop formed between Framebuffer and active Texture.
This error message from your browser console is particularly interesting, and it matches with what webgl-lint tells me:
https://greggman.github.io/webgl-lint/webgl-lint.js:3086: error in drawElements(TRIANGLES, 3, UNSIGNED_INT, 0): INVALID_OPERATION
WebGLTexture("*UNTAGGED:Texture20*") on uniform: gbufferD bound to texture unit 0 is also attached to WebGLFramebuffer("*UNTAGGED:Framebuffer13*") on attachment: DEPTH_ATTACHMENT
with WebGLProgram("*UNTAGGED:Program23*") as current program
with the default vertex array bound webgl-lint.js:2199:17
reportError webgl-lint.js:2199
reportFunctionError webgl-lint.js:2976
funcName webgl-lint.js:3086
drawIndexedVertices Graphics.hx:640
drawShader RenderPath.hx:481
commands RenderPathDeferred.hx:759 // <-----
commands RenderPathCreator.hx:46
renderFrame RenderPath.hx:144
renderFrame CameraObject.hx:80
renderFrame Scene.hx:263
render App.hx:138
render System.hx:214
animate SystemImpl.hx:588
(Async: FrameRequestCallback)
animate SystemImpl.hx:550
RenderPathDeferred.hx:759 is indeed related to SSS, but I think that it is likely caused by a missing “un-binding” of the depth buffer somewhere earlier in the render pipeline. My first idea was that https://github.com/armory3d/iron/pull/160 does not work with SSS, but the issue also happens if I checkout a commit before PR 160 (for both Iron and Armory repos). So I’m not so sure here, it needs more investigating…
If we could find out what WebGLFramebuffer("*UNTAGGED:Framebuffer13*") is then I guess it is pretty easy to find the cause. I will check whether I can temporarily tag the framebuffers in the Kha backend with webgl-lint.
Hi, I based it on the error messages reported above when the project was run on Krom, which was Uniform lightPlane not found
After a quick search on GitHub, I noticed that this uniform was used only when SSS was enabled. This was from the file deferred_light.frag.glsl at lines 59, 398 and 439
Hope this helps 
The current state of things:
I think I fixed the error related to the depth buffer, at least it can be accessed now from the SSS shader and the error message is gone.
However, I’m not yet able to really verify the fix since there is another pretty difficult issue with the file resulting in an almost completely black scene… I think that it is caused by Armory packing the metallic factor and the material ID into a single channel in the gbuffers to fit all buffer data into two gbuffers.
Since the material in the given scene uses SSS, it has matID 2. It also has a metallic value of 0.0. Packed into a single value, packFloatInt16() from gbuffer.glsl will return something similar to 0.1250019073777371 (I tested it in Python with different precision, tomorrow I will try to see whether I can access the actual 16 bit values in RenderDoc). I also wrote the still packed value into a single channel of another buffer, and it seems to be around 0.125 indeed. However, if you instead pack matID = 1 and metallic = 1 you get a value of 0.12498664835584039, so it’s pretty close to that 0.125. And that’s probably the problem: the unpacking will return matID = 1 and metallic = 1 even though matID = 2 and metallic = 0 were used for packing the values. If you set the metallic value slightly higher it works again. I will continue tomorrow
I confirm that we get the colors back just by disabling the SSS on the material.
Thank you @timodriaan for your detailed analyses!
Playing with the light intensity and world HDRi intensity I got it back to a normal look.
Although if I add one simple lamp, besides the Sun it gives me an error like this:
Blockquote/home/rogper/armsdk/iron/Sources/iron/object/LightObject.hx:51: characters 2-47 : Inline variable initialization must be a constant value
/home/rogper/armsdk/iron/Sources/iron/object/LightObject.hx:52: characters 2-68 : Inline variable initialization must be a constant value
I’m pretty sure that this is due to the unities being in Watts 
The original number must be some kind of float, so that’s probably the reason for this.
Another mysterious thing is that the full-screen support apparently doesn’t work anymore:
I got it in presentable condition once again… but full of movement issues now 
I just forgot everything I did back then… in this method.
Back to the fixing someday!
Here’s the most updated file:
The original issue with SSS should be fixed when https://github.com/armory3d/armory/pull/2553 is merged, I will take a look at your other issues tomorrow
This seems to be a bug in the Haxe compiler, I’ve opened an issue for it: "Inline variable initialization must be a constant value" despite -D no-inline · Issue #10779 · HaxeFoundation/haxe · GitHub. For now you can enable Armory Exporter > Compiler Inline (which is the default and it’s a good idea to keep it on in most cases) and it will work again. Even if the Haxe issue is fixed soon, it will probably take a while until it is included in Armory since first Kha needs to update the Haxe version and then Armory needs to update the Kha version.
Works for me on both Krom and html5 in Firefox (the latter is not full-screen as in “whole monitor” but it at least fills the browser window. I think true full-screen from the very beginning is probably not supported by browsers). So I think it might be an issue with your browser or perhaps a Kha issue.
Thank you very much @timodriaan!
I understood about the lamps issue, thanks!
Regarding the full screen previously was working perfectly on all equipment, even on Firefox for cell phones! Would always fill the window on Chrome (Opera and Brave) and Firefox.
Even now the old version online still does that: https://rogper.github.io on the same browsers that the new version doesn’t work.
