Interesting. I am not using any GLSL magic within the plugin (its all
fixed function pipeline and only bounces between buffers for temporary
render to texture stuff), so unless QC is doing something behind my
back when binding images that use shaders, I should not have to re-
bind the uniforms, as I understand it.
I spoke to some other "GL wizards" earlier about this exact issue and
they said that if I unbind a shader, the uniforms that are already
bound/set to it do not need to be reset/resubmitted when I re-bind,
thus why i am not doing that. It follows the state laws of OpenGL no?
So you are saying I have to ask every frame what the uniforms are,
'download' all of them, unbind the shader, blah blah, rebind, resubmit
all the uniforms and then render?
Ugh. That may explain why my output is 'nothing' since no texture is
bound its output gl_FragColor 0., 0., 0., 0.
Ugh x2
On Jun 19, 2009, at 6:40 PM, Christopher Wright wrote:
I wondering what special state management or 'no nos' to avoid when
attempting to make a custom consumer patch compatible with to be
rendered within the GLSL macro patch?
What I have as a partial working solution is to check for the
GL_ACTIVE_PROGRAM in startExecution and store that as an ivar, and
re-bind it before rendering out the final geometry. This seems to
work, however I have some odd behavior: If I create a GLSL shader
that uses a sampler and connect an image input to that sampler
input port, I do not render anything at all (not black, literally
no output at all). I attempted disabling texturing within my plugin
but the behavior remains. Anytime a sampler is made active (fed an
image), my rendering stops. Considering that the internals of the
GLSL Shader macro are black box, im not sure what to do?
sounds like you need to preserve all the uniforms. That means you
have to ask the current program what they are, store them off,
activate your GLSL program (which wipes out the old ones), do your
thing, revert to the old shader, and restore all the uniforms. I'm
not sure if this will solve the problem or not, but it's possible.
you should also check for glError, to see if anything interesting is
happening (that can lead to no-output scenarios -- when a patch
fails to render, all following patches tend to get skipped over,
which is a bit unintuitive.)
If you think it sounds torturous, let me assure you, it is ;)
--
[ 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]
