Hello,
I wanted to texture a terrain with different textures and set up the following material. In eevee this looks as expected. But in Armory it looks completely different. Not only that one texture seems to be all over the whole terrain it also looks like the RBG channels are flipped.
I´ve read several things pretty close to this problem but not excactly the same. Is this a bug or do I something wrong?
BR J
Hi,
there are two things that come to my mind:
The components of a normal vector can be negative, which means that the separated z value can be negative as well. Maybe that doesn’t behave well with the color ramp node, which then outputs a value < 0 or > 1 to the mix node, resulting in the image above. This could also explain the sharp edges, even though I’m not sure whether all of the wrongly colored pixels have a normal value where z < 0…
To test this, try adding a Math node that calculates the maximum of the z value and 0 and use that for the color ramp input.
Are the colors of the color ramp in a range between 0 and 1 or is the white for example brighter than 1?
Blender probably clamps the mix input between 0 and 1 and Armory could also do this, but it would result in a few more GPU cycles per shader even in cases where it’s not required at all. So I’m not sure if this is something that should be fixed. If it’s caused by the colorramp then I guess we could do something here. I will test it myself later today 
Hi,
thanks for the tip with the math node. It solves it and I got a decent result. But I had to put it behind the color ramp instead of infront.
I am not sure what this says, looks for me that the color ramp output is off, or isn´t it?
I am not sure what this says, looks for me that the color ramp output is off, or isn´t it?
Sounds like that, yes. Are the individual colors in the color ramp in a [0, 1] range? You can’t exceed that range by selecting colors with the mouse, but you could enter larger numbers by using keyboard input:
Here you can see an intensity of 2, which may lead to such issues.
Hi,
yes, I was aware of this and made sure the value where in that range.
Eventough your advise looked promising at first I am not sure if the Problem is really solved by this. I wanted to make sure this is not something my game file messed up, as this happend several times before.
I build a new test file with just a ANT Landscape. Made a new material but this time with just pure red and blue, I tried mix shader and mix RGB, both with the same result. In the background there is a flat plane which should be entirely blue but it isn´t.
Hi, sorry for my late answer. Can you please send me a screenshot of your updated material node tree or a small example file? Then I can have a look at it
Hi,
no problem. Please have a look at the test file. Looks for me Armory3d is still mixing eventough it shouldn´t from one point on.
ANT.blend (2.2 MB)
I’m still not exactly sure what’s causing this, but the issue doesn’t come from your shader. The deferred lighting outputs pixel values larger than 1 and it seems that the compositor shader renders to a render target that doesn’t allow such values, and somehow the blue gets pink that way. It might be a missing HDR -> LDR conversion somewhere or wrong gamma settings, I have no idea yet…
For now, you can disable tonemapping or the entire compositor so that the compositor pass is not run (because in your specific case only tonemapping is used), but that’s of course not a great solution.
Hi,
no big deal from my side. I am just trying different things from time to time and my actual “game” doesn´t need this function at the moment.
But did you really test deactivating tonemapping? On my side there is no difference in the outcome. Neither deactivation tonemapping, the whole compositer nor changing the renderpath made a change.
Shall I mark this as an issue on github? So it stays in mind and you can work on it and when time.
BR
Yeah I tested it and inspected a frame in renderdoc to verify that it’s the compositor shader (the deferred lighting also seemed to add at least some amount of color change, but this might be a HDR display thing in renderdoc), but it may well be that in your local setup something else is causing the issue (or the build was cached for some reason).
Shall I mark this as an issue on github?
Yes please, that would be great Please also attach the example file if possible.
