Thanks a lot, ill look into this. I draw the same way, just using
drawElements. Im not enough of a GL 3D guru to know if there is a huge
difference perf wise. If I want to draw with glDrawArrays, can I have
a texture array in a VBO that is smaller than the number of verts I
need?
I may be forcing a disable of client state for the vertex/texture and
normal array which may be the issue when re-drawing. Hrm. Fucking
OpenGL!
I wish there was a global
glPushALLFUCKINGSTATETHINGSSOICANLEAVETHEENGINEHOWITWASWHENIPOP()
and a glPopALLFUCKINGSTATENOWGODDAMNIT.
Thanks, you are helpful as always, Ill see what I come up with.
On Sep 14, 2009, at 12:08 PM, Christopher Wright wrote:
I am working on polishing up a custom consumer rendering patch for
10.6 compatibility, and have finally gotten around to adding what
appears to be proper normals for lighting. In experimenting with
the new 10.6 lighting patch I've noticed that the shadow option ...
"does weird stuff" to my consumer rendering, so I'm assuming I'm
not restoring state or drawing in a way that it expects, because
things just break with it. Im not able to get new textures on to my
vertices, I see no shadows, but my geometry continues to update. Im
using the standard QCPluginImageProvider methods to lock buffer
representation/bind to context etc.
Shadows work with Kineme3D, so I'll describe what we provide/use, so
you can double-check.
We store VBOs of vertices, normals, and texture coordinates. (with
3, 3, and 2 elements, respectively).
We draw using glDrawArrays (because some mesh formats provide more
than 1 normal per vertex, which glDrawElements can't deal with).
We set/clear some vertex array state:
glEnableClientState( GL_VERTEX_ARRAY );
glEnableClientState( GL_TEXTURE_COORD_ARRAY );
glEnableClientState( GL_NORMAL_ARRAY );
(this is probably an unclean thing to do -- we should be preserving
whatever the previous state is, instead of assuming it's disabled)
How do shadows work internally, and how does one make sure (using
the public API) that shadows can/will work with custom Consumers
rendered in non immediate mode (VBO via glDrawElements)? Is there
some key state that needs to be maintained before/after execute at
time? As far as I am aware I am playing it safe with my state
saving/restoration code.
Shadows appear to work by rendering all the geometry multiple times,
once with its normal texture, and once with a "shadow" texture, in a
custom GLSL shader. The shadow texture is generated presumably from
a depth map (or a few depth maps composited together, based on some
light-position jitter -- quality controls the number of samples to
take, where each sample requires a complete render), and I believe
they use a custom GLSL shader (to map screen-space pixels to
shadowmap space pixels). You can see artifacts of this when you
deform geometry with the GLSL shader -- your deformed (unshadowed)
mesh will render as expected, but the shadow on the deformed mesh
will display where the original grid was. That leads me to believe
that they're using GLSL, since it's per-pixel shadows, and it kills
the vertex shader as well.
(Super Secret Pro Tip: if you strings the QC framework, you can
find the GLSL shadow shader source inside ;)
As for making it work -- I'd check face culling, depth reading/
writing, and I'd almost certainly not use GLSL (as that'll guarantee
shadow breakage). I think that puts you out of luck (since your
Rutt Etra implementation is glsl-driven, if I recall correctly). :/
--
[ 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]
