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?
Why are the shadows on a grid different than on a box?
4733 5 0- RodrigoSalazar
- Member
- 8 posts
- Joined: Sept. 2016
- Offline
- RodrigoSalazar
- 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.
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
- mzigaib
- Member
- 948 posts
- Joined: April 2008
- Offline
- RodrigoSalazar
- 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.
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
- mzigaib
- Member
- 948 posts
- Joined: April 2008
- Offline
- mark
- Staff
- 2591 posts
- Joined: July 2005
- Offline
RodrigoSalazarThe 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.
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.
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