What the what???? (shader file question)
BeigeAlert
Texas Join Date: 2013-08-08 Member: 186657Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester, Squad Five Blue, Squad Five Silver, NS2 Map Tester, Reinforced - Diamond, Reinforced - Shadow, Subnautica Playtester, Pistachionauts
Texas Join Date: 2013-08-08 Member: 186657Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester, Squad Five Blue, Squad Five Silver, NS2 Map Tester, Reinforced - Diamond, Reinforced - Shadow, Subnautica Playtester, Pistachionauts
in Mapping
Okay, so I'm doing a little bit of an experiment with making a .surface_shader file that instead of being lit by lights, will have it's emissive property driven by a "sunlight" vector. So I thought it would be a simple matter of taking the dot product of the world-space normal vector and the sunlight's direction vector. Naturally, I ran into problems. For whatever reason, the "light" changes whenever I rotate the camera! Weird right? Okay, so I go through and take a look at each component to figure out where the problem lies. First, I plug the wsNormal directly into the emission. Pretty colors! But NOT changing when I move the camera... so that checks out. Then, just for kicks, I plug my little "sunVector" float3 into the emission output, and... what the hell??? It changes based on the camera's orientation! How can this be? It's supposed to be a CONSTANT!!!
It's defined in the .material file to be -0.866, -0.707, 0.5 so how in the world is it changing like this?
Here's my Level_SunLit.surface_shader file:
and here's the "CliffsTest.material" file that I've made:
It's defined in the .material file to be -0.866, -0.707, 0.5 so how in the world is it changing like this?
Here's my Level_SunLit.surface_shader file:
<shader>
<inputs>
<input name="albedoMap" type="texture" address="wrap" />
<input name="normalMap" type="texture" address="wrap" />
<input name="sunVec" type="float3">(1, -1, 1)</input>
<input name="sunColor" type="float3">(1, 1, 1)</input>
</inputs>
<params>
<param name="wsNormal">true</param>
</params>
<code>
<![CDATA[
float3 DecodeNormal(const float4 texNormal)
{
float4 n = texNormal * 2 - 1;
//return float3(n.a, n.g, sqrt(1 - dot(n.ag, n.ag)) );
return n.xyz;
}
void MaterialShader(in Material_Input input, inout Material material)
{
float4 albedo = tex2D(albedoMap, input.texCoord);
//float intensity = clamp(dot(normalize(sunVector),normalize(input.wsNormal)),0,1);
material.albedo = albedo.rgb;
material.emissive = sunVec;
//material.emissive = albedo.rgb * intensity * sunColor;
material.tsNormal = DecodeNormal( tex2D(normalMap, input.texCoord) );
material.specular = float3(0,0,0);
material.gloss = 0.0;
}
]]>
</code>
</shader>
and here's the "CliffsTest.material" file that I've made:
shader = "shaders/beige/Level_SunLit.surface_shader" albedoMap = "models/props/Biodome/Biodome_outdoor_terrain.dds" normalMap = "models/props/Biodome/Biodome_outdoor_terrain_normal.dds" sunColor = 0.5, 0.25, 1.0 sunVec = -0.866, -0.707, 0.5 surface = "metal"
Comments
Make a rectangle and add an emissive texture to it... doesn't matter which one (I did it with refinery glass, then with lava), now stretch it waaayyy out. At least 3000x3000. Did you see that? Grab the scale handles and stretch it in and out. WHY oh WHYYYYY is it getting brighter the bigger it gets??????????????????????????????????????????? Doesn't seem to happen when scaling props, though I suspect that works a little differently.
Welp... there's another bug to add to your colossal in-box.
The emissive-ness changing with size is definitely a bug though, and here's a gif to prove it!
Yea it's really pretty limiting. I tried making a parallax occlusion shader a while back, but quickly gave that up when I realized that we don't have access to even the most basic parameters (ie camera position).
And now, I realize I'll probably have to put this parallel light source shader on hold until I get a massive prop of the cliff made (as the emissive bug doesn't seem to affect props), and even then I'll have to provide the normal map in world-space instead of tangent space as we're not provided with world-space binormal or world-space tangent which are needed to convert from tangent-space normal maps to world-space normal maps. Without that it would look pretty bad, as the normal map would be ignored.
@[AwE]Sentinel no, texture size makes no difference. It seems to be only the size of the polygon that makes a difference.
Hehehe not likely... you have to make the faces pretty huge to get this bug... but it affects my outdoor terrain, so I'm still not happy!
EDIT: Oops, forgot to summon @Howser @Howser @Howser !!!!