Normal maps needs 1,-1 range in actual application. Its possible that blender does this automatically, just like Unreal! When you have normal map compression on the texture. Thats one of the things it does. So that 0.5,0.5,1 becomes 0,0,1 when its in one minus one range I didn't get that from somewhere, its like that. You can try it yourself by feeding a normal map channel into an if node. and comparing it to some values. Youll see that it has negatives too. So then both of your normal map and that vector had the same error. Both of them were in 0,1 range.
It won't really make more "instructions" but it will generate much more shader code. Especially if you keep toggling them on and off. This is why you see shader compilation when you toggle them. The switch parameter and the static switch is pretty much the same thing. You can make the static switch having a checkbox parameter like the switch parameter. Just hook up a boolean parameter to it. The switch parameter is just a little bit more user friendly because it has it by default but other than that there is no difference between them.
Normal maps needs 1,-1 range in actual application. Its possible that blender does this automatically, just like Unreal! When you have normal map compression on the texture. Thats one of the things it does. So that 0.5,0.5,1 becomes 0,0,1 when its in one minus one range I didn't get that from somewhere, its like that. You can try it yourself by feeding a normal map channel into an if node. and comparing it to some values. Youll see that it has negatives too. So then both of your normal map and that vector had the same error. Both of them were in 0,1 range.
Obscura is right about the range so trust him on that. I just didn't know if it would matter based upon whether or not the actual normal map is being used or not. But I think what you're saying is that the wrong value in his 3 vector is causing the normal map to be out of range from the start so that if he switches it to use the normal map it will be out of range as well. Do I have that right?
@Steamy_Steve Yes it was me saying that you can bake alphas in Substance Painter. Essentially what you do is make the plane that you bake down onto a red material and make all of your foliage objects a blue material. That way when you go to bake you create an ID map for the plane. I would bake that ID map at x2 the needed resolution because the ID maps tend to be dodgy in substance painter. Then just add in the Opacity channel and switch your shader to Alpha test in Painter. Add a fill layer with all black opacity then a mask and color pick your correct ID. When you go to export your maps make sure your alpha is somewhere in the export.
@Obscura ; @zachagreg ; Ok, here's what I've got about normal maps in DirectX: .- red channel drives the x axis tilt, 0 to 255 (left to right, -1 to 1), where 128 is the middle point, perpendicular to the projecting polygon -. green channel drives the y axis tilt, 0 to 255 (up to down, -1 to 1), where 128 is the middle point etc etc .- blue channel drives the z axis depth, 128 to 255 (top to bottom, 0 to -1)
Hence, the normal colour depicting a surface that is flat and perpendicular to the projecting polygon is 128,128, 255 (0.5, 0.5, 1 in UE4's decimal colour coding). Why is this not correct? =0
@zachagreg ; Making alphas that way sounds complicated, with xNormal it's a 30 seconds setup and 10-20 more to bake. Any overlooked reason why I should prefer Substance Painter to bake alpha maps? Anyway, just to be sure I got it right: I *fill* the low-poly plane with a black layer, and then I bake the high-poly's white vertex colour onto it with dilation off and AA 2x...?
@Obscura ; Thus I should just go with "fillers" through "Add" nodes and avoid switches like the plague? =o What's the difference between "more instructions" and "more code"? And yes, I'm squeezing so much knowledge out of you and I dont feel ashamed at all.
Yea it's about the same time in all actuality, it's preference really. I try to use the least amount of programs and I've just always had a distaste for xNormal personally. So it comes down to preference. I would say the added benefit is you can easily paint any areas of the alpha that you don't like. It's easily adjusted.
You've got it kind of right but you just use the color picker from the baked ID map. Which is in the bake settings, but in essence yes fill the background with black to make it completely transparent and then the remaining color will stay opaque.
You don't have to worry about dilation because that won't change the alpha on export. 2x AA should be sufficient yes.
Also another note is that if your highpoly is one mesh you can just use the mesh ID option in the ID map settings for Painter. Which forgoes the need to have separate materials for your high and low.
@zachagreg ; And what about normal maps' colour values? =o
Anyway, this is weed_03, Aconitus.....
And yes, it's 100% modeled, sculpted and handpainted by me....just for the sake of learning, I know there are faster ways to craft this kind of props.... ^.^
There are faster ways but a lot of high quality foliage is hand sculpted so you're taking the right approach in my opinion. As far as the normals go, you're referencing the 0,0,1 or .5,.5,1 right? I'll use your own quote so that this makes a little more sense because you already said why it should be 0,0,1 I just don't think you've realized it.
@Obscura ; @zachagreg ; Ok, here's what I've got about normal maps in DirectX: .- red channel drives the x axis tilt, 0 to 255 (left to right, -1 to 1), where 128 is the middle point, perpendicular to the projecting polygon -. green channel drives the y axis tilt, 0 to 255 (up to down, -1 to 1), where 128 is the middle point etc etc .- blue channel drives the z axis depth, 128 to 255 (top to bottom, 0 to -1)
Hence, the normal colour depicting a surface that is flat and perpendicular to the projecting polygon is 128,128, 255 (0.5, 0.5, 1 in UE4's decimal colour coding). Why is this not correct? =0
0-255 is equal to -1 to 1 in UE4 right? So 128 is half way between 0 and 255. What's halfway between -1 and 1?
Yes that would be correct if it weren't taking unpacked normal data. In an albedo the range is indeed 0 to 1 however in an unpacked normal, at least in UE4's case that range is -1 to 1. That is the range the material input expects when plugging anything into the normal channel. This happens behind the scene somewhat when the normal setting is applied to the Sampler Type of a Texture Sample node. So whenever that Sampler Type is set to Normal it expects -1 to 1 range and will convert the texture to that range, but since you are piping in just the Vec3 it can't make the automatic conversion to the correct range.
As to why this is and why Epic made it like this, I do not know. I just know that it is. I'm sure there is a legitimate reason for this but I don't have any insight into that.
This distinction can be seen visually and I know it trips up a lot of people when they first see that there is a difference between their maps in the material editor.
See how above in the Details panel the colors are more near the range of what a normal map typically looks like. When previewing the Texture Sample however you can now see it is much more towards blue than it is purple. This is what you are experiencing. I know it seems wrong. Because what you're saying makes sense but what's happening here is that conversion into the -1 to 1 range rather than the 0 to 1 range.
@zachagreg ; @Obscura ; Aha! Ok, now I get why it seemed like we were talking about two different things: because we were! x) So, let me get this straight: the texture sampler converts the range of a normal map to a -to+ range, but what about a vector3 node? Do I have to comply and range it according to UE4....or is it ok to use the actual normal map colour range? And what would the right range be? [0, 0, 0.5]?
Yea I had the feeling we were! But yes, specifically a texture sampler set to Normal type, that's an important distinction. As for using the Vec3 node, if you are putting into a normal input then yes you have to comply with the -1 to 1 range if it is not for a normal map you do not.
For a "flat" normal map Vec3 the input will just be 0,0,1 blue
New type of grass, the short kind...which, apparently, is more difficult to tweak than the tall one. =p This one suffers from a high polycount, but I can tweak it furtherly and make it weigh less....
@zachagreg I have no idea why the difference in colour is so harsh. I tried to mimic the actual grass that I took as reference, which tends to change from a full green to a yellow-ish one. And it looks fine, in SP.
Anyway, first I'd like to furtherly tweak the density, then I'll work the colour.
@Obscura I'm already studying some tuts to be able to craft something more suitable. ^^'
Replies
It won't really make more "instructions" but it will generate much more shader code. Especially if you keep toggling them on and off. This is why you see shader compilation when you toggle them. The switch parameter and the static switch is pretty much the same thing. You can make the static switch having a checkbox parameter like the switch parameter. Just hook up a boolean parameter to it. The switch parameter is just a little bit more user friendly because it has it by default but other than that there is no difference between them.
@Steamy_Steve Yes it was me saying that you can bake alphas in Substance Painter. Essentially what you do is make the plane that you bake down onto a red material and make all of your foliage objects a blue material. That way when you go to bake you create an ID map for the plane. I would bake that ID map at x2 the needed resolution because the ID maps tend to be dodgy in substance painter. Then just add in the Opacity channel and switch your shader to Alpha test in Painter. Add a fill layer with all black opacity then a mask and color pick your correct ID. When you go to export your maps make sure your alpha is somewhere in the export.
Ok, here's what I've got about normal maps in DirectX:
.- red channel drives the x axis tilt, 0 to 255 (left to right, -1 to 1), where 128 is the middle point, perpendicular to the projecting polygon
-. green channel drives the y axis tilt, 0 to 255 (up to down, -1 to 1), where 128 is the middle point etc etc
.- blue channel drives the z axis depth, 128 to 255 (top to bottom, 0 to -1)
Hence, the normal colour depicting a surface that is flat and perpendicular to the projecting polygon is 128,128, 255 (0.5, 0.5, 1 in UE4's decimal colour coding).
Why is this not correct? =0
@zachagreg ;
Making alphas that way sounds complicated, with xNormal it's a 30 seconds setup and 10-20 more to bake.
Any overlooked reason why I should prefer Substance Painter to bake alpha maps?
Anyway, just to be sure I got it right: I *fill* the low-poly plane with a black layer, and then I bake the high-poly's white vertex colour onto it with dilation off and AA 2x...?
Thus I should just go with "fillers" through "Add" nodes and avoid switches like the plague? =o
What's the difference between "more instructions" and "more code"?
And yes, I'm squeezing so much knowledge out of you and I dont feel ashamed at all.
You've got it kind of right but you just use the color picker from the baked ID map. Which is in the bake settings, but in essence yes fill the background with black to make it completely transparent and then the remaining color will stay opaque.
You don't have to worry about dilation because that won't change the alpha on export. 2x AA should be sufficient yes.
Also another note is that if your highpoly is one mesh you can just use the mesh ID option in the ID map settings for Painter. Which forgoes the need to have separate materials for your high and low.
And what about normal maps' colour values? =o
Anyway, this is weed_03, Aconitus.....
And yes, it's 100% modeled, sculpted and handpainted by me....just for the sake of learning, I know there are faster ways to craft this kind of props.... ^.^
We're talking about a colour node, here. The range is 0 to 1.
What's between 0 and 1?
If I set the colour node to [0,0,1] (black, black, white) I get full blue, which means the X and Y axis are fully tilted toward left and up.
The flat normal map colour is [128,128,255] (grey, grey, white). And [grey, grey, white] in UE4's decimal colour values is [0.5,0.5,1].
Aha!
Ok, now I get why it seemed like we were talking about two different things: because we were! x)
So, let me get this straight: the texture sampler converts the range of a normal map to a -to+ range, but what about a vector3 node?
Do I have to comply and range it according to UE4....or is it ok to use the actual normal map colour range?
And what would the right range be? [0, 0, 0.5]?
This one suffers from a high polycount, but I can tweak it furtherly and make it weigh less....
I think the density and that line may even itself out with differences in height and size so don't stress too much about it. Looks like shadows
And it looks fine, in SP.
Anyway, first I'd like to furtherly tweak the density, then I'll work the colour.
@Obscura I'm already studying some tuts to be able to craft something more suitable. ^^'