[INFO] Shader Stuff- HLSL instruction limits

[xenoargh]

Hmm.  Maybe it's sending that to the post-fx?  I haven't looked much at that yet; one thing I want to do eventually is calm down the OMG BLOOM if you set it to HSL High, and maybe do some other tweaks to color correction... if I run out of more useful stuff to do.

Oh, and in terms of playing around with pixel shaders, since you asked...

1.  I'd like a shader that implements translucence and doesn't cull backfaces.  Uses a normalmap and specular, preferably the skybox cube.  Yeah, yeah, render-order issues and such; it won't be perfect but it should look OK for most uses.

2.  I'd really, really, really, really like a shader that takes the skybox cubemap (see the water) and uses that in the pixel shader of a normalmapped, specular-friendly thing.  Imagine how nice armor would look, using cheap fake reflections (when not in shadow).  It's not entirely cheap, IDK whether it's practical on typical hardware yet, but I'd love to test it and find out.

3.  I'd like a non-junky exact lighting model for point lights, so that it's no longer using vertex lighting indoors.  If you can get that done, I'd really appreciate seeing the code and getting help with the hair shader; it's looking pretty good outdoors but indoors it remains meh.

4.  I'd like a version of standart_shader to implements glow, preferably in a way that's post-fx friendly (i.e., bloom).  That's probably the lowest-hanging fruit of all; IIRC the current shader's already reading the alpha channel, so obviously it's all set up and ready.  I'd really dig being able to use that for a number of things.

Anyhow, this is my want list; I'd prefer PS / VS 2.a rather than 3, though; that cuts off some important tools but I figure 3.x is probably a bigger block than 2.a, at least under DX9, and a lot of players are using XP (and so am I).

[Vincenzo]

What it does is this:

Code: [Select]

float3 P = mul(matWorldView, vPosition); //position in view space
//apply fog
float d = length(P);
float4 vWorldPos = (float4)mul(matWorld,vPosition);
Out.Fog = get_fog_amount_new(d, vWorldPos.z);
And get_fog_amount_new does nothing else then call get_fog_amount(d) which is:

Code: [Select]

return 1.0f / exp2(d * fFogDensity);
So it could be fairly easy to add that in the pixel shader.

I would advise against using such calculations in the pixel shader, since pixel shaders are executed millions of times per object where as vertex shaders are executed per vertex, it is far more efficient to do pre-calculations in the vertex shader, and pass their results towards the pixel shader.

Why it doesent work with VS 3.0/PS3.0  not entirely sure, however I'd advice against using VS/PS 3.0 in warband simply because the engine is not set up for it at all, Your better off fitting everything within the PS2/VS2 limits. that includes performance reasons.

[Barabas]

Hmm.  Maybe it's sending that to the post-fx?  I haven't looked much at that yet; one thing I want to do eventually is calm down the OMG BLOOM if you set it to HSL High, and maybe do some other tweaks to color correction... if I run out of more useful stuff to do.

Oh, and in terms of playing around with pixel shaders, since you asked...

1.  I'd like a shader that implements translucence and doesn't cull backfaces.  Uses a normalmap and specular, preferably the skybox cube.  Yeah, yeah, render-order issues and such; it won't be perfect but it should look OK for most uses.

Hmm I think you can already do this (without the skybox, which is not a cube D=) by using the correct settings in openbrf. I tried it out for ice once. You should enable No Z-write and use a rendering order higher then 0 probably. Sadly I didn't save a screenshot of it. Anyway I don't think you need to write a new shader for that.

2.  I'd really, really, really, really like a shader that takes the skybox cubemap (see the water) and uses that in the pixel shader of a normalmapped, specular-friendly thing.  Imagine how nice armor would look, using cheap fake reflections (when not in shadow).  It's not entirely cheap, IDK whether it's practical on typical hardware yet, but I'd love to test it and find out.

I think I just did that for the newest version of Vikingr, sort of. I edited the envmap shader and made it way more sensible and accept a normalmap! =D

3.  I'd like a non-junky exact lighting model for point lights, so that it's no longer using vertex lighting indoors.  If you can get that done, I'd really appreciate seeing the code and getting help with the hair shader; it's looking pretty good outdoors but indoors it remains meh.

Hmm.... haven't looked at that at all yet.

4.  I'd like a version of standart_shader to implements glow, preferably in a way that's post-fx friendly (i.e., bloom).  That's probably the lowest-hanging fruit of all; IIRC the current shader's already reading the alpha channel, so obviously it's all set up and ready.  I'd really dig being able to use that for a number of things.

You mean use the alpha channel for specular lighting? To me it seems that it should already do this, however, Ive not yet tried it out or figured out how it works exactly in the code.

Anyhow, this is my want list; I'd prefer PS / VS 2.a rather than 3, though; that cuts off some important tools but I figure 3.x is probably a bigger block than 2.a, at least under DX9, and a lot of players are using XP (and so am I).

Alright, then I'll forget about that.

*snip*

I would advise against using such calculations in the pixel shader, since pixel shaders are executed millions of times per object where as vertex shaders are executed per vertex, it is far more efficient to do pre-calculations in the vertex shader, and pass their results towards the pixel shader.

Why it doesent work with VS 3.0/PS3.0  not entirely sure, however I'd advice against using VS/PS 3.0 in warband simply because the engine is not set up for it at all, Your better off fitting everything within the PS2/VS2 limits. that includes performance reasons.

It's done in the vertex shader.  The strange thing is that it never ever gets to the pixel shader. And it's not that bad, its only one exponential, now I don't know how expensive that is precisly but for using specular stuff you also have to calculate a power, and sometimes thats done multiple times. Also I don't think pixel shaders are executed millions of times per object, as my fairly big screen with a resolution of 1920x1200 only has 2304 thousand (2.3 million) pixels. So I'm guessing it's executed about that many times for each frame (not object) or am I missing something here?

(like I said I'll drop the idea of using version 3 anyway ^^)

[xenoargh]

Pixel shaders are executed for every texel that passes depth and alpha testing, pretty much  So for every pixel in your screen, it can add up to many, many passes per render to buffer.  Cards and software try to pre-optimize this as much as possible by doing geometry sorting, etc., so that it doesn't lead to crippling performance problems.

Vincenzo is right, math adds up very quickly, even in pretty good conditions.  It's important to be conservative with shaders and optimize them heavily; I really honestly think that the standart_shader is not written for best performance (GPUs do not like IF statements and lots of conditional checks) so eventually I'll be splitting it out to two versions, one with spec and all bells and whistles, one without, if the engine will let me

That said, a few instructions to gain a major improvement in looks is not a big deal.



1.  Translucency:  I don't think that translucency can work well without using an environment map; glass just doesn't look good without reflections, however fake.  There are other issues as well- alpha-tested stuff that is merely transparent already gets shoved high in the rendering order, and as I found out with hair, still has issues.  I think that if #2 works, this just becomes a follow-up, though.

2.  Envmap:  I'd love to see the code for using an envmap, but what I really want is for it to reflect the skybox, so that it'll be closer to environmental conditions.  You've said "it's not a cube" twice- could've sworn the skyboxes used cubemaps, guess I'll have to check it out. 

Using a static envmap will look pretty horrible if the envmap is for daytime but the map is at night, for example; the skybox should basically replace the distant light for specular purposes.  If done right, it provides a pretty good fast approximation of global illumination and gets rid of some lighting calculations.  I've done this elsewhere, I just haven't had time to look at what I'll have to change to make it happen here.

3.  Point Lights:  Yeah, I'm puzzled about this one, I dunno anything about point lights and normalmaps yet; guess I'll have to do some reading   There are other alternatives, such as toning down the vertex lighting except at places where the specular result should peak, that probably would be a faster and cheaper alternative while providing reasonable performance.

You mean use the alpha channel for specular lighting? To me it seems that it should already do this, however, Ive not yet tried it out or figured out how it works exactly in the code.

No, just simple self-illumination, i.e., it glows in the dark, ignoring lighting results according to a control variable, usually an alpha channel (I built a shader that used RGB for spec, glow and reflect values once, because RGB DXT1 is as cheap as an alpha for DXT5 in terms of memory). 

It's an easy thing to code, I'll just do it this evening.

[cmpxchg8b]

2.  Envmap:  I'd love to see the code for using an envmap, but what I really want is for it to reflect the skybox, so that it'll be closer to environmental conditions.  You've said "it's not a cube" twice- could've sworn the skyboxes used cubemaps, guess I'll have to check it out.

I don't think the skyboxes use cubemaps, but you should be able to. To tell the engine that the environment texture is a cubemap you need to set the 0x40 flag (I think it's the 7th in the OpenBRF dialog: "unused (?)").

[Barabas]

*snip*

Alright thanks for the info

1. You are right there.


2. The skyboxes you see are just spheres with a rectangular texture on them I think. At least that's the impression I got when going through all the brfs. And looking at the original envmaps, they are shperical. Anyway, I've no idea how one would get the skybox texture into the shader. It does take into account the sun color, so that already helps quite a lot. Generally I don't think it looks too bad. My shader has some issues, especially on snow maps though, so I have to sort out a few things yet.

[xenoargh]

I don't think the skyboxes use cubemaps, but you should be able to. To tell the engine that the environment texture is a cubemap you need to set the 0x40 flag (I think it's the 7th in the OpenBRF dialog: "unused (?)").

That is interesting, and will need to be tested; I'm used to working with cubemaps, not the way they've set these up.  You're absolutely right, they're images wrapped around a sphere in an odd way, and they don't have a "ground", which explains a lot of things. 

I guess I need to take a long look at how they're referencing these images, though, and whether they're using the HDR stuff for anything but final bloom.   IDK whether that flag actually works, either, and I'm not sure how I'd set up a test for it to see yet.

All this can wait; for now I need to deal with the glow and then I think I'll take a look at what happens when I make a new shader entirely; the more I think about it, the more I think standart_shader needed to be at least two or three specific types with as little branching as possible.

[Barabas]

I really honestly think that the standart_shader is not written for best performance (GPUs do not like IF statements and lots of conditional checks) so eventually I'll be splitting it out to two versions, one with spec and all bells and whistles, one without, if the engine will let me

Probably true, it's quite a mess. However I was under the impression that while compiling the shaders, that it just build a shader for every technique you define. So that it already has seperate code for when you call "standart_noskin_nobump_nospec" and "standart_noskin_bump_specmap_Instanced" for example. Or am I being naive and optimistic?

You can 'easily' make new shaders though. You just have to put them in a brf in your mod, make them point at the right technique and set all the right flags and texture acces things. I don't really understand those, so for my extra shader I just copied/merged some values from other shaders ^^

[xenoargh]

If it's not an #include, it's a branch; there's quite a lot of if/then in there that can go

Yeah, it'll mean a new core shader reference, but it should be worth it, IIRC the last time I dealt with this, splitting two shaders out to eliminate branching resulted in a reasonable performance increase. 

Well, that, and I need something I don't mind trashing, now that I have a specular result roughly like what I wanted.  It wants some content values that aren't standard to operate perfectly, so I'll have to split things for now anyhow, until the content catches back up.

[Barabas]

Hmmm.... thats weird, cause I was just optimizing the main_standart shader and my compiled filesize did go down when I put some stuff in a if(use_specularfactor){blablabla}. (I was moving some stuff from the pixel to the vertex shader that's the same for the whole scene/model anyway, like vMaterialColor, SunColor and SpecularColor.) And my guess is smaller filesize means less instructions =D

[xenoargh]

Oho, that stuff must get cut when the true-false stuff is set in the compiler instructions that follow for each sub-variant.  Good catch, that explains a lot

[Barabas]

Oh whoops... I misread the size, it's actually bigger now   
I wonder why...

I'll try out some stuff and report back

[cmpxchg8b]

Instructions like

Code: [Select]

if(use_specularmap) or

Code: [Select]

if(use_skinning)all reference function parameters that are known at compile time, so they won't generate any actual branching in the shaders.

However, instructions like

Code: [Select]

if(bUseMotionBlur)referencing a global set by the engine at runtime, will result in branching.

If you aren't sure whether your shaders are getting optimized properly, run D3DXDisassembleEffect on them and check the generated assembly.

[Barabas]

Yeah you are right. I found why the filesize increased, it has this:

Code: [Select]

#ifdef USE_PRECOMPILED_SHADER_LISTS
//use_bumpmap, use_skinning,
VertexShader standart_vs_noshadow[] = { compile VS_X vs_main_standart(PCF_NONE, 0,0),
compile VS_X vs_main_standart(PCF_NONE, 0,1),
compile VS_X vs_main_standart(PCF_NONE, 1,0),
compile VS_X vs_main_standart(PCF_NONE, 1,1)};

VertexShader standart_vs_default[] = { compile VS_X vs_main_standart(PCF_DEFAULT, 0,0),
compile VS_X vs_main_standart(PCF_DEFAULT, 0,1),
compile VS_X vs_main_standart(PCF_DEFAULT, 1,0),
compile VS_X vs_main_standart(PCF_DEFAULT, 1,1)};
                           
VertexShader standart_vs_nvidia[] = { compile VS_X vs_main_standart(PCF_NVIDIA, 0,0), //ps_main_standart compiled versions?!
compile VS_X vs_main_standart(PCF_NVIDIA, 0,1),
compile VS_X vs_main_standart(PCF_NVIDIA, 1,0),
compile VS_X vs_main_standart(PCF_NVIDIA, 1,1)};

#define DEFINE_STANDART_TECHNIQUE(tech_name, use_bumpmap, use_skinning, use_specularfactor, use_specularmap, use_aniso, terraincolor) \
technique tech_name \
{ pass P0 { VertexShader = standart_vs_noshadow[(2*use_bumpmap) + use_skinning]; \
PixelShader = compile PS_2_X ps_main_standart(PCF_NONE, use_bumpmap, use_specularfactor, use_specularmap, false, use_aniso, terraincolor);} } \
technique tech_name##_SHDW \
{ pass P0 { VertexShader = standart_vs_default[(2*use_bumpmap) + use_skinning]; \
PixelShader = compile PS_2_X ps_main_standart(PCF_DEFAULT, use_bumpmap, use_specularfactor, use_specularmap, false, use_aniso, terraincolor);} } \
technique tech_name##_SHDWNVIDIA \
{ pass P0 { VertexShader = standart_vs_nvidia[(2*use_bumpmap) + use_skinning]; \
PixelShader = compile PS_2_X ps_main_standart(PCF_NVIDIA, use_bumpmap, use_specularfactor, use_specularmap, true, use_aniso, terraincolor);} }  \
DEFINE_LIGHTING_TECHNIQUE(tech_name, 0, use_bumpmap, use_skinning, use_specularfactor, use_specularmap)

and I changed the last part to:

Code: [Select]

#define DEFINE_STANDART_TECHNIQUE(tech_name, use_bumpmap, use_skinning, use_specularfactor, use_specularmap, use_aniso, terraincolor) \
technique tech_name \
{ pass P0 { VertexShader = compile VS_X vs_main_standart(PCF_NONE, use_bumpmap, use_skinning); \
PixelShader = compile PS_2_X ps_main_standart(PCF_NONE, use_bumpmap, use_specularfactor, use_specularmap, false, use_aniso, terraincolor);} } \
technique tech_name##_SHDW \
{ pass P0 { VertexShader = compile VS_X vs_main_standart(PCF_DEFAULT, use_bumpmap, use_skinning); \
PixelShader = compile PS_2_X ps_main_standart(PCF_DEFAULT, use_bumpmap, use_specularfactor, use_specularmap, false, use_aniso, terraincolor);} } \
technique tech_name##_SHDWNVIDIA \
{ pass P0 { VertexShader = compile VS_X vs_main_standart(PCF_NVIDIA, use_bumpmap, use_skinning); \
PixelShader = compile PS_2_X ps_main_standart(PCF_NVIDIA, use_bumpmap, use_specularfactor, use_specularmap, true, use_aniso, terraincolor);} }  \
DEFINE_LIGHTING_TECHNIQUE(tech_name, 0, use_bumpmap, use_skinning, use_specularfactor, use_specularmap)

This is just the same as the rest of the "DEFINE_..._TECHNIQUE" stuff, and would be easier if I want to include use_specularfactor in the vertex shader. However my filesize increases from 1.165 KB to 1.356 KB. This is very strange to me, I wouldn't think it matters if you use these booleans or some crazy sum hack thing. Deleting the "VertexShader standart_vs_noshadow[] =" lines reduces it again to 1.295 KB. This is totally beyond me ^^

[Faunus]

You can do some pretty neat stuff with te Post FX shaders. I've been trying to implement a SSAO shader.. not quite happy with the results, but once I get it fine-tuned, I'll post it here. Besides that... depth of field, blur, radial blur, tintage (e.g all scenes appear darker or with a green tint etc).