Material vs Instance

[Crusha K. Rool]

I currently have a problem with my Materials. I set up a big MasterMaterial to save some work, but somehow the results don't look the same like when I create a separate Material for them, although the properties in the MasterMat's Instance are set to be exactly the same as the Material I use for comparing.

This is the result:


One the left side is the MasterMaterial's Instance Constant, which is way too dark and on the right is the real Material.
[SHOT]http://img222.imageshack.us/img222/9084/instvsmat.jpg[/SHOT]


I have no idea how that could come, nothing is different in the way both Materials use the resources. If wished, I can post more screenshots about the layout.

The only real difference might be that the MasterMaterial is set up to allow DetailNormalMaps, but the problem still exists when I disable them. Anyway, maybe something is wrong in this layout?

[SHOT]http://img64.imageshack.us/img64/690/normallayout.jpg[/SHOT]

[Fartuess]

well... it probably have something in common with detail normal maps. I had problem with dark materials caused by some stupid engine mistake (after cooking of level texture sample node lost path to detail normal map texture and aplied one of engine textures, which was grey). So maybe in your case engine do same thing - lost path to texture and apply other- random one.

Or... maybe not... :P

[Wyldhunt]

Detail textures tend to darken the material because the Diffuse texture is usually multiplied by the detail diffuse texture. You didn't show that part, but that's how it's usually done. There shouldn't be much change as long as both materials are exactly the same.

One thing I did notice: When you tell it not to use normals, it uses 0.0,0.0,1.0 to plug in to the normal slot. That will darken things. 0,0,1 is not 'Flat'. That is the deepest depression that normals will allow. You should be using 0.5, 0.5 ,1. That's an actual flat surface at the base model height for a normal map, and should prevent some odd shading issues.

[mslaf]

Detail textures tend to darken the material because the Diffuse texture is usually multiplied by the detail diffuse texture. You didn't show that part, but that's how it's usually done. There shouldn't be much change as long as both materials are exactly the same.

One thing I did notice: When you tell it not to use normals, it uses 0.0,0.0,1.0 to plug in to the normal slot. That will darken things. 0,0,1 is not 'Flat'. That is the deepest depression that normals will allow. You should be using 0.5, 0.5 ,1. That's an actual flat surface at the base model height for a normal map, and should prevent some odd shading issues.

- Diffuse details maps are obsolete and with detail normal maps practically invisible == useless.

- 0,0,1 is correct, 0.5,0.5,1 is not. Normal is a vector not a scalar.

- Your material is fine, the problem must be somewhere else.

BTW: You can zero the Up component of the detail normal map (B:127), so you won't have to do it the expression tree.

[Wyldhunt]

- Diffuse details maps are obsolete and with detail normal maps practically invisible == useless.

The question was about what could be causing the darkening. If they are using detail diffuse, it will darken and they did not show that part of the material. Obsolete or not is irrelevant. If they are using them, it will darken just as much regardless of common or current game making trends. I pointed it out because I did not know if they were using that technique or not.

- 0,0,1 is correct, 0.5,0.5,1 is not. Normal is a vector not a scalar.

Do a Google search for 'Neutral Normal Map' and start reading the results. You seem to be in a distinct minority in believing that.
http://www.game-artist.net/forums/sp...l-mapping.html
http://wiki.polycount.com/NormalMap#Tangent_Basis
etc
Or, just use any normal map plugin to make a normal map on a flood-filled 128,128,128 square. It will always be 128, 128, 256.
Your vector math for Up may be correct, but the important part is how the engine will make use of that vector.
This is an answer that I came to, not from vector math. It comes from experience with UDK and how it interprets normal maps. Apparently, 0.5,0.5,1.0 for flat is an industry standard. Hence the plugins giving that result.
I had this exact same problem when I was making my master material. I did the exact same thing. 0,0,1 seems like it should be correct. All of my materials were dark, just like in the picture. I finally decided to make a flat normal texture with a PS plugin and noticed the 0.5,0.5,1.0. With that, all of my materials lit up to where they should be and all of the odd shadow issues disappeared. I'm not saying your math is wrong. Only that game engines don't seem to work that way. It almost acted as though all of my light was reflecting straight up into the sky instead of straight away from the object. 0.5,0.5,1.0 seems to be the industry standard to get a good flat reflection when viewed from most angles.
Although, Normals are vectors. We agree on that.

- Your material is fine, the problem must be somewhere else.

That is likely if it happens when the normal maps are enabled. The shader is set up correctly.

BTW: You can zero the Up component of the detail normal map (B:127), so you won't have to do it the expression tree.

I'm not following your point here. If you're saying that they can replace the appended 0 with a 0.5 in their detail map, then you are incorrect. That would just decrease their normals depth. When they add the detail map to their primary map, B would = 1.5. When it normalized the map, all of the normals would be shallow because of it.

[mslaf]

The question was about what could be causing the darkening. If they are using detail diffuse, it will darken and they did not show that part of the material. Obsolete or not is irrelevant.

The only real difference might be that the MasterMaterial is set up to allow DetailNormalMaps. Assuming that the 'real' term doesn't cover any other differences, you're correct.

Do a Google search for 'Neutral Normal Map' and start reading the results. You seem to be in a distinct minority in believing that.
http://www.game-artist.net/forums/sp...l-mapping.html
http://wiki.polycount.com/NormalMap#Tangent_Basis
etc

Do a Google search for 'HLSL Normal map' and start understanding the steps and math that are behind it. You will notice the difference between extracting normal vector from the texture sampler and providing it as a vector. The neutral normal vector is 0,0,1! 0.5,0.5,1 is a normalized color value 127, 127, 254 that represent a natural normal vector but it's not a normal vector.

I'm not following your point here. If you're saying that they can replace the appended 0 with a 0.5 in their detail map, then you are incorrect. That would just decrease their normals depth. When they add the detail map to their primary map, B would = 1.5. When it normalized the map, all of the normals would be shallow because of it.

Again, learn the difference between normal map vector and its color representation, normalized or not, because you mixing those things all the time. 0,5 is normalized color value 127: 127/254 = 0.5. The normal vector for this color value is 0.

If you provide a detail normal map that has the up vector component set to zero, then you won't have to do it every render call, which means it will be faster to render.

[Wyldhunt]

The only real difference might be that the MasterMaterial is set up to allow DetailNormalMaps. Assuming that the 'real' term doesn't cover any other differences, you're correct.

The reason why I mention diffuse detail textures when there is any chance that a diffuse detail texture may be causing an issue is because Epic uses detail diffuse as their examples all across UDN, which is where most of the UDKers go to learn how to use the ME.
http://udn.epicgames.com/Three/Mater...Detail Texture
http://udn.epicgames.com/Three/Terra...istance detail
As long as Epic is teaching everyone to use diffuse detail, there is a decent chance that a fair amount of them are going to be using it.
In fact, I still use detail diffuse on a lot of my terrain materials that don't use normals as a way of eliminating tiling. I layer 3 different sizes. Until Epic teaches everyone to only use normal detail, it is relevant to include diffuse detail information when offering debugging advice.

Do a Google search for 'HLSL Normal map' and start understanding the steps and math that are behind it. You will notice the difference between extracting normal vector from the texture sampler and providing it as a vector. The neutral normal vector is 0,0,1! 0.5,0.5,1 is a normalized color value 127, 127, 254 that represent a natural normal vector but it's not a normal vector.

Are you saying that I can plug a 0,0,1 float3 node in to the normal slot of the ME and have the same result as plugging in a 0.5,0.5,1.0 color texture?
I'm fairly sure that the ME would treat a float3 0,0,1 exactly the same as a 0,0,1 colored texture, since the ME is only using the color information in the texture to grab the information reference.

From my own experience, I can say with a fair amount of certainty that if you plug in 0,0,1 to the normals slot of the ME as either a float3 or a texture, the reflection vectors will not be ideal for a flat surface. I'll test it again on my next day off to make sure though. As I said before, when I was testing, an input of 0,0,1 created dark materials much like the one Crusha posted above.

I do not doubt your math skilz. I am pointing out what the input in the ME should be for optimal results.

Again, learn the difference between normal map vector and its color representation, normalized or not, because you mixing those things all the time. 0,5 is normalized color value 127: 127/254 = 0.5. The normal vector for this color value is 0.

If you provide a detail normal map that has the up vector component set to zero, then you won't have to do it every render call, which means it will be faster to render.

That makes more sense.
I was thinking about the ME and the actual input, which needs to be 0. Making it 0 in advance would save instructions.
Do you always work in raw vector format and then convert on the fly to figure out what you actually need in the editor, or are you just trying to test our vector math skills? I'm not sure that advising someone to set B127 is a very clear answer when you know that they actually need it set at 0.
Yes, if they stopped to think of it as a vector, they'd know that zeroing the Up component (B127) means 0. That is making it overly complicated when discussing the ME and PS, where it's just as easy to say "Set B0 in advance to save instructions". The B127 plays no part in the workflow, and Crusha clearly understands that it needs to be 0 already, as evidenced in their material.

I'm not confusing vectors and scalars. I'm giving instructions on what the input should be in the ME. B127 may work out to 0 as a vector, but using 127, 0r 0.5, in the ME or PS won't work. It needs to be 0. I was assuming that you were also advising on what to input in the ME, hence the confusion.

[mslaf]

The long weekend has ended.....

The reason why I mention diffuse detail textures when there is any chance that a diffuse detail texture may be causing an issue is because Epic uses detail diffuse as their examples all across UDN, which is where most of the UDKers go to learn how to use the ME.
http://udn.epicgames.com/Three/Mater...Detail Texturehttp://udn.epicgames.com/Three/Terra...istance detail

Those examples are for the terrain. Same name, similar technique and totally different purpose.

Are you saying that I can plug a 0,0,1 float3 node in to the normal slot of the ME and have the same result as plugging in a 0.5,0.5,1.0 color texture?
I'm fairly sure that the ME would treat a float3 0,0,1 exactly the same as a 0,0,1 colored texture, since the ME is only using the color information in the texture to grab the information reference.

I can't see any mathematical or practical sense to perform the math on normal map color values. Could provide a single example, what kind of math you could do with normal map color values, because I can't - besides the stuff like sharpening or similar image processing function that is never or usually never performed in the realtime.

From my own experience, I can say with a fair amount of certainty that if you plug in 0,0,1 to the normals slot of the ME as either a float3 or a texture, the reflection vectors will not be ideal for a flat surface. I'll test it again on my next day off to make sure though. As I said before, when I was testing, an input of 0,0,1 created dark materials much like the one Crusha posted above.

Each pixel of the texture sampler, that is plugged to the normal map port, goes through the (( xyz * 2 ) - 1 ) formula that returns a vector (shifts and extends the range of a float encapsulated in a color value). The math that you do after this point, is always performed on the vector.



is translated to:

return (((tex2D(Texture2D_0,Parameters.TexCoords[0].xy) * float4(2.00000000,2.00000000,2.00000000,1.00000000)) + float4(-1.00000000,-1.00000000,-1.00000000,0.00000000)).rgb * float3(0.1,0.2,0.3));

and



is translated to:

return float3(0.1,0.2,3);

See: GetMaterialNormal function for details or any normal map implementation in HLSL, CG or GLSL.

I do not doubt your math skilz. I am pointing out what the input in the ME should be for optimal results.

Don't get me wrong, but when I you advice someone to google the net for such basic information like above, you really have doubts about his skills

As we can continue this lovely debate, I would like Crusha to post the shot of entire material and it's instance to solve this problem.