Blender messes up with framebuffers in custom OpenGL renderer #90116

New Issue

Alexander Samsonov · 2021-07-25T10:39:17+02:00

2021-07-25 10:39:17 +02:00

System Information
Operating system: Linux-5.8.0-63-generic-x86_64-with-glibc2.31 64 Bits
Graphics card: GeForce RTX 2060 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 460.91.03

Blender Version
Broken: version: 2.93.0, branch: master, commit date: 2021-06-02 11:21, hash: 84da05a8b8
Worked: None. Does not work on 3.0 neither

Short description of error
Custom OpenGL-based renderer is inconsistent when using complex framebuffers. Result depends on blender window configuration and context.

Exact steps for others to reproduce the error
Install pyopengl module for blender's python with pip install pyopengl
Open attached renderengine_bug.py in blender and run the script
renderengine_bug.py
It will add a custom OpenGL-based renderer called GLRender in Blender's UI.
Try to render with bpy.ops.render.render('EXEC_DEFAULT') from Blender python console. It should render and after completion create 3 images corresponding to different outputs of fragment shader. Note that they all have different types - vec4, vec3 and float.
If you try to repeat that with Image Editor opened then for some reason only first attachment of the framebuffer seems to be drawn into, so images gl_1 and gl_2 are empty. If you have 3d viewport opened then again, everything renders as it should.
Rendering with bpy.ops.render.render('INVOKE_DEFAULT') always works fine.
So for some reason, the result of my OpenGL renderer depends on a window configuration of blender. So I might assume that some color attachments are reserved by blender or something. I am not 100% fluent with OpenGL, but when trying this code in a standalone python, everything is consistent.
Also note that attachments which have type vec4 are always rendered fine. So if you try to change type of col1 or col2 to vec4 and change fragment shader correspondingly, they are always render as should. So the problem is present only for outputs with types float, vec2, vec3.
I also uploaded a video demonstrating the problem:
2021-07-25 11-23-02.mp4

I have an almost exact renderer using blender's gpu module, where multiple framebuffer attachments works fine. I still cannot use that module completely as extracting data from gputextures to blender images is super slow compared to pyopengl+numpy

**System Information** Operating system: Linux-5.8.0-63-generic-x86_64-with-glibc2.31 64 Bits Graphics card: GeForce RTX 2060 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 460.91.03 **Blender Version** Broken: version: 2.93.0, branch: master, commit date: 2021-06-02 11:21, hash: `84da05a8b8` Worked: None. Does not work on 3.0 neither **Short description of error** Custom OpenGL-based renderer is inconsistent when using complex framebuffers. Result depends on blender window configuration and context. **Exact steps for others to reproduce the error** Install `pyopengl` module for blender's python with `pip install pyopengl` Open attached `renderengine_bug.py` in blender and run the script [renderengine_bug.py](https://archive.blender.org/developer/F10236680/renderengine_bug.py) It will add a custom OpenGL-based renderer called GLRender in Blender's UI. Try to render with `bpy.ops.render.render('EXEC_DEFAULT')` from Blender python console. It should render and after completion create 3 images corresponding to different outputs of fragment shader. Note that they all have different types - vec4, vec3 and float. If you try to repeat that with Image Editor opened then for some reason only first attachment of the framebuffer seems to be drawn into, so images gl_1 and gl_2 are empty. If you have 3d viewport opened then again, everything renders as it should. Rendering with `bpy.ops.render.render('INVOKE_DEFAULT')` always works fine. So for some reason, the result of my OpenGL renderer depends on a window configuration of blender. So I might assume that some color attachments are reserved by blender or something. I am not 100% fluent with OpenGL, but when trying this code in a standalone python, everything is consistent. Also note that attachments which have type vec4 are always rendered fine. So if you try to change type of col1 or col2 to vec4 and change fragment shader correspondingly, they are always render as should. So the problem is present only for outputs with types float, vec2, vec3. I also uploaded a video demonstrating the problem: [2021-07-25 11-23-02.mp4](https://archive.blender.org/developer/F10236681/2021-07-25_11-23-02.mp4) I have an almost exact renderer using blender's `gpu` module, where multiple framebuffer attachments works fine. I still cannot use that module completely as extracting data from gputextures to blender images is super slow compared to pyopengl+numpy

Alexander Samsonov commented

2021-07-25 10:39:17 +02:00

Added subscriber: @blendersamsonov

Omar Emara commented

2022-02-10 13:07:39 +01:00

Added subscriber: @OmarEmaraDev

Omar Emara commented

2022-02-10 13:07:39 +01:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Omar Emara commented

2022-02-10 13:07:39 +01:00

I either get corrupt data on the second and third attachment or I get zero data in software mode.
I am not sure if the code is correct to classify this as a bug, however.
All your attachment textures have a type of GL_RGBA32F but you write float and vec3 outputs in the fragment shader. Is that correct?
Can you also attach the gpu module version of your script?

I either get corrupt data on the second and third attachment or I get zero data in software mode. I am not sure if the code is correct to classify this as a bug, however. All your attachment textures have a type of `GL_RGBA32F` but you write float and vec3 outputs in the fragment shader. Is that correct? Can you also attach the gpu module version of your script?

Omar Emara commented

2022-05-25 11:40:30 +02:00

Just a poke regarding my inquiry above, otherwise we will have to archive this for now.

Omar Emara commented

2022-06-07 12:18:27 +02:00

Changed status from 'Needs User Info' to: 'Archived'

Omar Emara closed this issue

2022-06-07 12:18:27 +02:00

Omar Emara commented

2022-06-07 12:18:27 +02:00

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

Thanks again for the report. If the problem persists please open a new report with the required information.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed. Thanks again for the report. If the problem persists please open a new report with the required information.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Blender messes up with framebuffers in custom OpenGL renderer #90116