Hash Fellow robcat2075 Posted March 27 Hash Fellow Share Posted March 27 A forum member has posed this problem... LightSource.prj That is the correct behavior. Only ray-traced lights can accurately account for the shadowing created by boolean cutters. So, with the box as a boolean cutter, the sphere is completely "cut" and casts no shadow from the ray-traced light. The z-buffered light can not handle that complex situation, so even though the box cuts the sphere from the camera's view, the z-buffered light still sees it and a shadow is cast. Interesting way to get a shadow-only pass! I shall remember that! Quote Link to comment Share on other sites More sharing options...
Tom Posted March 28 Share Posted March 28 Thanks for the explanation! Quote Link to comment Share on other sites More sharing options...
Hash Fellow robcat2075 Posted March 29 Author Hash Fellow Share Posted March 29 As I dimly understand it... Z-buffered lighting works by rendering a depth map from the viewpoint of the light. Every pixel of that map is really a number that is the distance from the light to the surface point that pixel lands on. then when the real camera image is being rendered, every pixel is checked to see if the surface point it lands on is farther from the light than that same surface point is in the depth map. If it is farther, then that means some other surface is in front of it from the light's point of view and it must be in shadow and should not get the light's intensity added to it's surface color. Apparently this is usually faster than computing an actual ray form teh camera to the light. So why can't this process accommodate the Boolean cutter? I dont' know, but it doesn't. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.