• Create Account

# What to do with an attenuated light vector in my shader

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

12 replies to this topic

### #1Daniel Wilson  Members   -  Reputation: 159

Like
0Likes
Like

Posted 05 July 2012 - 11:22 AM

Hi, I am working on implementing a subsurface scattering light shader and have it all coded I just need to debug. I have a question I cannot solve though, say I have the attenuated light vector that has come from the light, scattered as it enters the surface of the object, and now goes to the viewers eye. What would I do with this output vector for for a mesh that has a standard Blinn-Phong shader? The image has the vector I am talking about, vector PC

In my normal lighting shader I have this:


float3 l = normalize(IN.light.xyz - IN.oPosition);
float3 v = normalize(IN.oPosition);

// compute diffuse and specular terms
float diff = saturate(dot(l,IN.normal));
float spec = saturate(dot(normalize(l-v),IN.normal));
spec = pow(spec, shine);
// attenuation factor
float att = saturate(dot(l, IN.normal));

// compute final color
float3 finalcolor;
finalcolor =  ambient.xyz*color.xyz +
att*(color.xyz*diffuse.xyz*diff +
specular*spec);

return float4(finalcolor.xyz, 1.0);


With no normal map or anything, how might I slot PC into this code. I'm thinking it would replace the view direction v that I have. Someone else told me the *= it with the final colour, but that just produces weird rainbow type colours, and my light is white

### #2shiqiu1105  Members   -  Reputation: 111

Like
0Likes
Like

Posted 05 July 2012 - 09:16 PM

How do you implement the SSS effect?? it's an approximation?

### #3Daniel Wilson  Members   -  Reputation: 159

Like
0Likes
Like

Posted 06 July 2012 - 06:30 AM

How do you implement the SSS effect?? it's an approximation?

It is a single scattering approximation, using cg. The paper is called subsurface texture mapping and is located here . It uses a texture to encode depth in the rgba channels, where red is the first layer, alpha is the bottom layer etc. So light enters the mesh, becomes attenuated from this texture and lots of other calculations, then leaves afaik. So I'm not really sure what to do with the light that leaves then. My current guess is that it would replace the l vector in the above code (rather than subtracting the light pos from the pixel position).

### #4Daniel Wilson  Members   -  Reputation: 159

Like
0Likes
Like

Posted 09 July 2012 - 08:39 PM

My theory now is that I could just multiply the final colour by the result. Anyone know if this is correct? My result may be wrong at the moment, its pretty blue so multiplying by the final colour is really removing most of the diffuse colour for a dark blue though....

### #5Daniel Wilson  Members   -  Reputation: 159

Like
0Likes
Like

Posted 06 August 2012 - 09:18 AM

So I didn't quite figure this out yet because it's quite a complex shader. I would lke to implement this shader with a basic phong model.

Say I have this:

[source lang="cpp"] float3 BumpNormal = tex2D(nm, IN.texcoord)*2.0 - 1.0; float4 amb = AmbientIntensity * ambient; float4 diff = DiffuseIntensity * diffuse * saturate(dot(IN.worldLightDir,BumpNormal)); float3 R = normalize(2.0 * dot(BumpNormal, IN.worldLightDir) * BumpNormal - IN.worldLightDir); float3 v = normalize(IN.eye); float spec = pow(saturate(dot(R,v)), specularPower) * SpecularIntensity; // compute final color float4 color = tex2D(color_map,IN.texcoord); float4 finalcolor = (amb + diff + spec) * color;[/source]

R and V are purely directional vectors right? So my attenuated light vector must represent a direction and the intensity of the light that is returned to the viewer I think. In the above code the only thing that strikes me as close to this is the calculation of the diffuse value. Ignoring the bump map (I don't need bumped normals), does anyone know if it would be wrong to have:
[source lang="cpp"]float4 diff = DiffuseIntensity * diffuse * p_omega_out;[/source]
Where p_omega_out is the attenuated light intensity/direction? I think my vector needs to go from the pixel to the viewer, would this vector do that?!

### #6Hodgman  Moderators   -  Reputation: 45748

Like
1Likes
Like

Posted 06 August 2012 - 09:36 AM

Specular lighting is light that reflects off the surface, without entering the material at all, so your SSS code definately shouldn't modulate the specular contribution.

Diffuse lighting is light that refracts into the object, bounces around inside, and later re-emerges. In standard lighting models, we use the simplification that the diffuse exit points are all located at the entry point (there is no movement inside the material).

SSS expands this by making the diffuse model more advanced -- instead of just using a constant diffuse colour, you use your chosen technique (a multi-layered texture, in your case) to calculate the colouration of the diffuse light, and to calculate how far inside the material the diffuse light travels before re-emerging (which has a blurring effect on the diffuse light).

Regarding attenuation: standard lighting will calculate the attenuation from the light-source to the material (from S to K in your original diagram), which affects the amount of light that reaches the surface in the first place (before it's split into diffuse-refraction/specular-reflection). In standard blinn-phong, internal diffuse attenuation is specified by a constant value: your "diffuse colour".
When you extend this with SSS, the "diffuse colour" is instead calculated by the internal attenuation from K to M, and M to P -- the details of that specified by your chosen technique.

### #7Daniel Wilson  Members   -  Reputation: 159

Like
0Likes
Like

Posted 06 August 2012 - 11:31 AM

In standard blinn-phong, internal diffuse attenuation is specified by a constant value: your "diffuse colour".
When you extend this with SSS, the "diffuse colour" is instead calculated by the internal attenuation from K to M, and M to P -- the details of that specified by your chosen technique

Ah okay this is interesting thank you. You see the paper assumes you just know what to do with the output vector that has been attenuated from K-M-P. So theoretically it should be okay to use it in place of a hard coded "diffuse" value I did have, e.g.:
[source lang="cpp"]float4 diff = DiffuseIntensity * p_omega_out * saturate(dot(IN.worldLightDir,BumpNormal));[/source]
At the moment if I output p_omega_out as a colour, the result is some pretty blurry bands of colour, so hopefully it won't damage the rest of the colour too much. (I'll post a screen cap in a few mins). Thanks

### #8Daniel Wilson  Members   -  Reputation: 159

Like
0Likes
Like

Posted 06 August 2012 - 06:28 PM

Okay so the p_omega_out value looks like this as a colour:

Applied to a simple plane. I'm not sure whether or not that's the correct output for it but that's what I have at the moment. If I slot it in to my phong normal mapped plane, I get this:

Which is pretty but obviously isn't right! So is p_omega_out wrong, or am I just putting it in the wrong place!? Here is the final part of the code for reference but the only change is the inclusion of the new attenuated vector:
[source lang="cpp"] float3 BumpNormal = tex2D(nm, IN.texcoord)*2.0 - 1.0; float4 amb = AmbientIntensity * ambient; float4 diff = DiffuseIntensity * float4(p_omega_out, 1) * saturate(dot(IN.tangentSpaceLightDir,BumpNormal)); float3 R = normalize(2.0 * dot(BumpNormal, IN.tangentSpaceLightDir) * BumpNormal - IN.tangentSpaceLightDir); float3 v = normalize(IN.tangentSpaceEye); float spec = pow(saturate(dot(R,v)), specularPower) * SpecularIntensity; // compute final color float4 color = tex2D(color_map,IN.texcoord); float4 finalcolor = (amb + diff + spec) * color; return finalcolor;[/source]

### #9Hodgman  Moderators   -  Reputation: 45748

Like
0Likes
Like

Posted 06 August 2012 - 11:14 PM

You see the paper assumes you just know what to do with the output vector that has been attenuated from K-M-P.

I'm having a hard time following any of your posts in this thread, because "attenuated light vector" doesn't seems like the right terminology for what you're trying to describe.

Also, I have no idea what p_omega_out is, or where those magic colours come from.
i.e. with the information given, I can't possibly help. Note my previous post was just general advice barely connected to your posts because of this.

Perhaps you should just post your full SSS shader code, and the input textures?

### #10Daniel Wilson  Members   -  Reputation: 159

Like
0Likes
Like

Posted 07 August 2012 - 12:33 PM

Woops sorry, I've gotten so deep into this thing I'm just assuming the whole world knows what I mean by p_omega_out . I appreciate the help and even general advice is very useful. Here is another screen from the paper which should be looked at with the image from the first post.

When I say p_omega_out, I mean the vector from the pixel P to the viewer.

Here is the fx composer file I have at the moment, it's rather large and based off of the algorithms in the paper which you would probably need to read in full to make sense of so I won't ask you to do that! I am applying this map as the subsurface texture map.

The file is attached here as well because it's not really displaying properly here.

### #11Hodgman  Moderators   -  Reputation: 45748

Like
0Likes
Like

Posted 07 August 2012 - 08:56 PM

Have you correctly plugged in matrix_tex with appropriate data?

### #12Daniel Wilson  Members   -  Reputation: 159

Like
0Likes
Like

Posted 07 August 2012 - 09:29 PM

Yeah should've mentioned that too sorry, I am certain that data is correct. This shader is actually being used in Ogre, and it's easy to generate the texture in Ogre and the output is virtually identical to fx composer. Each rgba component in the floating point texture just holds a preset scattering coefficient value taken from this table:

### #13Daniel Wilson  Members   -  Reputation: 159

Like
0Likes
Like

Posted 17 August 2012 - 01:12 PM

So I've been working on this a while longer, and the only real conclusion I have come up with is the colour values must be wrong. I thought for a while maybe they were right and I was not doing the correct thing with the result. I was given the good advice that:

The scattered radiance should be added to the phong radiance component because
the phong model computes the radiance at the surface only, the scattered radiance is
just more radiance coming from under the surface, to the eye.

So hopefully that might help some future googlers, now if if I could just work out the correct values to begin with! I knew the colours were too trippy

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS