Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TexturesAndFbos: Changes and Notes #2

simongeilfus opened this Issue Jul 13, 2016 · 2 comments


None yet
3 participants
Copy link

simongeilfus commented Jul 13, 2016

Changes / Additions

  • gl::TextureBase::Format::setSamples
  • gl::TextureBase::Format::getSamples
  • gl::Texture2d::Format::samples
  • gl::Texture3d::Format::samples
  • gl::Fbo::createEmpty (see cinder#1191)
  • gl::Fbo multisampling support for texture2dArray (see cinder#1191)
  • gl::Fbo::Format::depthTexture doesn't support GL_DEPTH_STENCIL format (see cinder#1501)
  • gl::Fbo better support for textureCubemap (see cinder#1320 and
  • gl::Fbo better support for texture3d and texture2dArray (see cinder#1191)
  • gl::Fbo::attach
  • gl::Fbo::attach multisampling support
  • gl::Fbo::Format option to switch to texture based multisampling
  • static gl::Fbo::checkStatus
  • Fix for "gl::Fbo default depth-stencil renderbuffer is created twice on desktop" (see cinder#1503)
  • gl::framebufferRenderbuffer
  • gl::framebufferTexture
  • gl::frameBufferTextureLayer
  • gl::drawBuffers( const std::vector<GLenum> &bufs );
  • gl::getMaxSamples
  • gl::getMaxColorTextureSamples
  • gl::getMaxDepthTextureSamples
  • gl::Environment::supportsTextureMultisample
  • gl::Environment::supportsTextureStorageMultisample
  • Tests on Linux, MacOS, iOS and GL ES 3 !!!
  • EmptyFbo
  • Separate texture multisample tests from EmptyFbo
  • Layered Rendering

Related pull requests


  • Could deprecate gl::Fbo::getMaxSamples() to gl::getMaxSamples() as it's not onle related to Fbos (found only two breaking changes in Fbo.cpp#L81, nothing in samples)
  • maximum number of samples of a texture is not GL_MAX_SAMPLES but GL_MAX_COLOR_TEXTURE_SAMPLES and GL_MAX_DEPTH_TEXTURE_SAMPLES ... No idea if those might return different values on other gpus.
  • made gl::Fbo::checkStatus() static
  • should we have both ScopedDrawBuffers and ScopedDrawBuffer or one class is enough for both glDrawBuffer and glDrawBuffers?

Textures Multisample support :

Function Target Desktop ES Cinder Proposed Feature Name

@simongeilfus simongeilfus changed the title Changes and Notes TexturesAndFbos: Changes and Notes Dec 22, 2016


This comment has been minimized.

Copy link

thyrrestrup commented Jan 9, 2018

It would be a very welcome update to get at least some of these changes merged into Cinder.
Nice work!


This comment has been minimized.

Copy link

totalgee commented Apr 12, 2018

Thanks, it's great Fbo is getting some love. (-;

Not sure this is useful "generally", but for my purposes it would have been useful to have:

  • ability to bind the resolved part of a multisampled Fbo, using the Cinder Fbo API. Normally, when you bindFramebuffer() (it seems to assume you're binding in order to draw to it, even if you pass the READ target), it binds the multisampled framebuffer (which is what getId() returns if the Fbo has multisampling). Luckily, the method getResolveId() existed, so I could do what I needed directly with raw OGL calls (as long as I was careful to restore Cinder's framebuffer binding state after changing it under the covers).

  • related to the above: When you call bindFramebuffer() with the GL_READ_FRAMEBUFFER target, it perhaps shouldn't call markAsDirty() (ref), since you're only going to be using it as a source.

BTW, above, when I say "what I needed," I mean: the ability to blit the resolved part of a multisampled Fbo to a different (non-multisampled) Fbo. In my case, I was doing that using an OpenGL extension blit function (glMulticastBlitFramebufferNV()) to transfer it between GPUs.

In my case, I'm not using any extra (color) attachments, so I didn't need to change read/draw buffers for the Fbo blit stuff I was doing (using glDrawBuffers() or glReadBuffer()). However, it might be necessary in some cases, if you had multiple attachments. Is it possible to get/enumerate the attachments (mAttachments* entries) once you've created an Fbo? Doesn't seem to be. (NOTE: This is not important for me in this case, mainly just a curiosity...don't worry about it!)

I'm not sure any of this warrants complicating Fbo -- e.g. for different bind cases for READ vs DRAW -- but just thought I'd add my comments here in case they are useful or spark any thoughts. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.