[map] Shader fun - this is a dev blog

[map] Shader fun - this is a dev blog

Happenin' news on what is happening in the community. Content releases, new tutorials, other cool stuff.
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

[map] Shader fun - this is a dev blog

Post by Beherith »

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:
Image
dansan
Server Owner & Developer
Posts: 1203
Joined: 29 May 2010, 23:40

Re: Shader fun - this is a dev blog

Post by dansan »

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?
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: Shader fun - this is a dev blog

Post by Kloot »

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 ;)
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: Shader fun - this is a dev blog

Post by Beherith »

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.
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: Shader fun - this is a dev blog

Post by Kloot »

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.
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: Shader fun - this is a dev blog

Post by Beherith »

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:)
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: Shader fun - this is a dev blog

Post by Beherith »

im having a little trouble with the non linearity of eye space z buffer. how do you suggest i deal with this?
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: Shader fun - this is a dev blog

Post by Kloot »

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.
trepan
Former Engine Dev
Posts: 1200
Joined: 17 Nov 2005, 00:52

Re: Shader fun - this is a dev blog

Post by trepan »

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...
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Shader fun - this is a dev blog

Post by jK »

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
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: Shader fun - this is a dev blog

Post by Beherith »

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?
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Shader fun - this is a dev blog

Post by jK »

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.
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: Shader fun - this is a dev blog

Post by Beherith »

awesome, thanks. i am using the fized version then.
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: Shader fun - this is a dev blog

Post by Beherith »

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.

Image

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)));
Does anyone know why stuff like healthbars and ETA timers get drawn before the bloom shader (which is at level -10000)?
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: Shader fun - this is a dev blog

Post by Beherith »

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.

Image
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: Shader fun - this is a dev blog

Post by Beherith »

Now I see how awesome it would be to have real MRT with a normal texture buffer...
User avatar
Falcrum
Posts: 149
Joined: 14 Nov 2007, 01:03

Re: Shader fun - this is a dev blog

Post by Falcrum »

I've been waiting for this for years
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: Shader fun - this is a dev blog

Post by Beherith »

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.
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: Shader fun - this is a dev blog

Post by Beherith »

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.

Image

Any thoughts are welcome!
Manoa
Posts: 79
Joined: 19 May 2008, 18:51

Re: Shader fun - this is a dev blog

Post by Manoa »

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 !
Post Reply

Return to “Community Blog”