Hey there,
sorry for the imprecise title, I couldn’t find a more appropriate one.
I often find myself in nesting different classes which each have their own draw() function. For easier explanation let’s take a simple UI as an example:
MyApp
-- Scenes
-- Layers
-- Elements
Each is a vector of classes and inherits some kind of interface that defines virtual methods for update() and draw().
I tend to call gl methods directly in each draw() method, often nested in push- & popMatrices(). Somehow this doesn’t feel right, but I am uncertain about this. A practical difficulty I sometimes encounter is the use of glScissor which needs absolute positioning.
I was wondering if it would be a better approach to let each class draw in its own FBO and just return the reference to it, so that the concurring parent can take care of drawing and positioning it. A nice side effect would also be the omitted need for glScissor. On the other hand I can’t really estimate the impact on VMemory usage and performance in general when it comes to drawing a lot of these. I know this is a somewhat blurry question, but I’d love to hear some opinions or different approaches on this topic.
Thanks in advance,
Daniel
Hi,
having a separate Fbo for each element is quite costly in terms of memory and performance. But they’re indeed an easy way to control the area drawn to, where scissoring is messy and awkward to use.
It might be better to be smart about what needs to be drawn to an Fbo and what can be drawn directly. For instance, you could have an element that binds an Fbo and then let its children draw themselves directly. Those elements would not care about whether or not they’re drawing to an Fbo. When the last child has drawn itself, unbind the Fbo.
Another trick you might use it to keep a pool of Fbo's around, so you can reuse them over and over, even for multiple elements during a single frame.
-Paul
If your elements are mostly static and don’t change frame-to-frame then rendering to an Fbo might be a win. I do this selectively for complex elements like SVG icons that would waste vertex upload / processing time otherwise.
If your scene is really dynamic (lots of change between frames) then Fbos would probably just introduce more rendering and memory usage.
Also remember you can also use gl::viewport() instead of glScissor() if you want to draw locally to a specific region of the framebuffer.
Hej,
thank you very much for the insights. I kinda like the idea having just a couple of FBOs for larger objects – like in: canvases, containers or whatever an appropriate terminology would be – and adjusting the viewport beforehand. To be honest I never thought of that. There are still some broad knowledge gaps I yet have to fill in when working with Cinder or OpenGL in particular