What the what???? (shader file question)

BeigeAlert

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:

<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"

BeigeAlert

Adding some more strangeness to the mix here with a fun experiment you can try at home!

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.

Rudy.cz

Pics or it didn't happened

BeigeAlert

The issue with the changing input value seems to have just... disappeared. I even copy+pasted from my original post and... nothing, worked right. Except I just discovered that it seems to be completely ignoring the values that I defined in the .material file, going instead for the default values, so I'm cutting that out completely and just hard-coding the sun-angle and color into the shader.

The emissive-ness changing with size is definitely a bug though, and here's a gif to prove it!

Rudy.cz

That really looks funky. Frankly I cannot give you any advice on this, but I am sure that Howser had dabbled with shaders within Spark from all of us the most. Unfortunately he reported that shader implementation in NS2 is pretty shady.

[AwE]Sentinel

I was working with lava in Honorguard and almost the same happend. Does the brightness change with the size of the texture? If you fit the texture size to the face size/enable texture lock, does it change that much as well?

Vetinari

Now we only have to figure out how to abuse that in a cool way for a map.

BeigeAlert

Rudy.cz wrote: »

That really looks funky. Frankly I cannot give you any advice on this, but I am sure that Howser had dabbled with shaders within Spark from all of us the most. Unfortunately he reported that shader implementation in NS2 is pretty shady.

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.

F0rdPrefect wrote: »

Now we only have to figure out how to abuse that in a cool way for a map.

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‌ !!!!

Loki

its used in kodiak if you know where to look done via texture size rather than geo size (and yeah texture size does work) its down to a light source too