Hello George, the way the shadows are calculated as I understand it is like this: The scene gets rendered twice: the first time from the perspective of the light source only to generate the depth buffer you are talking about. In the second render step the actual scene is rendered from the cameras perspective. The shaders are using the depth buffer from the first render step to generate the shadow. If your objects are moving outside the field of view of the first render step you will see the boundary of this render buffer in the shadow. You can easily make this visible by looking at your sample composition with your "incorrect" scene, stopping the sphere and changing the x/y/z position of the light. Then this shadow boundary moves around and reveals the field of view from the light source. The real problem with this shadow approach is that the first render step has to use a finite field of view and therefor has those boundaries.
In your sample composition you are moving the objects and light source with the 3D Transform to another location which causes this first render step-render buffer to be different. If you are moving the sphere in the "correct" scene for a grater distance (e.g. put in "2" in the wave generator for the Z axis) the boundary gets visible again. Was this description understandable (and correct)? best, Achim Breidenbach Boinx Software Ltd. On 07.07.2012, at 02:19, George Toledo wrote: > <Shadow Test.qtz> > > I have a nagging feeling I've "sort of" realized this before and used this to > workaround a problem quickly, but I just put together a test to reconfirm how > to workaround this / the nature of the bug. > > The shadow function (shader?) on a Lighting Environment macro ignores the > internal GL matrix transforms, and seems to assume that all objects are at > 0,0,0. This will result in odd lopped off shadows. It also seems to cause the > shadow polygon offset to be computed incorrectly. (Pics attached.) > > > <incorrect.jpg> > > When an object seems to be kept in a -1 to 1 range (?), the shadows seem to > basically be computed correctly. Then, if the "Lighting" Environment is > placed in a 3D Transform, it can be moved freely, and the shadow texture is > correctly applied. This isn't a practical approach for many things, but is > for a handful of cases. > > <correct.jpg> > > > > I may be totally wrong about my "guessing" about this roughly -1~1 translate > limit on the actual "shape" renderer (eg., sprite, sphere, cube, etc.), as I > haven't done much testing recently besides with the sphere in SL for around > five minutes. It's hard to see how a that could be happening if the shadow is > calculated from depth buffer (but maybe it isn't). > > Best regards, > George Toledo > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Quartzcomposer-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/quartzcomposer-dev/achim%40boinx.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
