linear sampling in frag shaders

[michagl]

this topic was inspired by the 'aproximating gaussian blur' thread... but i thought it better i post it indapendantly. the basic idea is the ins and outs of sampling an excessive number of times in a fragment shader.

i've been trying to get around to doing a radial disk fog effect with oscilating colours.

edit: the colours don't actually move though like a spinning disk -- though that would probably be a much cooler use of the effect and come for virtually free. i just meant the fog would oscilate between light and dark regions. ie. regions of greater and lesser atmosphereic scattering. another cool use for the effect might be to sample across a project cloud shadow or something. realisticly there is less fog under a heavy cloud cover because fog is just light reflecting off atmospheric particles, so where there is less light there should be less fog.

my idea so far has been to setup 4 intersection tests against a line segment and 2D planes. then lerp between the intersection points, and sum the outputs to get the total amount of fog along the line segment from the eye to the pixel.

but with this talk of sampling so intensely, i have to ask if it might be just as good to just sample the line segment so many times based on its length against a colour wheel type texture and just sum those samples to get the final fog value.

i guess i will try both... but could anyone give me a guess on which would be the more fruitful approach? i figure the sampling would introduce some dither type noise which might actually prove more visually appealing than a perfect sampling or might be totally distracting.

just trying to get a handle on whether or not all of this 'super' sampling is productive enough if applied say to every rasterized fragment.

edit: also just thought that using the colour wheel aproach would also mean much greater control over the actual colour of the fog along the radial axis for a more variable effect. also i'm curious if somehow mipmapping could be leveraged for sampling texels further from the eye. must fragment shaders do mipmapping manually or is the fragment early z depth used for mipmapping under special circumstances? how do you do mipmapping manually in a shader?

[michagl]

last night i got tired of programming the same old monolithic stuff and decided to take a break and do something fun...

here is the initial results:

http://arcadia.angeltowns.com/share/gaean-fog.jpg

here is the fragment shader:

// constants ////////////
 
#define SAMPLES 6 
 
#define POWER 0.3											
 
#define RANGE 1.0
 
#define DENSITY 1.95 
 
// derived constants ////
 
#define SCALE (1.0/(SAMPLES-1.0))
 
/////////////////////////
 
struct Input
{
	float4 colour	 : COLOR;
	float2 texcoords : TEXCOORD;
	float4 position	 : TEXCOORD2;
};
 
void main(Input IN,
		   uniform float4    Eye,
		   uniform sampler2D Fog, 
		   uniform sampler2D Map,
 
  	       out float4 colour : COLOR)
{	
	colour = tex2D(Map,IN.texcoords); colour*=IN.colour; 
 
//	colour = tex2D(Fog,IN.position.xz); 
 
//	colour = float4(0,IN.position.x*0.5+1,IN.position.z*0.5+1,1);
 
//	return;
 
	float4 delta = IN.position-Eye;
 
	float4 step = delta.xzxz; step*=SCALE*2.0;
 
	float4 turtle = float4(Eye.xz,Eye.xz+step.xy*0.5);
 
	float4 fog = float4(0,0,0,0); 
 
	for(int i=0;i<SAMPLES/2;i++)
	{
	    fog+=tex2D(Fog,turtle.xy); fog+=tex2D(Fog,turtle.zw); turtle+=step;
	}
 
	float distance = dot(delta,delta);
 
	distance = min(pow(distance,POWER)*fog.w*DENSITY*SCALE,RANGE)*(1.0/RANGE);
 
	colour = lerp(colour,fog*SCALE,distance); 	
}

perhaps a more readible form of the same code:

http://arcadia.angeltowns.com/share/gaean-fog_fp.cg.txt

here is the texture data:

http://arcadia.angeltowns.com/share/fog-mirror.png

there is supposed to be an alpha channel in there if the png conversion didn't keep it.

edit: hmmm, looks like the png is actually displaying the alpha channel as a transparancy.

basicly it is a per-pixel atmospheric scattering shader. the same technique could be used to do general earth atmospheric scattering seamlessly from the ground to outside earth orbit.

it looks very nice, even when the sampling is low it is guaranteed to be perfectly smooth . you could probably sample a spherical atmosphere about 4 times and get usable results... my current target looks fair enough with 6 samples which achieve the unique layered structure i was looking for.

i believe typical earth atmospheric scattering simulations envolve some fresnel refraction component... it doesn't deliver that, though i have some code for generating a per vertex earth atmosphere which i may look at to try to come up with a refractive component.

i have more to say and ask later regarding shader logistics, but i want to go ahead and post this bit.

sincerely,

michael

[michagl]

ok, after some time to think about it i only have a couple issues to add here.

of course i'm interested in any way i could maybe optimize this program. shader programming is not exactly something i do on a regular basis.

but mostly i'm interested in this bit of code:

	float4 delta = IN.position-Eye;
 
	float4 step = delta.xzxz; step*=SCALE*2.0;
 
	float4 turtle = float4(Eye.xz,Eye.xz+step.xy*0.5);
 
	float4 fog = float4(0,0,0,0); 
 
	for(int i=0;i<SAMPLES/2;i++)
	{
	    fog+=tex2D(Fog,turtle.xy); fog+=tex2D(Fog,turtle.zw); turtle+=step;
	}

it seems to me like there are a class of operations that don't map well to the vector hardware but are very useful in general.

basicly if you analyse the code above you will see that conceptually it is very simple. it is a lot like rasterizing a line to some extent. you have a point A in your texture and a point B... you want so many samples between the point and you want them all summed together.

effectively its a lot like looking through the line. maybe this is the only application for such a construct... i can't think of many others off the top of my head.

but in another post regarding 'relief mapping'...

[i will try to stick a link here]

... heavy use of linear and binary searches through texture space are utilized, which in escence are basicly the same sort of function... that is you are basicly sampling a line segment through the texture. the binary search is especially ill fit because it is heavily interdependant and especially can't really take advantage of vector hardware under many circumstances.

so it seems to me like these three functions and probably some others could easilly be unified in a hardware unit responsible for managing highly regular linear texture sampling and scheduling.

so i guess my final question is, might it be possible by say the next or following generation of shader specifications to perform a sample across a linear stretch of texture space and perform simple operations along the way such as summing, and linear and binary search etc, all encompassed in a single hardware mapped functionality.

i guess it all depends on the popularity of such functionality, so if nothing else i'm trying to popularize the usage here.

sincerely,

michael

[michagl]

oh, i'm also interested in mipmapping for this shader.

is it possible to control mipmapping manually in a shader? is this the same as texture depth sampling for light maps as explained in the Cg docs?

right now i'm just assuming that if the early z depth is such for a frag, it will be associated with the mipmap level that would normally be applied to a distant pixel.

it just happens for this shader that is the correct result... but i figure it isn't always.

so in the end what i'd really like to know is, for this shader, with no manual intervention and mipmapping enabled for the 'Fog' sampler, will mipmapping be applied with respect to the z depth of the in going fragment?

the idea is the sampling would probably be more accurately represented for sampling across a long distance if mipmapping is used to effectively up the sampling size.

sincerely,

michael

PS: sorry for the multipost internal monolog (or is it monologue?) thread... everyone wants to ream me for these kind of threads, but i'm just looking for some input. -michael

[zed]

is it possible to control mipmapping manually in a shader? is this the same as texture depth sampling for light maps as explained in the Cg docs?

dont think so, but check out texture lod bias

[michagl]

Originally posted by zed:

is it possible to control mipmapping manually in a shader? is this the same as texture depth sampling for light maps as explained in the Cg docs?

dont think so, but check out texture lod bias

yeah, i was planning on playing with that as soon as i determined whether or not the shader was actually utilizing the mipmapping.

i'm assuming you are implying that it is using mipmapping based on the early z depth of the fragment.

if you changed the depth of the fragment manually in a shader, would subsequent texture reads utilizing mipmapping be effected by this change?

[dorbie]

No he's implying no such thing. MIP LOD calculations have nothing to do with fragment z, it is calculated using screen space derivatives of texture coordinates. This is true even if a shader fetches a texture coordinate.

The bias mentioned is the fixed function texture unit MIP LOD bias available through the texture environment in the standard OpenGL API (version dependent).

http://oss.sgi.com/projects/ogl-samp...e_lod_bias.txt

[michagl]

i figured the bias was related to z depth.

ok, so there are Cg tex2D (sampling routines) functions which take an x and y derivitive along with the texture coordinates... could these be used to control mipmapping? any extra cost in using these overloads? i would really like to be able to utilize mipmapping with this shader.

finally just out of curiosity, there are cg tex?D functions which take for instance a 3d coordinate for a tex2D function. they are described as using 'depth compare' and some words at the bottom say this is for 'shadowmap lookup'... what is this about please? i've never actually intensively studied shadowmaps, but i thought i understood the general idea well enough. just out of curiosity can someone cue me in on why this functionality is so pervasive it is given an overload?

sincerely,

michael

[SirKnight]

PS: sorry for the multipost internal monolog (or is it monologue?) thread... everyone wants to ream me for these kind of threads, but i'm just looking for some input. -michael

I think you need to get yourself a blog. A blog makes much more sense for these kind of "self-discussions" which also desire input by others.

-SirKnight

[michagl]

apparently i'm not fit for bbs. i don't get it, so i guess i will just tune out.

first time i posted in here, everyone told me i'm not descriptive enough, then someone suggests a 'blog'... i don't understand why people can't relax and enjoy themselves.

its been useful, but its not worth all the hot breath down my kneck and constantly being chastised for completing a thought or not or whatever.

truthfully this sort of hostile behavior just discourages people from contributing, which is sad for the community and opengl.

i can't believe how few people are active in this forum. its opengl... there has to be more people than this doing serious work with opengl. they must be seriously afraid to post.

on one hand people act like this forum should be like a cooperative consulting firm or something, or maybe a 1-800 hotline. people can't discuss opengl, because they would rather try to find a solution any way they possibly can first rather than using the forum. to me this is a waste of a forum.

maybe elitest believe that only the most esoteric of discussion should be had here... but i'm sure the opengl community would be much better served with a vibrant forum.

the closest this forum gets to vibrant is the occasional stray newly registered member who is either turned out or patronized for the sake of someone's ego, then likely after the experience never posts again. and if they had monitored the forum for long would probably never have posted in the first place.

the fact that people expect contributors to come to the table with knowledge of every event in the cosmos first, and to check the forum logs for all previous discussion totally defeats the purpose of what a forum really is. this really isn't a 'forum' in any respect of the word.

anyhow, this bbs is too hostile and depressing for my capacities... so i'm seriously restricting my interaction to necessity if anything from now on. i've had my fill.

sincerely,

michael