Glad to hear that, hopefully things are starting to make more sense now.
On 09/03/2018 02:54 PM, Andy wrote:
> Progress! Here's my current framegraph:
>
> RenderSurfaceSelector:
> Viewport:
> ClearBuffers:
> buffers: ColorDepthBuffer
> clearColor: "#EEfaebd7"
> NoDraw: {}
> FrustumCulling:
> # OnScreen
> CameraSelector:
> objectName: onScreenCameraSelector
> RenderCapture:
> objectName: onScreenCapture
> # OffScreen
> CameraSelector:
> objectName: offScreenCameraSelector
> RenderTargetSelector:
> target:
> RenderTarget:
> attachments:
> - RenderTargetOutput:
> attachmentPoint: Color0
> texture:
> Texture2D:
> width: 512
> height: 512
> format: RGBAFormat
> ClearBuffers:
> buffers: ColorDepthBuffer
> clearColor: "#EEfaebd7"
> NoDraw: {}
> RenderCapture:
> objectName: offScreenCapture
>
> Results of the render captures:
>
> onScreenCapture: https://postimg.cc/image/v26nfj36l/
> offScreenCapture: https://postimg.cc/image/68x3evrvx/
>
> I fixed the offscreen aspect ratio issue by creating a new offscreen
> camera and forwarding all but these two signals:
>
> Qt3DRender::QCamera::aspectRatioChanged
> Qt3DRender::QCamera::projectionMatrixChanged
>
> Question:
>
> 1) I am using an RGBAFormat for my texture. I changed the alpha in
> the clear colour from 0x80 to 0xEE and I now see an alpha cleared
> background in the offscreen (see image). I can just use RGB for my
> purposes right now, but I'm curious why the onscreen clearing is not
> using the alpha channel? I can confirm this by changing the clear
> colour to #FF000000 - I just get solid black.
Well I believe that this depends on the format of your back buffer
(usually it is RGB). You can try to query it with
QSurfaceFormat::defaultFormat() and looking for the alphaBuffer size (or
apitrace also gives you the format when you select a draw call that
renders to screen).
>
> Problem:
>
> 1) The resulting scene isn't the same in the offscreen capture:
> - the yellow cube is on top of everything
> - the red & blue arrows aren't clipped by the plane
I suspect that this is caused by the fact that you have no depth
attachment on your RenderTarget so that depth testing isn't performed
properly. You would need to create another RenderTargetOutput that you
bind to the attachment point Depth with a suitable Texture2D texture
with format (D32, D24 ...).
> - it isn't antialiased
That's likely caused by a) not having a high resolution enough for your
attachments b) using a Texture2D instead of a Texture2DMultisample
(though I'm not sure RenderCapture would work with the latter).
Have you tried going for a 2048/2408 texture instead of 512/512 assuming
you have no memory constraints? Then you can always scale back the
QImage you capture to 512/512 if need be.
>
> I'm wondering if this is because the shaders aren't being used for the
> offscreen texture? I noticed in apitrace that when switching
> GL_DRAW_FRAMEBUFFER to 0 (onscreen), glUseProgram(1) is called. This
> is not called when switching GL_DRAW_FRAMEBUFFER to 1 (offscreen). Is
> the program supposed to persist or does it need to be called again
> when switching framebuffers?
Programs aren't tied to FrameBuffers, you just call glUseProgram when
you want to switch program and/or when you didn't track what was the
previously used program was.
>
> (apitrace is super-cool. Thanks for the pointer.)
There are also vogl and renderdoc but I tend to always go back to
apitrace :)
>
> Thank you for your time & help!
>
> ---
> Andy Maloney // https://asmaloney.com
> twitter ~ @asmaloney <https://twitter.com/asmaloney>
--
Paul Lemire | paul.lem...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel: France +33 (0)4 90 84 08 53, http://www.kdab.fr
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
