udk material troubles

joeriv

First problem, wich is actually 2 things at the same time.

Mesh with vertex painting on it.



Left:
DX11, works fine except for the fact that using TC_NormalmapUncompressed I get all these weird white dots.
Switching to DX9 or TC_NormalMap fixes this.

(not a huge problem, if not for the problem in the right image).

Right:
Only in DX9:
As soon as I do anything related to reflections (ruled out the emissive slot, just plugging in a vector3 gives no problems-
my vertex colours completely go away and I can't change them.

even doing a simple "reflection vector -> vector transform -> cubemap"
either straight in the emissive
or lerped in the diffuse (with a alpha of 0 even) gives this problem).


2nd problem:

My alpha expression for the vertex painting works fine for the normal/spec/diffuse.
But as soon as I do it for the specPower it throws this error, it doesn't matter what I put into either A or B (just putting in a constant in both), it only gets fixed by plugging a scalar into the alpha slot.

Obscura

Second: use constant 1, scalar or something that is not a 2,3 or 4 channel vector in the alpha of this lerp.

joeriv

well yes, but that sadly doesn't solve the actual problem.
if I just plug in a scalar, then I might as wel not have the lerp there, because then it won't give a seperate specularPower value for the 2 textures, just a flat value over the whole thing that is a average (depending on the value of the scalar) of the A&B slot.

So maybe there is a reason for it, but I can't really understand why the exact same thing works for diffuse/spec/normal and not for specularPower.

edit: nevermind, thinking about your post I understand it now (plugging in a texture doesn't work, plugging in just the alpha does work).

masking out one channel did the trick, thanks ^^(since my alpha expression is just grey scale values)

Obscura

Because the diffuse/spec/normal can be "colored"(more than one channel) and the gloss is not.

joeriv

hehe yes, just edited in, my brain was a bit slow ^^ thanks, probably would have taken a long time to finally realise it without you mentioning it

Obscura

Np! I dont really know what is causing your first problem(s), but maybe I would try to clamp the normalmap. Just a tip, I'm not sure about this.

Santewi

The NormalmapUncompressed is buggy as hell, if you don't get white dots you'll get black dots.

The solution is to mask out the blue channel in the shader and append a constant value to it. Values between 0.75 and 1 should work fine.

lpcstr

Santewi wrote: »

The NormalmapUncompressed is buggy as hell, if you don't get white dots you'll get black dots.

The solution is to mask out the blue channel in the shader and append a constant value to it. Values between 0.75 and 1 should work fine.

How is that a solution? It's not a normal if you are replacing one of the components with an arbitrary value.

z = sqrt(1 - x^2 - y^2)

Santewi

Its the simplest solution. I know its not the best or ideal in any way, but it works and I think however way you calculate the Z it'll result in the white/black dots in the DX11 renderer.

I don't know what math the shader uses to compute the Z value when using the TC_NormalmapUncompressed, but assuming it's the same as you, wouldn't that just result in the same dots appearing?

mAlkAv!An

First issue, vertex colors and vector transform does not work at the same time.

UDN Quote:

Warning: VertexColor is mutually exclusive with the Transform node due to limited interpolators. If you use both a Transform node and VertexColor, then VertexColor will come out all white.

Checking "Per Pixel Camera Vector" in the material properties will make both work together.

joeriv

That solves all my issues (I'll just stay away from uncompressed normal maps for now).
Thanks a lot for the help/responses

alfalfasprossen

The problem is the way udk internally derives the blue channel from red-green-only normal maps, which is the case if you use uncompressed normal maps, or use the built-in deriveZ node.

The problem is actually that the term under the root may evaluate to a negative number due to floating point inacurracy, which will yield an invalid result, causing fancy errors in DX11 mode.

You can easily built your own way to derive the blue channel, and use the result as the normal input for the shader. lpcstr provided the correct formula to do so, but here is an image that might help, note the clamp before the sqrt

Santewi

I was suspecting the artifacts had something to do with negative values, but what is different between the DX9/11 renderers that causes this?

ambershee

Hard to know the exact cause. It's just one of numerous issues with the Dx11 renderer.