B Info Shader Shader Stuff- HLSL instruction limits

Users who are viewing this thread

Conceptually you can just add an offset to vertex position modulated by sine functions of time + position. Now I have no idea for Warband whether you can edit vertex shader and if so whether there's a time parameter to modulate with.
 
Chaingun said:
Conceptually you can just add an offset to vertex position modulated by sine functions of time + position. Now I have no idea for Warband whether you can edit vertex shader and if so whether there's a time parameter to modulate with.

There is. It's not easy to make them wobble realisticly though. And you have to find some way to wobble only the tips not the roots ^^
Using the position within the model coordinates doesn't work as automaticaly generated flora doesn't have those.
 
Computica said:
Barabas said:
Alright, well it is supposed to work :p
Everything multiplies there anyway, so.

If you have any other cool ideas for ways of using textures or anything. I'm all ears. I can't really think of anything  :shock:
I've been trying to figure out how to make the plant/tree shaders wobble. Does anyone know how to that in HLSL?

Shing a ding!

You'll probably want to talk to Slawomir or Tuls from the WFaS mod.
 
I just managed to compile everything using vs_3_0 and ps_3_0 ^^
And it works in-game as well... apart from the fog, that somehow dissapeared  :shock: :eek:
Same for underwater effects  :sad:

!!This might not be the best idea if you don't know what you're doing!! (like me)
 
What should be done is to make it PS / VS 2 compliant; this can be done with vertex painting methods (VS 2 is not allowed to read pixels, but may read vertex colors).  The hard part is randomizing the system a bit so that the results exhibit some patterns of gross and tip motion that are dissimilar and feel natural.  I did this with another engine by generating per-object uniforms sent to the shader, but there are probably ways to achieve a similar sense of randomness via using the world-space coordinates of the thing.
 
Does anyone know why compiling with vs and ps 3 would break the fog?
If we can fix that you would be able to actually read textures in the vertex shader =)
 
Fog may be using FFP; I don't have a better answer yet until I've had a chance to look at some things.  I'm not entirely sure that using VS 3.0 is as trouble-free as VS 2, though; you may run into fairly severe ATI / nVidia issues, and I don't think the engine returns a lot of details if a shader crashes.
 
Ahh.. alright. I already wondered where the Out.Fog went after the vertex shader. Never comes back into the pixel shaders.
It's not very important anyway.
 
You can re-implement fog, though, I think; you'd have to get world-space coordinates for the vertex and compare to the camera's position; I *think* that is possible without having to send it a uniform... maybe get the length of the eye vector?  Should be possible to get the fog's strength, attenuation etc. from the existing inputs; it's probably just not getting along with the pixel shader. 

Might get into a fair amount of math on the pixel shader, though. 

I should prolly shut up, I will have to look at various things before my competence with HLSL and the DX rendering system is vaguely useful, so this may all be wrongo; sorry if it causes any wasted time :wink:
 
What it does is this:

Code:
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:
	return 1.0f / exp2(d * fFogDensity);

So it could be fairly easy to add that in the pixel shader.
 
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).
 
Barabas said:
What it does is this:

Code:
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:
	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.
 
xenoargh said:
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.

xenoargh said:
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

xenoargh said:
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.

xenoargh said:
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.

xenoargh said:
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.

Vincenzo said:
Barabas said:

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 ^^)
 
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 :smile:

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 :smile:  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.
 
xenoargh said:
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 (?)").
 
xenoargh said:

Alright thanks for the info :smile:

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.
 
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.
 
xenoargh said:
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 :smile:

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? :razz:

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 ^^
 
If it's not an #include, it's a branch; there's quite a lot of if/then in there that can go :smile:

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.
 
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
 
Back
Top Bottom