Normal maps broken

[ghost]

It looks like normal maps on terrain are broken, when I add them nothing changes, instead there is ugly graphic artifacts: http://duion.com/files/temp/screenshot_TG_DirtPit_day001-00001.png

I noticed it is not only on terrain but on other shapes as well, producing similar graphic artifactsm, the normal maps do something, but it does not look right.

[VinnyVicious]

Confirmed on 3.9.

[Areloch]

Can you link me to the textures you're using so I have the exact reproduction case?

[ghost]

I think any will do, the one I used on the screenshot is this https://github.com/Duion/Uebergame/tree/development/art/terrains/slope And where I noticed the normal maps on regular shapes were broken was on these models https://github.com/Duion/Uebergame/tree/master/art/shapes/barriers/inflatable/inflatable_barriers_01

[ghost]

I think the feature that made the normal map ambient darker, if you change the ambient light to darker was broken as well, it recently got added from BeamNG I think, but now seems broken again, since the normal maps do look very flat and not as crispy as in 3.8 apart from them being broken with those glitches occasionally.

[ghost]

The normal maps are broken in dx9, dx11 and opengl, so it is not just one renderer that causes it.

[RichardsGameStudio]

It seems that it is caused (at least in some instances) by the part in: Var* GBufferConditionerHLSL::_conditionOutput( Var *unconditionedOutput, MultiLine *meta ) where the depth is encoded into 2 channels (line 360-369)

I manually removed the multiplication float2 part from the shader of a material which had this issue, which resulted in a correct rendering of this material (but this certainly is no working method).

Changing this in the engine (line 367) is not an option, this resulted in other unwanted behavior for materials that are correct. The material that I had an issue with contained glowing and subsurface scattering. Don't know if the problem with terrains issue #1740 has a relation with this.

[Azaezel]

From what I've been able to determine thusfar it is indeed related to multipass scenarios and gbuffer referencing. terrain with >3 layers for instance having to have a second blendpass, or a model with two layers only the first of which contains a normalmap both wig out in a similar fashion.

[ghost]

I fixed it on the model by just adding a normal map into the second UV layer as Azaezel said, but that is not possible with terrain.

[RichardsGameStudio]

Confirmed. Adding a normal map into the 2nd UV layer fixes this issue for shapes.

[ghost]

So my paintball barriers were just an exception since they were the only shapes using a second UV layer since they use reflections. All other shapes were fine. So normal maps overall are not broken, mostly just the ones on the terrain and that one exception in case you use a second UV channel and do not add a normal map as well.

[RichardsGameStudio]

It seems so. It might be a nice addition when the engine adds the normal map from the first layer by itself if none provided in the second...

[ghost]

It worked fine before in 3.8, so I don't think that is the issue, the issue appeared in 3.9

[Azaezel]

10-1 it'll be related to https://github.com/GarageGames/Torque3D/search?utf8=%E2%9C%93&q=meta-%3EaddStatement%28+expandNormalMap%28+texOp%2C+bumpNormDecl%2C+bumpNorm%2C+fd+%29+%29%3B and related. still re-re-re-reviewing that, though if folks want to stick more eyes on it, by all means.

[RichardsGameStudio]

Don't know if that is the case. I just compared the 3.9 files to my old build (which was Torque1.2 (yes I know) updated to almost 3.5) and the expandnormalmap method and the TerrainNormalMapFeatHLSL parts are practically equal.

[RichardsGameStudio]

Regarding the terrain problem, see remark at #1740 concerning GBuffer conditioning.