dzPoint Lights

Szark

Are soft shadows broken for these lights as no matter the setting the shadows still remain sharp?

mjc1016

No, not broken...I don't think the 'softness' is connected to anything, not sure if it ever was. So if it wasn't ever connected, it can't be broken...right?

Szark

Thanks LOL Right....I think. Oh well back to Uber Point lights then.

SimonJM

Small lights, such as point lights do tend to produce sharp shadows. Size is relative so HUGE lights (such as the sun) a long way away will act like a smaller light source much closer.

Szark

Uber Point lights don't seem to have this problem Simon but yes with Ray Traced shadows the closer the object is to a surface the sharper the shadow is and vice versa.

mjc1016

In the code, there is an 'oddity' about the way the ShadowSoftness is connected...and it's been that way from the start. It doesn't match the 'formula' in the other two lights...so I'm 'borrowing' the formula from the spot and trying it. Yes, these three have the source code...or at least I have it, as they were example shaders in the DS3 scripting kit or SDK (can't remember which).

Szark

oh sweet let me know how you get on please mjc. I would love to be able to use these point lights with soft shadows as they work so well compared to Uber and the normal point lights with only discovering them with help from others here, namely my Russian friend. wonder if anyone has made a bug report about this?

mjc1016

Well...it works, sort of...using the other code does 'fuzz' the edge...ever so slightly. By removing the limit and cranking up the 'softness' to 10x the normal maximum it shows up a bit more, but not particularly 'soft' but rather a tad more jagged, as if it doesn't have enough 'room' to produce a gradient.

So, in a way, they are behaving 'more correctly'. They are keeping crisp edges like tiny lights should.

So, I was not quite right, yes they are 'connected' internally, but not the same as the other lights do them. And even correcting that doesn't give much in the way of 'softness' to the shadow.

You can use the shadow intensity slider to make them less intense overall...

Szark

Thank you for trying mjc, much appreciated. I did try a value higher than the fixed limit. I might try a stupidly high value and see what happens

mjc1016

Szark said:

Thank you for trying mjc, much appreciated. I did try a value higher than the fixed limit. I might try a stupidly high value and see what happens

Without the edit it doesn't matter, because the value ends up being 0.0, which with the other values in the shadow calculation basically ends up with a result of 'yes, there is a shadow'. The shadow intensity level has more of an impact in the shadow calculations than the softness value does.

Szark

Sorry I misunderstood when you said "So, I was not quite right, yes they are ‘connected’ internally, but not the same as the other lights do them"

JonnyRay

I'm looking at the DzPointLight code in shader builder. A couple of interesting things to note there...

1. When using Deep Shadow Maps, the Shadow Softness parameter is multiplied by 0.023094014 when it is passed into the Renderman built-in shadow function. I don't know why one would do this. I can't find another good source at the moment, for a sample point light shader to compare it to.

2. There is one improvement over earlier versions of the Point Light shader in DS. It used to be that a single deep shadow map was used for the entire globe of illumination. In this latest iteration, it assumes there are 6 maps (top, bottom, left, right, front, back). This should improve fidelity when using DSM shadows on point lights.

Szark

JonnyRay I only use Ray Traced Shadows, never DSM's so please excuse my ignorance when I say how does this effect Ray Traced shadows?

JonnyRay

Szark said:

JonnyRay I only use Ray Traced Shadows, never DSM's so please excuse my ignorance when I say how does this effect Ray Traced shadows?

That is the interesting thing. If you're using ray traced shadows, the DzPointLight code that is included in 4.6 (which is located at C:\Users\\AppData\Roaming\DAZ 3D\Studio4\ShaderBuilder\Shaders\Src\Light) doesn't seem to have the code problem that mjc is pointing out. It simply passes the ShadowSoftness to the built-in 3Delight shadow() function.

mjc1016

JonnyRay said:

I'm looking at the DzPointLight code in shader builder. A couple of interesting things to note there...

1. When using Deep Shadow Maps, the Shadow Softness parameter is multiplied by 0.023094014 when it is passed into the Renderman built-in shadow function. I don't know why one would do this. I can't find another good source at the moment, for a sample point light shader to compare it to.

2. There is one improvement over earlier versions of the Point Light shader in DS. It used to be that a single deep shadow map was used for the entire globe of illumination. In this latest iteration, it assumes there are 6 maps (top, bottom, left, right, front, back). This should improve fidelity when using DSM shadows on point lights.

Actually that factor is in the other's too (dzSpot) and on both DSM and RT.

There is a bunch of very simple point lights floating around that don't do shadows...but I haven't found another one that does, that didn't come from ShaderMixer...

Takeo.Kensei

[Edit] I must be tired or have bad eyes. The parameter is connected to blur input in shadow brick

So it influences the bluriness of the shadow

JonnyRay

To try to make the shadow code it a bit more readable...

...
if ShadowStrength is greater than zero and a shadow map has been generated...
   if the ShadowMap type is "raytrace"
      Get the ray depth information and decide if we should use it to cast a shadow or not
      call the Renderman shadow() function, passing in
         "raytrace" as the 'shadow map', 
         surface point being illuminated, 
         number of shadow samples, 
         shadow width (in both 's' and 't' dimensions), 
         blur (softness) setting
   otherwise, use Deep Shadow Maps
      At this point it does some calculations to see where the light is in relation to world center.
      This is to optimize the speed as it focuses primarily on casting light toward the part of the scene 
         where it is most likely to find other objects */
      In general, the next set of if..then..else statements do the following
      
      Determine if the light is more to the left/right, up/down, or front/back from the world center
         choose the best shadow map based on whether it is more right or left, up or down, front or back from world center
            call the built-in shadow() function passing in
               the selected shadow map, 
               surface point being illuminated,
               number of samples, 
               shadow width (in both 's' and 't' dimensions), 
               blur x 0.023094014, 
               bias x 5

Calculate the resulting light color as the Light Intensity times the Light Color 
   divided by length of the light vector 
      raised to the power of 1/2 of the Falloff 
         times 1 minus the shadow calculation times the Shadow Strength

Keep in mind that the code for a light shader is actually called from the surface of the objects in the scene. So all of this is done from the viewpoint of a point on the surface of one of your objects.

Reading this code, blur should work for raytraced shadows. It is passed directly from the user parameters in to the built-in shadow() function.

Additional information from Pixar on the shadow() funtion may be helpful...

blur (raytrace) - controls the ray traced shadow blurriness. Units are radians, describing the half-angle of the sample cone. The effect is similar to sampling a spherical light source of finite size. You should almost always increase the number of samples as the blur cone increases to reduce noise.This is likely why the original dzPointLight code didn't connect blur. The meaning is completely different from when using Shadow Maps...

blur (shadow map) - Specifies an additional area to be added to the texture area filtered in both the s and t directions, expressed in units of texture coordinates. A value of 1.0 would request that the entire texture file be blurred into the result. A value of 0.001 would request that one extra texture pixel be added in the case of a one-thousand by one-thousand texture file.

This is likely why the blur value is being multiplied by 0.023094014. We don't need the whole texture, just a piece of it.
Also, since blur can either mean "half-angle of the light cone - in radians" in the raytraced version or "percentage of the texture map to use in the filtering", the units aren't necessarily consistent either.

Also, note the comment in the raytrace version of shadow() about samples. If we're dealing with a point light which casts shadows in a full globe, the number of shadow samples is going to be critical to the accuracy.

width - This value multiplies the width of the area being filtered over both the s and t directions. A value of 0 effectively turns off texture anti-aliasing. The default value is 1.0.So this is a way to increase the filtering area for shadow samples.

mjc1016

JonnyRay said:

To try to make the shadow code it a bit more readable...

...
if ShadowStrength is greater than zero and a shadow map has been generated...
   if the ShadowMap type is "raytrace"
      Get the ray depth information and decide if we should use it to cast a shadow or not
      call the Renderman shadow() function, passing in
         "raytrace" as the 'shadow map', 
         surface point being illuminated, 
         number of shadow samples, 
         shadow width (in both 's' and 't' dimensions), 
         blur (softness) setting
   otherwise, use Deep Shadow Maps
      At this point it does some calculations to see where the light is in relation to world center.
      This is to optimize the speed as it focuses primarily on casting light toward the part of the scene 
         where it is most likely to find other objects */
      In general, the next set of if..then..else statements do the following
      
      Determine if the light is more to the left/right, up/down, or front/back from the world center
         choose the best shadow map based on whether it is more right or left, up or down, front or back from world center
            call the built-in shadow() function passing in
               the selected shadow map, 
               surface point being illuminated,
               number of samples, 
               shadow width (in both 's' and 't' dimensions), 
               blur x 0.023094014, 
               bias x 5

Calculate the resulting light color as the Light Intensity times the Light Color 
   divided by length of the light vector 
      raised to the power of 1/2 of the Falloff 
         times 1 minus the shadow calculation times the Shadow Strength

Keep in mind that the code for a light shader is actually called from the surface of the objects in the scene. So all of this is done from the viewpoint of a point on the surface of one of your objects.

Reading this code, blur should work for raytraced shadows. It is passed directly from the user parameters in to the built-in shadow() function.

Additional information from Pixar on the shadow() funtion may be helpful...

blur (raytrace) - controls the ray traced shadow blurriness. Units are radians, describing the half-angle of the sample cone. The effect is similar to sampling a spherical light source of finite size. You should almost always increase the number of samples as the blur cone increases to reduce noise.This is likely why the original dzPointLight code didn't connect blur. The meaning is completely different from when using Shadow Maps...

blur (shadow map) - Specifies an additional area to be added to the texture area filtered in both the s and t directions, expressed in units of texture coordinates. A value of 1.0 would request that the entire texture file be blurred into the result. A value of 0.001 would request that one extra texture pixel be added in the case of a one-thousand by one-thousand texture file.

This is likely why the blur value is being multiplied by 0.023094014. We don't need the whole texture, just a piece of it.
Also, since blur can either mean "half-angle of the light cone - in radians" in the raytraced version or "percentage of the texture map to use in the filtering", the units aren't necessarily consistent either.

Also, note the comment in the raytrace version of shadow() about samples. If we're dealing with a point light which casts shadows in a full globe, the number of shadow samples is going to be critical to the accuracy.

width - This value multiplies the width of the area being filtered over both the s and t directions. A value of 0 effectively turns off texture anti-aliasing. The default value is 1.0.

So this is a way to increase the filtering area for shadow samples.

Right...

The problem is, no matter what, the actual area that ends up 'blurred', even if forcing large numbers, is barely inside the edge of the shadow as to not make much difference to the shadow itself. In other words, no matter what you plug in, the math done is not going to result in a very 'soft' shadow.

JonnyRay

mjc1016 said:

Right...

The problem is, no matter what, the actual area that ends up 'blurred', even if forcing large numbers, is barely inside the edge of the shadow as to not make much difference to the shadow itself. In other words, no matter what you plug in, the math done is not going to result in a very 'soft' shadow.

Might try turning on the Hidden Parameters and playing with the "Shadow Width" to see if it makes a difference.

But I'm wondering if the problem is two-fold. First, DzPointLights don't have a lot of range when casting light. Which means if they are casting shadows they have to be pretty close to the object. Which causes issues for soft shadows for many lights.

Second, as you're suspecting, I wonder if something in the 3Delight engine is just "off" when it comes to the math for soft shadows, raytraced lights, and point light sources.

I'll play some tonight and see if I can come up with anything. But it may end up that the best option is just AoA's Advanced Spotlight (in "point light" mode).

mjc1016

JonnyRay said:

mjc1016 said:

Right...

The problem is, no matter what, the actual area that ends up 'blurred', even if forcing large numbers, is barely inside the edge of the shadow as to not make much difference to the shadow itself. In other words, no matter what you plug in, the math done is not going to result in a very 'soft' shadow.

Might try turning on the Hidden Parameters and playing with the "Shadow Width" to see if it makes a difference.

But I'm wondering if the problem is two-fold. First, DzPointLights don't have a lot of range when casting light. Which means if they are casting shadows they have to be pretty close to the object. Which causes issues for soft shadows for many lights.

Second, as you're suspecting, I wonder if something in the 3Delight engine is just "off" when it comes to the math for soft shadows, raytraced lights, and point light sources.

I'll play some tonight and see if I can come up with anything. But it may end up that the best option is just AoA's Advanced Spotlight (in "point light" mode).

Not off so much as there is an actual difference between a point and an 'infinite' light...like a distant light...and it has to do with whether the rays are considered parallel or not. The way 3DL calculates it will never give very 'soft' shadows on a point light...and in a way, the current behavior is more 'correct'. But since true point light sources don't really exist, it's hard to say...but the best I can come up with are the shadows cast by those tiny surface mount super bright LEDs...they stay 'crisp' no matter how far they are away from the object that is casting the shadow.

And like I said, I did get it to the point where there was a difference in appearance, but not enough of one to matter. Zooming in real tight on the edge of the shadow, it was very noticeable...backed out at a 'normal' distance not so much.

Both the AoA and omnifreaker ones use different shadow code than the dzPoint, at least from observing the results.

Szark

Yes I am still here watching, reading and waiting for my head to explode.

I went back to Uber and now I am testing out AoA's lights.

You both say it is a small light, but aren't all point lights small. I am not being funny I just don't see what the differences are....is there something in the code that makes them smaller. Or as mjc points out Uber and AoA lights use different shadow calculations which is the real difference and not size.

mjc1016

See this post by Dimension Theory...

http://www.daz3d.com/forums/discussion/27675/P1215/#564974

Szark

Cheers mjc..."non large scale" I take it you are referring to...I still don't understand. Do you have some links to some required reading so I can get my head around this please. If not no problem.

mjc1016

Szark said:

Cheers mjc..."non large scale" I take it you are referring to...I still don't understand. Do you have some links to some required reading so I can get my head around this please. If not no problem.

That and the fact that it looks like they are 'faking' a point light with a 360 degree spot to get soft shadows, as opposed to using a 'real' point light.

Szark

Arr yes I see the logic now if AoA needed to do that to get soft shadows from a point like light behaviour.