I realized that I didn't include the location of the sphere, and that it may not be obvious what I'm referring to if someone was to open the qtz. /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuartzComposer.framework/Versions/A/Resources/Sphere.dae
Is it possible that things that are part of the DAE/OpenCL mesh system are being pulled into their own 3d camera environment, OpenCL kernels are being used to calculate the transforms, working space, running the objects through this dof/shadow/glow whatever process, etc., but that when this is being all put "back together", so to speak, that there's no calculation going on to make shadows not texture the backside of things like sprites? If not that, maybe a discrepancy in the math of what a thickness of a sprite is vs. where the shadow is supposed to cut off that is making it bleed through too far? Sorry for the ultra "gloss over humongous amounts of details poke in the dark", but it does it seems like the DAE/Mesh stuff is somehow working in it's own 3D environment from the other objects. It seems like it's set up to ignore FOV/Projection mode, for instance, when Core 3D/CL Mesh stuff is in a macro level, as part of the trade for being able to calculate the shadows... but that it is setup to work with typical matrix transform stuff that's now built into the 3D transform patch. Chris, as long as you're running down culling with lighting... what is it that you're observing the new model option culling to do (not sure if you've looked at it yet)? It doesn't make a difference as far as the the problem qtz goes, but I never saw a really good description of what is happening with model culling in QC. -George Toledo On Tue, Sep 29, 2009 at 8:53 AM, Christopher Wright <[email protected]>wrote: > Sorry - just answering my own post with another observation - in my >> example, I wondered why the outer right hand wall wasn't blue since the blue >> light was nearest to it. >> >> I'm aware that the walls we're looking at are the back faces of the cube >> and I'm using two-sided lighting, but if you imagine the coordinates of the >> lights were inverted, the results would be correct. The blue light would be >> on the left, the green light in the bottom right corner, etc. >> >> Back surfaces don't seem to be lit correctly - I'm inclined to think this >> is close to the issue George is observing? >> > > > Lighting is completely separate from shadows -- shadows require knowledge > of the geometry between the light and the shadowed surface (a very > complicated problem), while Lighting only requires knowledge of the > lightsource and the object being lit (simple). > > (again, I'm not on Snow Leopard at the moment, so I'm flying blind here) > > When a polygon is lit in standard OpenGL lighting, it's per-vertex. This > means the light value is calculated at the corners of the polygon, and > interpolated across the face of the polygon. This is cheap and easy, and > also wrong (if the light's near the center of the face, it doesn't highlight > as it ought to, since the center of the face is interpolated from the > corners, which would be darker). > > With GLSL, it's possible to do per-pixel lighting, which resolves that > issue nicely. However, you have to write your shader yourself to get that > up and running. (there are examples out there that do this for you already) > > Next up, there's 1-sided vs. 2-sided lighting. By default, QC's lighting > is 1-sided. That is, it lights the front side > (normal-points-towards-the-light case), but not the back side. There's a > checkbox in the lighting patch's parameters to enable 2-sided lighting. > This will cause the light to work on the back side > (normal-facing-away-from-the-light case). You may want to experiment with > this setting, to see if it helps. I have a feeling you may be experiencing > a combination of both of these issues (per-vertex instead of per-pixel > lighting, and 1-sided instead of 2-sided). > > Note that when you're culling polygons (face culling), front/back facing is > determined by vertex winding (clockwise/counter-clockwise), not normal > direction(towards/away). This normally doesn't matter to anyone, as normals > aren't exposed much in QC, but if you're writing your own GL code for a > plugin you may want to keep that in mind. > > > -- > [ 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/gtoledo3%40gmail.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: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
