-
After working out a couple of issues I have a QOpenGLWidget with a camera based on the mouse interaction example. The next thing I need to do is object picking, so I've been looking at the example. The example is adding a
Thank you! |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments
-
Do you also get no GL errors? With
You have to do that, I don't think Qt expects additional buffers added to its internal framebuffer, and on resize it could even delete the whole thing and create a new framebuffer object, with a different ID.
I think ApiTrace should still work on Mac? I remember using it there years ago, it's in my regular toolbox on Linux and Windows and it's been invaluable. |
Beta Was this translation helpful? Give feedback.
-
There is a From the Qt docs:
This made it sound (to me) like I could modify the default frame buffer, but maybe I'm confusing my terminology. So if I can't modify the frame buffer I get from Qt, any suggestions for an alternate strategy? Can I create a separate frame buffer and render to it as well, and use it for object picking? Seems kind of wasteful to render twice, but 🤷 Something like: void foo::draw( Magnum::GL::Framebuffer &inQtFrameBuffer )
{
// draw to inQtFrameBuffer
inQtFrameBuffer.clear( Magnum::GL::FramebufferClear::Color | Magnum::GL::FramebufferClear::Depth );
mCamera->draw( mDrawables );
// switch to second framebuffer somehow?
// draw to new framebuffer (with object IDs)
mCamera->draw( mDrawables );
// switch back to inQtFrameBuffer (may not be needed)
} Or is there a way to copy the frame buffer's data so we don't render twice? (I'm clearly taking a stab in the dark here.)
I looked at that and there aren't any builds for it. The devs made a comment in one of the issues that they don't use/support macOS anymore. Thanks again Vladimír! |
Beta Was this translation helpful? Give feedback.
-
Just in case you aren't aware, If you get an invalid operation error then it's probably not a way forward. No idea what exactly could be the cause, but I personally wouldn't bother trying further with this experiment :) The way to go would be to create your own framebuffer, with the Object ID attachment, and then ultimately blit() the color from it to the (wrapped) Qt's framebuffer. That is still one extra operation, but better than having to draw twice. Regarding ApiTrace, I think it's just not maintained there anymore (I suppose because Apple decided to not care about GL, and it's a hostile platform in general), but the support isn't removed. You could try to build it yourself: https://github.com/apitrace/apitrace/blob/master/docs/INSTALL.markdown#mac-os-x |
Beta Was this translation helpful? Give feedback.
-
Got it! That makes sense - use Magnum for everything, then just blit to the Qt widget. I now recreate the Magnum Framebuffer when the widget is resized, then do something like: void foo::draw( Magnum::GL::Framebuffer &inFrameBuffer )
{
startMagnumContext();
mFrameBuffer->clearColor( 0, 0xa5c9ea_rgbf );
mFrameBuffer->clearColor( 1, Magnum::Vector4ui{} );
mFrameBuffer->clearDepth( 1.0f );
mFrameBuffer->bind();
mCamera->draw( mDrawables );
endMagnumContext();
Magnum::GL::AbstractFramebuffer::blit( *mFrameBuffer, inFrameBuffer, mFrameBuffer->viewport(),
Magnum::GL::FramebufferBlit::Color );
} One thing that tripped me up is that QOpenGLWidget has a "device pixel ratio" of 2 (at least on my machine). So I needed to convert "pixel size" to "device size" in a bunch of places. Thanks Vladimír! |
Beta Was this translation helpful? Give feedback.
-
One additional thing, assuming |
Beta Was this translation helpful? Give feedback.
-
Ah yes! Thank you. The learning continues... |
Beta Was this translation helpful? Give feedback.
Just in case you aren't aware,
Debug{} << GL::Renderer::error()
will print the human-readable enum name so you don't have to do manual string conversions or look up numeric values. Works with most Magnum enums.If you get an invalid operation error then it's probably not a way forward. No idea what exactly could be the cause, but I personally wouldn't bother trying further with this experiment :) The way to go would be to create your own framebuffer, with the Object ID attachment, and then ultimately blit() the color from it to the (wrapped) Qt's framebuffer. That is still one extra operation, but better than having to draw twice.
Regarding ApiTrace, I think it's just not maintained there…