Users who are viewing this thread
OK, I'll test that theory out really quick 
My thought as I was heading to get some food was, "gee, maybe the vertex shader failed to link", but I'll try this out; if it doesn't work, I'll try restoring the link to the original vertex shader, as most of the things I want changed are in the pixel shader.
My thought as I was heading to get some food was, "gee, maybe the vertex shader failed to link", but I'll try this out; if it doesn't work, I'll try restoring the link to the original vertex shader, as most of the things I want changed are in the pixel shader.
Well, I'll be darned. That* actually worked
So I guess now it'd be nice to know why, but heck, I could've spent all night on this otherwise; now I can spend all night testing the self-luminance version and getting a few more things converted. Thanks very much for confirming and testing, that was most confusing
Let's see if I can re-separate it can keep it working, and if yes, then I can release some code.
*Copying specular_shader_bump_Instanced, removing the instancing flag, and using a renamed version, instead of a modified version of the stock standart_shader.
So I guess now it'd be nice to know why, but heck, I could've spent all night on this otherwise; now I can spend all night testing the self-luminance version and getting a few more things converted. Thanks very much for confirming and testing, that was most confusing
Let's see if I can re-separate it can keep it working, and if yes, then I can release some code.
*Copying specular_shader_bump_Instanced, removing the instancing flag, and using a renamed version, instead of a modified version of the stock standart_shader.
I just broke it again while rolling everything back from testing 
It appears that there is something very, hmm, odd going on here. IDK where I broke it yet; what I do know is that when I set the technique to compile using the standart shaders, it remained broken.
I'm starting to think that I need to just roll it all back and make sure the pixel shader actually works properly, then the vertex shader, as a straight swap. I wanted to avoid doing that; practically all of my mod's content will have to be adjusted to really work perfectly with this. Maybe one big IF conditional when compiling, if this actually works...
It appears that there is something very, hmm, odd going on here. IDK where I broke it yet; what I do know is that when I set the technique to compile using the standart shaders, it remained broken.
I'm starting to think that I need to just roll it all back and make sure the pixel shader actually works properly, then the vertex shader, as a straight swap. I wanted to avoid doing that; practically all of my mod's content will have to be adjusted to really work perfectly with this. Maybe one big IF conditional when compiling, if this actually works...
Well, the pixel shader actually worked better than expected; no errors with things that don't have specular maps (I guess that reads as a specular of zero). Only "loss" is the fake aniso and very spotty results with all the un-converted gear. Some things look at least as good as they always have, like the Native bascinet; some things have a severe lack of specular highlights and look dulled and un-shiny. Gotta go investigate that, see if it's coef or RGB spec values or just the specmap that makes all the difference; it'd be nice if I could boost spec values and fix it automagically, this really isn't too bad.
However, there is that little issue of not actually having a new shader that operates properly. This replaces core functionality of the standart shader series, overriding a lot of states and basically it's a different animal. I don't want it to operate like this- it's a definite improvement, when properly tuned, but it really should be its own thing, to keep backwards compatibility, otherwise I doubt anybody will use it other than me (I wanted metallic metal really bad, heh).
I'm afraid I'm stumped on that; maybe somebody with a bit more knowledge can help me out with this when I provide the source. I hope it's something dumb / obvious, frankly, but now that I know the pixel shader works just fine as it was written, I'm pretty confused about what went wrong here.
[EDIT]Confirmed that the specular values contribute a lot, in terms of what still looks good and what doesn't (which isn't too surprising given how the new code works); now I'll test whether I can fix with RGB shifts for all the stuff that is currently too subtle in terms of lighting.[/EDIT]
However, there is that little issue of not actually having a new shader that operates properly. This replaces core functionality of the standart shader series, overriding a lot of states and basically it's a different animal. I don't want it to operate like this- it's a definite improvement, when properly tuned, but it really should be its own thing, to keep backwards compatibility, otherwise I doubt anybody will use it other than me (I wanted metallic metal really bad, heh).
I'm afraid I'm stumped on that; maybe somebody with a bit more knowledge can help me out with this when I provide the source. I hope it's something dumb / obvious, frankly, but now that I know the pixel shader works just fine as it was written, I'm pretty confused about what went wrong here.
[EDIT]Confirmed that the specular values contribute a lot, in terms of what still looks good and what doesn't (which isn't too surprising given how the new code works); now I'll test whether I can fix with RGB shifts for all the stuff that is currently too subtle in terms of lighting.[/EDIT]
OK, here is code for folks who'd like to try it out.
Features:
1. Better simulation of metallic reflections, using specular RGB as a multiplier and cap. Specular values may now be regulated in a fairly complex fashion, using the specular to color-shift final results. An example file is included with this code so that you may import it into your projects and test it immediately with an object formatted properly for testing.
2. Improved overall lighting behavior both outside and in, removing the vertex lighting effects that produced artifacts and bad face lighting.
3. Still respects vertex colors from vertex AO and paint.
If used properly, the shader can give fairly realistic results. If we can also get the sky's color factored in for fake fast reflections, objects will look fairly realistic. And it's still fairly cheap.
Caveats:
1. If your models don't have speculars that reach near white, you will see issues with specular values; objects will have bumps but will look dull.
2. Metals require color-shifting to exhibit proper final values. In the real world, very few metals are truly gray, with pure-white specular behavior; you'll want to play with this a lot and let your objects give you more realistic color values, and it will require a little practice.
The whole point of the project was to get metals, especially brass, copper and bronze, to no longer be shifted to white points and get rid of the wholesale slaughter of RGB values that made everything look like plastic. Steels can be corrected with a little brown or blue; metallic paints may be simulated by highly saturated values; you can even do two-tone simulation by using a different saturated color in the specular vs. the diffuse. I think that a reasonable simulation of opalescent behaviors minus sub-surface refractive effects can probably be simulated with this, but I have not tested yet.
3. I am only providing this code snippet, which replaces a standart pixel shader. You will need to replace your code, compile the fx file, and test. I'm not providing instructions; this is very non-newbie territory and I don't want people who aren't comfortable with shaders even trying to mess with it yet.
4. I'm sure there are mistakes or ways to get the desired behaviors a little more cheaply, but it's about what I wanted atm visually and I'm mainly an artist, not a coder, so please don't complain if it's not what you want, it's Open Source, offer a rewrite
Example file can be downloaded here.
[EDIT]@Computica: See the earlier screens. Basically I'm just working with stuff that I have backed up in more than one place and were things that I was really unhappy with how they looked before. I'll let everybody play with it and see what they can do; I am just scratching the surface, in terms of using it as an artist- I can already see some pretty cool stuff I can do with this.[/EDIT]
Features:
1. Better simulation of metallic reflections, using specular RGB as a multiplier and cap. Specular values may now be regulated in a fairly complex fashion, using the specular to color-shift final results. An example file is included with this code so that you may import it into your projects and test it immediately with an object formatted properly for testing.
2. Improved overall lighting behavior both outside and in, removing the vertex lighting effects that produced artifacts and bad face lighting.
3. Still respects vertex colors from vertex AO and paint.
If used properly, the shader can give fairly realistic results. If we can also get the sky's color factored in for fake fast reflections, objects will look fairly realistic. And it's still fairly cheap.
Caveats:
1. If your models don't have speculars that reach near white, you will see issues with specular values; objects will have bumps but will look dull.
2. Metals require color-shifting to exhibit proper final values. In the real world, very few metals are truly gray, with pure-white specular behavior; you'll want to play with this a lot and let your objects give you more realistic color values, and it will require a little practice.
The whole point of the project was to get metals, especially brass, copper and bronze, to no longer be shifted to white points and get rid of the wholesale slaughter of RGB values that made everything look like plastic. Steels can be corrected with a little brown or blue; metallic paints may be simulated by highly saturated values; you can even do two-tone simulation by using a different saturated color in the specular vs. the diffuse. I think that a reasonable simulation of opalescent behaviors minus sub-surface refractive effects can probably be simulated with this, but I have not tested yet.
3. I am only providing this code snippet, which replaces a standart pixel shader. You will need to replace your code, compile the fx file, and test. I'm not providing instructions; this is very non-newbie territory and I don't want people who aren't comfortable with shaders even trying to mess with it yet.
4. I'm sure there are mistakes or ways to get the desired behaviors a little more cheaply, but it's about what I wanted atm visually and I'm mainly an artist, not a coder, so please don't complain if it's not what you want, it's Open Source, offer a rewrite
Example file can be downloaded here.
Code:
PS_OUTPUT ps_main_standart ( VS_OUTPUT_STANDART In, uniform const int PcfMode,
uniform const bool use_bumpmap, uniform const bool use_specularfactor,
uniform const bool use_specularmap, uniform const bool ps2x,
uniform const bool use_aniso, uniform const bool terrain_color_ambient = true )
{
PS_OUTPUT Output;
float3 normal;
//Get our normalmap, expand it
normal = (2.0f * tex2D(NormalTextureSampler, In.Tex0) - 1.0f);
float sun_amount = 1;
//Add some ambient factor to sun amount
sun_amount = 0.05f + GetSunAmount(PcfMode, In.ShadowTexCoord, In.ShadowTexelPos);
//define ambient term
const int ambientTermType = 1;
const float3 DirToSky = In.SkyLightDir;
float4 total_light = get_ambientTerm(ambientTermType, normal, DirToSky, sun_amount);
//Get our sunlight input
total_light.rgb += (saturate(dot(In.SunLightDir.xyz, normal.xyz))) * sun_amount * vSunColor;
//Get point light inputs, if any, and boost lighting results
float light_atten = In.PointLightDir.a;
const int effective_light_index = iLightIndices[0];
total_light += saturate(dot(In.PointLightDir.xyz, normal.xyz) * vLightDiffuse[effective_light_index] * light_atten);
//Output our current lighting state
Output.RGBColor.rgb = total_light.rgb;
//Input our material color, if any
Output.RGBColor.rgb *= vMaterialColor.rgb;
//Input our diffuse and specular textures for later use
float4 tex_col = tex2D(MeshTextureSampler, In.Tex0);
float4 spec_tex = tex2D(SpecularTextureSampler, In.Tex0);
//Start the process of gamma correction for post-processing later
INPUT_TEX_GAMMA(tex_col.rgb);
//Diffuse multiplied by vertex colors (blood, etc.)
Output.RGBColor.rgb *= tex_col.rgb * In.VertexColor.rgb;
//Shift specColor according to vertex and spec_tex RGB
float4 specColor = 0.1 * spec_coef * vSpecularColor * spec_tex;
//Get sun specular color and power.
float4 sun_specColor = specColor * vSunColor * sun_amount * spec_tex;
float3 vHalf = normalize( In.ViewDir + ((use_bumpmap) ? In.SunLightDir : -vSunDir) );
//Create fSpecular, boost using sun
float4 fSpecular = sun_specColor * pow( saturate(dot(vHalf, normal)), fMaterialPower) * spec_tex;
//Use the VertexColor & spec_tex to change hue of fSpecular
fSpecular *= In.VertexColor * spec_tex;
//add point lights' specular color for indoors
fSpecular.rgb += specColor * In.ShadowTexCoord.rgb;
//Point lights
//Light atten here dropped to fix transitions between lights; left unchanged for now
float4 light_specColor = specColor * vLightDiffuse[effective_light_index] * (light_atten * 0.5) * spec_tex;
vHalf = normalize( In.ViewDir + In.PointLightDir );
fSpecular += light_specColor * pow( saturate(dot(vHalf, normal)), fMaterialPower);
//Keep correcting the final output...
Output.RGBColor += fSpecular * spec_tex;
//Gamma out for color correction, feeds post fx.
OUTPUT_GAMMA(Output.RGBColor.rgb);
//No alpha shifts other than alpha test; no translucency support
Output.RGBColor.a = 1.0;
return Output;
}[EDIT]@Computica: See the earlier screens. Basically I'm just working with stuff that I have backed up in more than one place and were things that I was really unhappy with how they looked before. I'll let everybody play with it and see what they can do; I am just scratching the surface, in terms of using it as an artist- I can already see some pretty cool stuff I can do with this.[/EDIT]
Mammoet
Master Knight
I'm not sure I understand how you tried to make it a seperate shader. What I did when I tested my fur one, was just copy a vertex and pixel shader and paste them at the bottom. Rename them both, make a technique that uses these and then reference it in a brf file. Fill in the texture acces things and use whatever flags you think are appriopriate (though I'm in doubt if they actually do anything). It SHOULD work.
Wow, do you know you're using the specular texture to the 5th power for specular lighting?
And I think it'd not be the best idea to use the sky color to add to your lighting effects as to simulate world reflections as the sky usually has a different color then most of the objects in the scene. You could take a look at the get_ambientTerm code, there is something like vGroundAmbientColor (can't remember exactly) and I beleive this has sort of the ambient color, it's green on grass maps and white on snow maps. Maybe you can use that somehow.
Wow, do you know you're using the specular texture to the 5th power for specular lighting?
And I think it'd not be the best idea to use the sky color to add to your lighting effects as to simulate world reflections as the sky usually has a different color then most of the objects in the scene. You could take a look at the get_ambientTerm code, there is something like vGroundAmbientColor (can't remember exactly) and I beleive this has sort of the ambient color, it's green on grass maps and white on snow maps. Maybe you can use that somehow.
Hatonastick
My shader knowledge is practically zero (messed with it a bit under OpenGL and that's it), but if it was possible I'd love to see the hair shader fixed. The Native anisotropic looks awful.
Yeah, I know, but it didn't. I still don't know why it went awry, either. Probably something silly, but IDK what.
Well, there's a lot going on here. The post-fx gamma re-boosts results for all this stuff using armor; there's a 5X boost to specular that probably doesn't need to be in the math, but was left in there by Taleworlds... there's a lot of strange stuff I had to deal with. I really don't think it's optimized at all, basically, but it does what I want, visually
I think it really depends on whether the skybox is reasonable or not, and how it handles shadows. It wouldn't be perfect, by any means, but real reflections are very expensive, and I don't think they're even generated unless fancy water's on and you're on a map with water.
Yeah, I agree, just not quite sure how to implement one yetI meant that using a half-decent environment map might be easier and achieve a decent result as well
I did something with GLSL where I took a cubemap and used that for lighting, basically a cheap form of global lighting and reflections; the visual results for anything reflective were really good and it's fairly cheap.
IDK how to port that approach until I have a clue about how to get access to the skies for the game and how to get them to have a "ground"- I took a look, and they doubled their sky on the bottom sides, it's weird and will need to be addressed as well.
Yeah, it's sphere-wrapped.
I think it's:
Now I gotta go stare at the water, see which register gets used for that.
[/EDIT]It's using the diffuse register, not one of the special slots (1 and 3). Boo, hiss. Envmap uses 4, which is reserved for the normalmap. IDK whether this is possible or not.[/EDIT]
I think it's:
Code:
tex = tex2D(ReflectionTextureSampler, (0.25f * normal.xy) + float2(0.5f + 0.5f * (In.PosWater.x / In.PosWater.w), 0.5f - 0.5f * (In.PosWater.y / In.PosWater.w)));Now I gotta go stare at the water, see which register gets used for that.
[/EDIT]It's using the diffuse register, not one of the special slots (1 and 3). Boo, hiss. Envmap uses 4, which is reserved for the normalmap. IDK whether this is possible or not.[/EDIT]
Mammoet
Master Knight
the "envmap_specular" (not the water one) uses this in the vertex shader(ok its modified from the original messiness, but it comes down to the same thing):
and this
in the pixel shader.
There is a whole lot of stuff wrong with the original envmap_specular shader though. For example it calculates the specular on a vertex basis...
The normal map uses 2 right? (at least that's what it says in OpenBRF when I look at for example "standart_shader_bump_nospec".
Code:
Out.Tex0.zw = Out.ViewDir.yz - Out.SunLightDir.yz+1.0f;
Code:
float3 envColor = tex2D(EnvTextureSampler, In.Tex0.zw).rgb;There is a whole lot of stuff wrong with the original envmap_specular shader though. For example it calculates the specular on a vertex basis...
xenoargh said:
The normal map uses 2 right? (at least that's what it says in OpenBRF when I look at for example "standart_shader_bump_nospec".
Hmm. At the shader level (water_shader_mud_high), it states it's material requirements as one diffuse slot with a special flag.
At the Material level (river_mud), it's using a diffuse and normalmap. There are special flags all over this, as well.
And yes, you're right, got normal / specular reversed Either way, can't live without them. The special flags make me wonder how texture access works; too bad that isn't documented.
At the Material level (river_mud), it's using a diffuse and normalmap. There are special flags all over this, as well.
And yes, you're right, got normal / specular reversed
Either way, can't live without them. The special flags make me wonder how texture access works; too bad that isn't documented.My guess is maybe the 100 flag means that it can access diffuse and the reflections? IDK. I'm starting to think so, though; the problem they hit is the same one you hit anywhere with shaders; texture access per pass is limited. The flags are probably there to signal special cases. It may be that the 5 that are shown in OpenBRF are always available to every shader; that would be handy.
In GLSL it was limited to 8, IIRC, so you had to resort to FBO to store results if you needed more (i.e., expensive).
In GLSL it was limited to 8, IIRC, so you had to resort to FBO to store results if you needed more (i.e., expensive).
Got one of the big collections of atlased swords over to the new specmap adjustments using the new shader; makes a terrific difference. They still look fairly crappy, vs. hand-paint, but it's still a huge step up- Blood and Steel players will be very happy with this
