[map] Shader fun - this is a dev blog
[map] Shader fun - this is a dev blog
The final goal of this work is supposed to be screen-space dynamic lights. Join me on my rocky road to nowhere.
Since I couldnt figure out how to render the normals of the screen space to a target, I just figured the next best thing would be to just calculate them from the depth buffer. The depth buffer stores how far a pixel on screen is from the camera, so we can basically think of it as a heightmap from eye space.
Vote if this is a bad idea:
Since I couldnt figure out how to render the normals of the screen space to a target, I just figured the next best thing would be to just calculate them from the depth buffer. The depth buffer stores how far a pixel on screen is from the camera, so we can basically think of it as a heightmap from eye space.
Vote if this is a bad idea:
Re: Shader fun - this is a dev blog
First CarRepairer and now Behe... working on a new widget: using a kinect it is measured how much drugs a player took, and then the appropriate psychodelic theme is turned on?
Re: Shader fun - this is a dev blog
As you can see you can only reconstruct geometric normals, not smoothly interpolated ones, which is a limiting factor. Another is that you don't have any material information (diffuse / specular / whatever) at hand to influence the lighting. Still, for the poor man's approach to deferred rendering it ain't bad
Re: Shader fun - this is a dev blog
I am most interested in what will happen on the areas where there are large depth jump at the edges of the models. There the eye-space normals become almost perpendicular to the eye vector.
But at the moment I'm having trouble transforming the eye-space normal into world space in order to do the dot/length cosine to get the level of illumination at that point. Any tips there would be super helpful.
Edit: I am also wondering on how many spectacular levels of fail it will produce with transparent things like cegs and water.
But at the moment I'm having trouble transforming the eye-space normal into world space in order to do the dot/length cosine to get the level of illumination at that point. Any tips there would be super helpful.
Edit: I am also wondering on how many spectacular levels of fail it will produce with transparent things like cegs and water.
Re: Shader fun - this is a dev blog
You'll get shading discontinuities, the strength of which will depend on depthbuffer precision.
Don't work in worldspace, you only need to back-transform every pixel (and forward-transform every light position) to eyespace.
Don't work in worldspace, you only need to back-transform every pixel (and forward-transform every light position) to eyespace.
Re: Shader fun - this is a dev blog
Ok, ill try to transform the light source into eye space then. Im guessing I should do that on the cpu, as its only needed once.
Thanks for the tips man!
Edit: Im using 24Floats for depth buffer atm, no reason not to use 32 bits, no? I recall something about a zbuffer selection of 16/24 bits in springsettings. Is that the same zbuffer that is used for triangle depth sorting?
Edit2: cool, pre transforming to eye space makes culling easier:)
Thanks for the tips man!
Edit: Im using 24Floats for depth buffer atm, no reason not to use 32 bits, no? I recall something about a zbuffer selection of 16/24 bits in springsettings. Is that the same zbuffer that is used for triangle depth sorting?
Edit2: cool, pre transforming to eye space makes culling easier:)
Re: Shader fun - this is a dev blog
im having a little trouble with the non linearity of eye space z buffer. how do you suggest i deal with this?
Re: Shader fun - this is a dev blog
The only real ways of dealing with it would be to use either an orthographic projection (no z-divide forcing hyperbolically distributed depth precision) or a w-buffer. Neither of those is an option though.
Re: Shader fun - this is a dev blog
IIRC, the fog fragment shader widget that I wrote so long ago
used screen space depth buffer information to calculate the
distance from the viewer. Maybe you could take a look at that...
used screen space depth buffer information to calculate the
distance from the viewer. Maybe you could take a look at that...
Re: Shader fun - this is a dev blog
https://github.com/jk3064/Map-Blueprint ... t.lua#L279
trepan's attempt does well for fog, but is not 100% correct and so creates visual differences when used for deferred lighting. Instead of wasting hours in rewinding the math to fix the 5% error, I would choose the easy path -> convert the z-buffer back to worldspace by multiplying with inverse cam-matrix.
That way you may waste a few gpu cycles, on the other hand it will always work and gives ~100% correct results -> KISS
trepan's attempt does well for fog, but is not 100% correct and so creates visual differences when used for deferred lighting. Instead of wasting hours in rewinding the math to fix the 5% error, I would choose the easy path -> convert the z-buffer back to worldspace by multiplying with inverse cam-matrix.
That way you may waste a few gpu cycles, on the other hand it will always work and gives ~100% correct results -> KISS
Re: Shader fun - this is a dev blog
Im using trepans fog shader as a base (the one you linked), and it seemed to me that it is doing the accurate inverse cam matrix multiplication you mention. Am I incorrect?
Re: Shader fun - this is a dev blog
my post wasn't accurate it seems
I didn't posted trepan's way, neither have any idea if I have a copy left of it.
I posted the link to my `fixed` version of it with matrix-inv.
I didn't posted trepan's way, neither have any idea if I have a copy left of it.
I posted the link to my `fixed` version of it with matrix-inv.
Re: Shader fun - this is a dev blog
awesome, thanks. i am using the fized version then.
Re: Shader fun - this is a dev blog
Cool, I didnt think this would work, but it does!
And the error on edges caused by computing the normals from depth map is actually a feature, as it does a 'black edge highlighting' style thing.
Talk about waste of gpu cycles?
Does anyone know why stuff like healthbars and ETA timers get drawn before the bloom shader (which is at level -10000)?
And the error on edges caused by computing the normals from depth map is actually a feature, as it does a 'black edge highlighting' style thing.
Talk about waste of gpu cycles?
Code: Select all
vec2 up2 = gl_TexCoord[0].st + vec2(0 , inverseRY);
vec4 up4 = vec4(vec3(up2.xy, texture2D( tex0,up2 ).x) * 2.0 - 1.0 ,1);
up4 = viewProjectionInv * up4;
up4.xyz = up4.xyz / up4.w;
vec2 right2 = gl_TexCoord[0].st + vec2(inverseRY , 0);
vec4 right4 = vec4(vec3(right2.xy, texture2D( tex0,right2 ).x) * 2.0 - 1.0 ,1);
right4 = viewProjectionInv * right4;
right4.xyz = right4.xyz / right4.w;
vec4 here4 = vec4(vec3(gl_TexCoord[0].st, texture2D( tex0,gl_TexCoord[0].st ).x) * 2.0 - 1.0 ,1);
here4 = viewProjectionInv * here4;
here4.xyz = here4.xyz / here4.w;
vec4 herenormal4;
herenormal4.xyz = -1*normalize(cross( up4.xyz - here4.xyz, right4.xyz - here4.xyz));
float dist=length(lightpos.xyz - here4.xyz);
float cosphi=dot(herenormal4.xyz, lightpos.xyz - here4.xyz)/dist;
gl_FragColor=vec4(1,1,1, cosphi*(lightpos.w/(dist*dist)));
Re: Shader fun - this is a dev blog
This is amazing, everything works in the deferred lighting!
Supports hundreds of light sources simultaneously, as it only renders each light's area of influence. Lights can stack. Performance is similar to the projectile lights widget, but the looks are a whole new class.
Works best with a little bloom. May even make sense to post-blur the whole thing before blending.
Drawbacks are the usual drawbacks: normals are computed
No shadows, can interfere with transparent CEGS.
Supports hundreds of light sources simultaneously, as it only renders each light's area of influence. Lights can stack. Performance is similar to the projectile lights widget, but the looks are a whole new class.
Works best with a little bloom. May even make sense to post-blur the whole thing before blending.
Drawbacks are the usual drawbacks: normals are computed
No shadows, can interfere with transparent CEGS.
Re: Shader fun - this is a dev blog
Now I see how awesome it would be to have real MRT with a normal texture buffer...
Re: Shader fun - this is a dev blog
I've been waiting for this for years
Re: Shader fun - this is a dev blog
Falcrum, you can test it, its in BAR. Just join the polonium autohost to have rapid download the mod for you.
For my next trick, I plan to try screen-space ambient occlusion.
My GPU still has plenty of overhead after turning on all the bells and whistles. And its just a now 2 generations old gtx 560 ti.
Maybe after that, Ill fold in the old LOS shader. But I wish I could do changes to that;
Calculating the LOS texture is quite expensive, especially if you want to do it often (extratextureupdaterate=4, which is the max). Since the LOS texture is a synced read operation, it would be nice if I could split it out of the main thread, and have it run 1 sim frame behind, but every frame.
For my next trick, I plan to try screen-space ambient occlusion.
My GPU still has plenty of overhead after turning on all the bells and whistles. And its just a now 2 generations old gtx 560 ti.
Maybe after that, Ill fold in the old LOS shader. But I wish I could do changes to that;
Calculating the LOS texture is quite expensive, especially if you want to do it often (extratextureupdaterate=4, which is the max). Since the LOS texture is a synced read operation, it would be nice if I could split it out of the main thread, and have it run 1 sim frame behind, but every frame.
Re: Shader fun - this is a dev blog
Ok, got the Infotex based LOS shader ready too, but it needs a few engine changes to look good. Here is the plan for unifying the deferred pipeline:
Shaders are red, textures are blue, intermediate buffers are green.
Any thoughts are welcome!
Shaders are red, textures are blue, intermediate buffers are green.
Any thoughts are welcome!
Re: Shader fun - this is a dev blog
nice work, can you upload it here ? the autohost downloading strange .gz files, I can't make out where the .lua file is
n/m I got it from the repository, thanks !
n/m I got it from the repository, thanks !