[Eldorado.Railroad]

Looking through SceneryShader.fx (hours of experimenting!):

Quote

float _PSGetShadowEffect(uniform bool ShaderModel3, uniform bool NormalLighting, in VERTEX_OUTPUT In)
float3 moments;
if (ShaderModel3)
moments = _PS3GetShadowEffect(In);
else
moments = _PS2GetShadowEffect(In);

bool not_shadowed = moments.z - moments.x < 0.00005;

I am puzzled....quite puzzled. moments is a variable that contains the coordinates of 3 points in space, correct? Or are we using the information "verbatim" from a shapefile etc:

Quote

vertex ( 00000000 42 40 ffffffff ff000000
vertex_uvs ( 1 110 ))

So how can a single point in space, unless everything is referenced to a known origin such as (0,0,0) be used to determine the criteria for gating whether a dynamic shadow is to be created or not? Are all points in XNA/OR space, positive values?

If I have it wrong please don't jump all over my head on this one, but please explain exactly how what seems like a single vertex is used to determine anything about the size of a polygon which the vertex in question belongs to?

When I refresh some ancient memory I recall this moment and this moment too. But a single point in space will not help much...???

Thanks so much for your help on this one.

[James Ross]

Eldorado.Railroad, on 10 March 2014 - 08:23 PM, said:

I am puzzled....quite puzzled. moments is a variable that contains the coordinates of 3 points in space, correct? Or are we using the information "verbatim" from a shapefile etc:

"moments" is the result of calling _PS3GetShadowEffect() or _PS2GetShadowEffect(). It's not a point in space, it's just three bits of data. If you look at how variance shadow maps work, e.g. http://msdn.microsof...esktop/ee416307, there are two values stored in the shadow map: depth and depth squared. These are returned from the GetShadowEffect functions in slots 'x' and 'y'. The other value is the depth of the current pixel being drawn. This is returned in slot 'z'.

The code is then comparing the pixel's depth with the shadow map's depth with a small margin of 0.00005, due to the errors in floating point calculations.

Eldorado.Railroad, on 10 March 2014 - 08:23 PM, said:

When I refresh some ancient memory I recall this moment and this moment too. But a single point in space will not help much...???

I believe the term "moment" as used here is the mathematical term; it is actually from the paper on VSMs which you can get as a PDF from http://dl.acm.org/ci...1111411.1111440 (linked from the MSDN doc above).

[Eldorado.Railroad]

James,

I think I was thrown off the trail here by the use of the word "moments", which given the complexity of what is involved does not describe to the "casual" onlooker that we are talking about "depths". On this side of the screen, a major "face palm"! From the MSDN article you sent me I can see a pretty close correlation to what we have in OR, a big thank you for pointing me in that direction. Seems like I have been using the wrong "google" incantations to get my info!

In the process of experimenting I have come across a whole bunch of these things. MSDN seems to be very skimpy on code solutions for the problems. Too bad.

From the descriptions here Cascaded Shadow Maps, the one thing that I can report (and I am sure you know very well) is that some unwanted shadow artifacts can be controlled by the "MAGIC_NUMBER" in:

fPercentLit = pow( p_max, MAGIC_NUMBER );

The biggest problem seems to be the self shadowing of the terrain at certain light angles. When the "MAGIC_NUMBER" is manipulated (and few other minor but not unsubstantial changes are made in SceneryShader.fx) I can achieve acceptable quality for either the objects on the terrain or the terrain itself, but not both at the same time.

This leads me to this next question. Would it be too difficult and complex to differentiate between the terrain and objects on the terrain when it comes to handling the vertex shader call? In other words, there would be an additional boolean that is passed to PSGetShadowEffect that could be used to set among other things the "MAGIC_NUMBER" inside of the pixel shader HLSL. I realize fully that some trickery will be needed to satisfy the variable contraint of SM2, but I know that something significant could be done with SM3.

Thank you!

[James Ross]

Eldorado.Railroad, on 11 March 2014 - 08:01 AM, said:

From the descriptions here Cascaded Shadow Maps, the one thing that I can report (and I am sure you know very well) is that some unwanted shadow artifacts can be controlled by the "MAGIC_NUMBER" in:

fPercentLit = pow( p_max, MAGIC_NUMBER );

The biggest problem seems to be the self shadowing of the terrain at certain light angles. When the "MAGIC_NUMBER" is manipulated (and few other minor but not unsubstantial changes are made in SceneryShader.fx) I can achieve acceptable quality for either the objects on the terrain or the terrain itself, but not both at the same time.

This leads me to this next question. Would it be too difficult and complex to differentiate between the terrain and objects on the terrain when it comes to handling the vertex shader call? In other words, there would be an additional boolean that is passed to PSGetShadowEffect that could be used to set among other things the "MAGIC_NUMBER" inside of the pixel shader HLSL. I realize fully that some trickery will be needed to satisfy the variable contraint of SM2, but I know that something significant could be done with SM3.

Fiddling with the magic number in the pow() and the error value I mentioned before (in the moments comparison) is what I spent hours and hours doing when making the shadow code and on subsequent changes to it. :good:

Certainly for SM3, we should be able to pass in a true or false for terrain vs. not-terrain (or something along those lines) and change the behaviour appropriately. I'd be interested in seeing the different sets of changes for each.