Shader fiddling (getting rid of blue)

Gestalt

As some may know I hate the blue channel in bump maps, and so I have spent some time fiddling to get rid of it (completely, no deriving it nonsense).
Here's a wip of the fiddling so far:

(image down: not accurate for use)

It's very loosely based on the idea of a 'derivative' map. I have absolutely no idea how good of a lighting model it is or how it is on performance, but it gives me bump detail with no blue channel (and no derivenormalz).

Ace-Angel

Haha, awesome, I just thinking about this, nice!

I'm interested on how it looks with a Compressed setting for the Normal map. So far I know Ashikhmin-Shirley is somewhat gets rid of the nasty artifacts for the Normal/Spec combo when they're compressed, I was wondering if this could be a cheaper option.

Vailias

you are doing some really funky math there, but if you like the results then good on ya.

Gestalt

Yeah it isn't too pretty right now :poly124:. Basically what I'd like to do is add the x and y values stored in a map to the x and y values (ndotl) of the surface and have them multiplied together to equal some type of lambert bump shading. Right now I'm sort of fudging that for various reason and need to iron things out.

Because of the way I'm using the light vector the light appears as it should on the front but also on the back as if it went through the surface (the x channel ndotl of the light vector goes around a sphere 1 to 0(front) to -1 to 0(back) and back to 1, when what I need is for the values to progress like radians would (0 progressing to 2pi, and 2pi and zero being treated as the same). Maybe this is a sign I should avoid ndotl until the end.

Right now I'm adding the clamped(negative) blue channel of the light vector at the end to make up for the fact that the reverse side is positive (and I can't just make the opposite side negative while also preserving the spirit of the shader!). Delete the blue channel stuff tagged on at the end and that's what I really have.

Edit: based on the fact that the 'derivative maps' go from -1 to 1 I've been treating them more as 'cos(theta) maps' and have been testing with one. On second look I'm almost certain the light vector this way isn't right; I'll have to figure things out tomorrow. Really all I want would be the x and y 'shading', or some better way of getting the light rotation.

Vailias

Well, standard normal maps range from -1 to +1 also.

Also I have no idea how your dot products are doing anything with the output of those mask nodes. The mask should function like the hlsl component swizzle, just outputting a floating point scalar. The dot product is only valid between vectors, so something has to be constructed there. It may be a 3 vector of all the same value, or some other thing. I'd have to look in the code window to see how UDK is resolving that.

I'll look this over more when I get a bigger screen and I can make heads or tails of what you're after.

arrangemonk

why no blue channel?
the typical comression issues or what?

Xendance

Why not use the normal map uncompressed compression option for normal maps? It only has red and green channels and the engine derives the blue channel under the hood without requiring any work from the material artist.
Edit: I'm not sure what the goal here is at all >_>

WarrenM

Might be to use the blue channel for something else? Masks and what-not? Less textures loaded is always good...

cptSwing

y u no use derivenormalZ?

Gestalt

Yeah the dot product masks are where the above is being fudged. I couldn't think how to get the angle of the light vector in an efficient way to work with so I sort of did something that generally worked for testing, but is not reliable or even lambertian at all (although I think I figured out some cool things and realized some relations after the fact that are actually making it work here).

The above is fiddling but I think I'll get more serious about it and try an 'azimuth' angle idea. Using the camera vector and making it view dependent should help me get over things with the light vector.

As for why not derive the blue channel; one I don't like the cost of it and two I'd like to go through the entire process of how the map is being used (as in the way the map adds together and is used for shading). Also the channel can be used for other things like as a compressed heightmap in every bump texture to use for masking and bump offset.

I realized a few sin cos mix ups that I'm going to mess with.

Edit: yeah it seems in an interesting quirk, the map and the abs(x) 1-x is what makes the shading work (it seems like some type of sin vs cos thing).

Ace-Angel

That would be so awesome, getting to use the Compressed Map without the nasties popping in.

Gestalt

Ok so I've decided I'll take the derivative mentality (it's cleaner and it makes more actual sense). So far I'm treating the derivative maps as a -sin(theta) map (edit: cos(theta) map) and the plan is to add this to the -sin(theta) between the light vector and the normal (maybe crossproduct or something? or I could do a custom node...) and use the combined slope info to make the shading.

Vailias

Cross product will return a vector perpendicular to two existing vectors. Not likely the operation you're looking for.

Still not really sure what you hope to gain from this that couldn't be nearly achieved by simply masking the red and green channels of the normal map then appending a constant for the blue like 1

Still good luck on your endeavour and glad you're learnIng stuff

Gestalt

Still not really sure what you hope to gain from this that couldn't be nearly achieved by simply masking the red and green channels of the normal map then appending a constant for the blue like 1

Yeah that's what I'll be doing for now because I really need to get back to working on art! When I have time again I'll refresh on some math, mess around with a few ideas, and try out a few different approaches. The blue channel will be an appended 1 until then.

commander_keen

UDN says the DeriveNormalZ node just does sqrt(1 - (x * x + y * y)) which is quite cheap. Technically I think it should use the spherical length on a unit sphere instead of linear length but I dont think the difference would be noticeable.

Vailias

Keen: It needs to keep the normal value as a normalized vector, ie length 1, and its coordinate systems are all Euclidian. Hence the standard Pythagoran implementation.

Brice Vandemoortele

er... code? images? please

Gestalt

In the end it seems like the derivative map interpretation would be the way to go if you were doing this as it has a lot of room to manipulate and use them. For code on that you can go to Mikkelsen's blog http://mmikkelsen3d.blogspot.com/

I wanted to make a map that was farther along in terms of what it computed, but obviously that's generally a bad idea. I believe there was some correlation between the normalized normal map and the cos(theta) that I was interested in, but I didn't pursue the idea for long. I'd say just look into the derivative approach if you want to 'properly' get rid of blue as it has actually been worked out very thoroughly. I was mostly messing around and brainstorming here.