Why are the shadows on a grid different than on a box?

   4722   5   0
User Avatar
Member
8 posts
Joined: Sept. 2016
Offline
Trying to figure out why Houdini/Mantra shows incorrect looking results for the shadow of 1 object onto a box, but shows correct looking results for shadows onto a ‘grid’.

I have boiled down my problem to a sample scene which reproduces my problem with a little shader ball geometry and a spotlight pointing at it.

For the spot light i'm using the default shadow type: Ray-Traced Shadows, and have my shadow mask set to *.

Does anyone have any idea?
Edited by RodrigoSalazar - Oct. 23, 2016 20:47:07

Attachments:
2016-10-23_15h01_14.png (289.3 KB)
2016-10-23_15h08_02.png (218.6 KB)
2016-10-23_14h56_23.png (245.9 KB)
boxspotlight.hiplc (281.1 KB)

User Avatar
Member
8 posts
Joined: Sept. 2016
Offline
I've been working out these issues with shadowing in my project for a couple weeks now (an hour a day or so)…

I just realized that if I increase the Axis Divisions on my Box geometry from the default 2, to a much larger number that the shadow becomes more and more correct. This explains why the grid received correct shadowing because the default divisions/polycount is very high.

Does anyone know why this happens? Why does the surface not shadow correctly unless it has a high poly count?

Thanks in advance to anyone that can share their expertise on this.
Edited by RodrigoSalazar - Oct. 23, 2016 21:29:14
User Avatar
Member
948 posts
Joined: April 2008
Offline
In the case of the first example if you turn the “add vertex normal” on the box everything works correctly which means that the issue is related to the way the normals are representing the geometry, set the normals correctly and you should have no problems.

I hope that helps.
https://vimeo.com/user2163076 [vimeo.com]
User Avatar
Member
8 posts
Joined: Sept. 2016
Offline
Thanks mzigaib! It's interesting that both solutions here work. I imagine what you suggested is probably the right way to do this.

I guess this means that to correctly render something with lights, all the geometry needs normals (And they are not calculated on the fly by the render if missing). Does this mean that the renderer is allowed to just do whatever it wants if there's no vertex normals? Like undefined behavior?

I wonder why the solution I came up with (increasing the poly count on the box), also seems to work.
Edited by RodrigoSalazar - Oct. 24, 2016 23:27:57
User Avatar
Member
948 posts
Joined: April 2008
Offline
I believe it is because when you add divisions there are more normals to interpolate along the face, in the case of the box with no divisions you just have shared normals on the corners, the ideal is that you don`t have to divide to have correct normals.
https://vimeo.com/user2163076 [vimeo.com]
User Avatar
Staff
2589 posts
Joined: July 2005
Offline
RodrigoSalazar
Thanks mzigaib! It's interesting that both solutions here work. I imagine what you suggested is probably the right way to do this.

I guess this means that to correctly render something with lights, all the geometry needs normals (And they are not calculated on the fly by the render if missing). Does this mean that the renderer is allowed to just do whatever it wants if there's no vertex normals? Like undefined behavior?

I wonder why the solution I came up with (increasing the poly count on the box), also seems to work.
The root of the problem is likely the code to get rid of the shadow terminator. With your box, you have shared vertices on the corners, meaning the normal is interpolated across the surface (approximating a curved surface). If you had vertex normals, or unique points on the box, it would work better.

Or, if you really need shared normals, you can disable the shadow terminator fix by adding the vm_smoothP rendering property.

You can see more on this subject in the H15 release notes (search for Terminator):
https://www.sidefx.com/docs/houdini/news/15/rendering [sidefx.com]
  • Quick Links