...shadow map? -GT On Tue, Sep 29, 2009 at 3:03 AM, George Toledo <[email protected]> wrote:
> FWIW, > > /System/Library/PrivateFrameworks/MeshKit.framework/Versions/A/Frameworks/MeshKitRuntime.framework/Versions/A > > ... has the spot shadow GLSL, and related GLSL...but I'm guessing you know > this (or maybe haven't poked around too much on it yet?) > > What method would you say that this falls into? > > > -George Toledo > > > On Tue, Sep 29, 2009 at 1:36 AM, Christopher Wright <[email protected]>wrote: > >> 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/ >> >> >
_______________________________________________ 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]
