Hi Vade, Number of good questions here. Thanks. I've posted answers to these below... and in the meantime also solved the problem.
Solution was: I found that my error had been in the cube drawing class code that I'd found someplace. It was setting GL_CULL_FACE and GL_DEPTH_TEST, both of which I found had to be disabled for the painting into the FBO to succeed. In case it's useful to others, I've posted up the complete code. http://dl.dropbox.com/u/421935/Example%20Code/RotatingCube.zip Quick explanation: 1) There's a DisplayLink class. This wraps up the DisplayLink / start / stop, and provides a singleton. 2) A VisualContext class. I attach a movie to this, and this class can register with the DisplayLink class to receive callbacks. It then stores a CGImageRef of the last image from QT - calling QTVisualContextTask every time an image is requested. The VC class can produce texture or pixel buffer data. 3) Then I've a reaaaal simple Texture class that wraps texture IDs. 4) And a QCRenderChain class, whose job it is to setup the FBO within the shared context, and do the rendering to the target texture specified by class (3). It also lets you pull frames from a previous render chain and use these as the source for a new render chain. Each chain can have multiple compositions, the output of the last feeding into the input of the next, and so on. In the example, the chains just use one composition. The example code does show using the output of one chain to feed the next (Reflections, in this case). Vade, Thanks for the help - it was encouraging to know I wasn't going mad and that it should all work as I thought! -- Answers -- 1) Depth buffer. Nope, just one attached texture. I'm rending images through filters and masks, no rotations, only scaling and translation in XY. 2) The patch does have a clear in it, but disabled. The rendering pipeline performs a glClear(0,0,0,0) on it's first call. 3) Yes, I'm using the texture variant of VC's - although both seem to work fine (I tried both, not caring for performance, to see if in fact there was any difference). 4) Regarding the output of a QCImage - this is the intent later on (and I have code that does this) - bur for now I'm doing the simple variant. One movie. One quad. (I'll then do 2/3/4 movies just to confirm my code works with multiple). 5) Regarding chaining - I didn't realize that using a QCImage output would mean I could get away with no billboard. That sounds useful. I could then have one last "Billboard" patch to render a QCImage into a texture (the last patch in the chain). I'll investigate that further, thanks. Neil On 8/02/2010, at 6:18 PM, vade wrote: > A few questions, > > are you flushing properly after rendering the FBO? Does your QCRenderer have > a clear in it, if not, are you calling glClear() before you render your > QCRenderers? > > Does your FBO have a depth buffer attachment? Otherwise anything rendering > geometry may look weird or have depth artifacts. > > You mention the QT movie shares the GL context, Are you using a > QTOpenGLTextureContext with your movie? Are you properly calling > QTVisualContextTask after each frame? > > If you suspect the QT movie to be messing with your context, you can isolate > each component (QC Renderer, QTMovie) to their own GL context shared with the > master context that is driving your view. Sharing the context will allow your > FBOs texture attachments, and textures from the QTmovie to all be rendered > and mixed accordingly to the main view (or have the CVOpenGLTextureRefs from > your visual context passed as input keys to your QC Renderers). You can do > this as many times as needed, you are not limited to 2 shared contexts, you > can do master shared to many "sub" contexts, or have a "serial" approach > where its master -> shared a -> shared b. I've seen little difference between > these approaches. > >> I've observed via OpenGL Profiler that the renderers are being called, and >> producing frames. The frames I really want to see painted on my textures >> seem to be being created as their own textures (maybe QCRenderer does this >> internally, I don't know), and not drawn into the FBO. > > You may be seeing the texture that is painted onto the billboard here in the > GL profiler. If you are looking to pass the output of one QC Renderer to > another, it will be faster to publish output images and use the QCImage type, > and then set that as an input image value in the next QCRenderer. This will > save you a draw call on the billboard, as well as a render to texture phase > with your FBO, and whatever internal swizzling QC does with textures -> > QCImage conversions. This of course is moot if your QCRenderer draws lots of > geometry and you want to capture that. > > Describe your rendering pipeline? > > On Feb 7, 2010, at 8:27 PM, Neil Clayton wrote: > >> Hi All, >> >> I'm having some problems rendering using multiple FBOs. >> >> I have texture, to which I want to draw to using an FBO. I've verified the >> texture is bound to the FBO correctly by drawing basic geometry >> (lines/polys) before I do the QCRenderer render. 80% of the time, these >> geometry operations are not overwritten with the contents of the render. >> The other 20%, I sometimes see a first frame being rendered to the texture >> and then garbage afterwards. It's as if QCRenderer isn't drawing into the >> currently bound FBO at all, or it is, and subsequent renders are stuffing up >> the FBO state (I'm careful to restore previous FBO state, afaik). >> >> I've observed via OpenGL Profiler that the renderers are being called, and >> producing frames. The frames I really want to see painted on my textures >> seem to be being created as their own textures (maybe QCRenderer does this >> internally, I don't know), and not drawn into the FBO. >> >> Is it the case that if I setup and FBO using a shared OpenGL context, and >> render a QC composition via QCRenderer, that it should render-to-texture if >> that is how the FBO is setup? >> >> One thing to note is that the QCRenderer, view and QTMovie all share the >> same context. The corruption happens while the movie is playing. I wonder >> if it's to do with locking between these components? (since the visual >> context will be rendering frames at the same time). I perform a >> CGLContextObj cglContext = (CGLContextObj)[context CGLContextObj]; within >> both my view and the QCRenderer... >> >> I've put a sample movie here: >> http://dl.dropbox.com/u/421935/RotatingCubeExample.mov >> >> >> Any ideas regarding QCRenderer and FBO's, with subsequently mapping the >> underlying textures to a quad? >> >> >> Neil Clayton >> [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/doktorp%40mac.com >> >> This email sent to [email protected] > Neil Clayton [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]
