View Issue Details

IDProjectCategoryView StatusLast Update
0032077Open CASCADEOCCT:Visualizationpublic2023-08-01 15:09
Reporternds Assigned Tonds  
PrioritynormalSeverityfeature 
Status assignedResolutionopen 
Target VersionUnscheduled 
Summary0032077: Visualization - setting custom default frame buffer object for OpenGl context
DescriptionIt's not possible to use custom frame buffer object for OpenGl_Context to have view result only in this buffer. The request here is that the default ZERO frame buffer should not be changed at all.

An example of using such approach is having several OCCT views in one OpenGl window, placed in own geometry of the window (provided by an inheritance of WNT_Window).

So, it's proposed to be able to change index of NO_FRAMEBUFFER. Now, it equals the ZERO value. If we may change it on some custom value and be sure that in OCCT code anywhere instead of the current ZERO value the custom value is used.
It solves this advanced case.

On attached snapshot we see three views created as QQuickFramebufferObject. Each view sets it's own frame buffer id into V3d_View and calls the view redraw. In this case, the default OpenGl view is not touched, the whole rendering goes only into this frame buffer.
TagsNo tags attached.
Test case number

Attached Files

  • several_views_on_one_openGl.png (23,211 bytes)

Relationships

related to 0031597 closedbugmaster Visualization, TKOpenGl - allow disabling Alpha component writes within OpenGl_Context::ColorMask() 

Activities

nds

2021-01-22 17:05

developer  

several_views_on_one_openGl.png (23,211 bytes)

kgv

2021-01-22 17:17

developer   ~0098340

Last edited: 2021-01-22 17:18

> So, it's proposed to be able to change index of NO_FRAMEBUFFER.
> Now, it equals the ZERO value.
> If we may change it on some custom value and be sure that
> in OCCT code anywhere instead of the current ZERO value
> the custom value is used.
It is unclear what is the real purpose under this hack as NO_FRAMEBUFFER is just a constant following OpenGL specs.

Expected solution for overriding default FBO target (e.g. to prevent rendering into window buffer)
is initializing an offscreen OpenGl_FrameBuffer (which can be a wrapper over QQuickFramebufferObject)
and setting it to OpenGl_Context::SetDefaultFrameBuffer().

nds

2021-01-22 17:35

developer   ~0098342

It wouldn't help because any such call:

theGlCtx->arbFBO->glBindRenderbuffer (GL_RENDERBUFFER, NO_RENDERBUFFER);
would redraw the main OpenGl window.

kgv

2021-01-22 17:41

developer   ~0098343

> theGlCtx->arbFBO->glBindRenderbuffer (GL_RENDERBUFFER, NO_RENDERBUFFER);
NO_RENDERBUFFER is used on creation of FBOs, it is irrelevant to rendering into window buffer.

nds

2021-01-22 17:41

developer   ~0098344

NO_FRAMEBUFFER is not OpenGl constant. It's defined in OpenGl_FrameBuffer.

kgv

2021-01-22 17:49

developer   ~0098345

Last edited: 2021-01-22 17:50

> NO_FRAMEBUFFER is not OpenGl constant.
> It's defined in OpenGl_FrameBuffer.
From OpenGL specs:
> void glBindFramebuffer (GLenum target, GLuint framebuffer);
> ...framebuffer is the name of a framebuffer object previously returned from a call to glGenFramebuffers,
> or zero to break the existing binding of a framebuffer object to target.

So OpenGl_FrameBuffer::NO_FRAMEBUFFER / OpenGl_ShaderProgram::NO_PROGRAM / OpenGl_Texture::NO_TEXTURE are nothing but convenient aliases to ZERO, as OpenGL doesn't define constants for such things.
Most of them are ZEROs in OpenGL specs, but some do not (like OpenGl_ShaderUniformLocation::INVALID_LOCATION which is -1, as 0 value is allowed name).

nds

2021-01-22 17:59

developer   ~0098347

If during the OCCT view redraw the current id in OpenGl is not ZERO. Why OCCT sends something to zero id?
Why it doesn't get the current from the openGl instead of using own NO_FRAMEBUFFER constant which is ZERO?

In application it leads to lot's of drawing in the main Gl context while the current buffer, set outside the redraw of OCCT view is not ZERO.

nds

2021-01-22 18:00

developer   ~0098348

The proposed patch is on CR32077.

nds

2021-01-22 18:17

developer   ~0098351

Oh, using the current id of openGl is not what is expected (as Qt do this by itself).
In the given example, the QQuickFramebufferObject has own buffer id. This id is set into OpenGl as current (by qt) when this quick item is rendered. And it's redered out of screen or in some area of the resulting qt item.

So, what is proposed with the patch on OCCT, is:
when renderer of this item happens we get id of this frame buffer and set it into OCCT variable SET_NO_FRAMEBUFFER(id), after doing redraw for V3d_View, after restore in OpenGl_Context the previous value if variable using SET_NO_FRAMEBUFFER(prev_id).

kgv

2021-01-22 19:54

developer   ~0098358

Last edited: 2021-01-22 19:58

Could you please clarify what kind of issues experienced while using OpenGl_Context::SetDefaultFrameBuffer(), designed for that purpose and tested in some samples in the past?
If there are some bugs in this API, then it would be better fixing them.

So far, I've personally tried only QOpenGLWidget, but don't conceptual difference with QtQuick FBO.

Issue History

Date Modified Username Field Change
2021-01-22 17:05 nds New Issue
2021-01-22 17:05 nds Assigned To => nds
2021-01-22 17:05 nds File Added: several_views_on_one_openGl.png
2021-01-22 17:17 kgv Note Added: 0098340
2021-01-22 17:17 kgv Status new => feedback
2021-01-22 17:17 kgv Note Edited: 0098340
2021-01-22 17:17 kgv Note Edited: 0098340
2021-01-22 17:18 kgv Note Edited: 0098340
2021-01-22 17:18 kgv Note Edited: 0098340
2021-01-22 17:35 nds Note Added: 0098342
2021-01-22 17:35 nds Status feedback => assigned
2021-01-22 17:41 kgv Note Added: 0098343
2021-01-22 17:41 nds Note Added: 0098344
2021-01-22 17:49 kgv Note Added: 0098345
2021-01-22 17:50 kgv Note Edited: 0098345
2021-01-22 17:50 kgv Note Edited: 0098345
2021-01-22 17:59 nds Note Added: 0098347
2021-01-22 18:00 nds Note Added: 0098348
2021-01-22 18:17 nds Note Added: 0098351
2021-01-22 19:54 kgv Note Added: 0098358
2021-01-22 19:54 kgv Note Edited: 0098358
2021-01-22 19:58 kgv Note Edited: 0098358
2021-02-02 16:59 kgv Relationship added related to 0031597
2021-08-24 14:19 kgv Target Version 7.6.0 => 7.7.0
2022-08-17 11:57 kgv Target Version 7.7.0 => 7.8.0
2023-08-01 15:09 dpasukhi Target Version 7.8.0 => Unscheduled