I'm certainly curious about it how it could be remedied. It seems like it needs to be lopped out and re-implemented entirely. It seems like the approach is probably inherently flawed given the results. Either this, or very specific usage instruction and documentation about when it can be expected to act normally needs to be available. That would help things seem to be more intentional and not seen so haphazard. I give major benefit of the doubt, as far as not expecting every usage scenario to always be possible with a patch like this.
Academic discourse follows, regarding "how it could be remedied" :)
Well, I probably wrote you a million "gosh, wouldn't is be awesome to have shadows in QC" emails from when I would go over to friends houses and watch them use Playstation/X-Box/Wii and see all of the shadowing and be kind of indignant that this wasn't possible in Quartz Composer. In that regard, I'm thrilled that it simply exists, and that Apple incorporated it into QC4, even if it doesn't work 100% as expected.
The most difficult thing to understand about shadows for people is that doing them in OpenGL is actually extraordinarily difficult. As in, people have been researching the topic for _decades_ and _still_ haven't got a 100% sure-fire way to do it quickly. Raytracers, of course, get shadows for "free", but that's not how OpenGL works at all.
When you see shadows in a video game, they're typically simple blobs (older games, N64-era stuff, for example) under characters, shadow projection (Banjo-Tooie used this, as did a number of Gamecube titles), shadow maps (used all over the place), or Shadow volumes (John Carmack used these in Doom 3). These all have issues, but are reasonably fast: * blobs -- not even pretending to be accurate, can "fall" through objects depending on implementation * shadow projection -- accurate, but requires expensive projection work when casting shadows onto non-planar surfaces (to the point where accurate projection code takes far too long to be useful in fully generic situations that QC presents) * shadow maps -- suffer severe pixelation artifacts, and sometimes self-shadowing if the offset isn't tuned. And they play hell with shaders (since the shader needs to compensate for the shadow map) -- this lead to no less than 812,943,182 different variations, including dual-paraboid shadow mapping, trapazoidal shadow maps, and subdivided shadow maps. These in turn also all have weaknesses and strengths. * shadow volumes -- these get ridiculously expensive as scene geometry complexity increases, and start burning fillrate (there are optimizations to help, but I'm not sure how much those scale)
There are perhaps a few other methods (Quake used a combination of pre- calculated baked shadows, along with some blobbing I think, for example), not all hybrids, but all variations on this theme.
-- [ christopher wright ] [email protected] http://kineme.net/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
