Viewport preview not working

[m-dr]

Tested using 3.1 and 3.2. F12 render works, but viewport rendering does not. I'm getting a repeated 'ERROR 1282 in glUseProgram' error.
2022-06-22_log.txt
'

[stkrake]

Uuuh, looks like a problem with my code to copy the render result into Blender's frame buffer via OpenGL in C++. Maybe
the wrong OpenGL context is current (you have more than one GPU active, I never tested that case).
This was a bit shaky anyway...

I will see wether whether I can quick-fix that...

[m-dr]

I was thinking maybe it was the edge case of me having multiple GPUs - a laptop one and an external one. However, I'm only really using one of them, which is an external GPU to which my monitors are connected. I'd be good to just ignore the internal one?

[stkrake]

This has to be fixed anyway. I don't think it's worth to play with the setup. Never touch a running system :)

[stkrake]

I added 2 additional methods to copy the render result into Blender's frame buffer. They are selectable via "Method to blit to frame buffer" in the Render properties:

• "C++ OpenGL texture": This is the original method. It is still the fastest (if it works)

• "python bgl texture": Nearly the same but with Blender's bgl-methods from python. If the problem really was the OpenGL context this should solve it. Slightly slower because of more copies (but there may be better solutions in python).

• "gpu_extras": Via gpu_extras.presets.draw_texture_2d(). Should always work but is pretty slow.
  Blender does not seem to have a way to copy into an existing gpu.types.GPUTexture, so it must be reallocated every frame.

I hope than "python bgl texture" or "gpu_extras" works for you. If "python bgl texture" does not work, it has at least the possibility to test out things in python without C++ compilation.

Only the Blender add-on has to be updated. I attached it and will make an official release next week (I'm not in office from thursday). This is a bit of a quick fix, I really tested it only on Blender 3.2. May not work on 3.1 or 2.93

blRstrAddon.zip

Thanks for reporting and testing :)

[m-dr]

I can confirm that the 'gpu extras' method works! The other two do not (in the viewport). Seems quite slow indeed. I can continue providing logs later if you're going to keep trying make the faster methods work - I'll be checking the engine out to see if it can be useful to me, however incomplete the featureset is yet. I do appreciate the reuse of existing shader nodes!

[stkrake]

Well, at least the last fallback works :) Sadly it will hide most of the 3090 power...

But my initial guess that something with the C++ side is broken seems to be wrong. I will check the OpenGL code more next
week, maybe it is simply wrong and works only on certain driver/hardware combinations. Currently it also has not enough logging to see much.

[stkrake]

Two more fixes:

• The GLSL code used long deprecated features (texture2D() and gl_FragColor). They are still in OpenGL Compatibility profile, but Blender uses Core only. So this was just wrong.
• If the GLSL compilation fails, now errors are logged and exceptions thrown. This should show the reason for 'ERROR 1282', if it is still there.

These changes are in "C++ OpenGL texture" and "python bgl texture". Only the add-on needs to be updated. I attached it:
blRstrAddon.zip

Please note that the log output from the add-on itself is not redirected into "Absolute path of log file". I need to document
this better. The add-on output appears only in the System Console (and can be redirected if Blender is started from the command line). If there is a GLSL compilation failure, it should show up pretty early in the System Console.

[m-dr]

Okay, so the default C++ mode works for me now! I tried switching to other modes - don't see any difference in terms of performance so either the switching didn't work or the performance is similar - but I'll need to do a proper scene, not just a box with a light. I'll do some logging once I learn how to pipe console output on Windows. I had a funny bug at the first try today, when scaling an object up - my eGPU got turned off and I had to reboot.
I'll maybe also open another issue for some node related matters? For instance currently the HDRI environment node does not provide a correct equirectangular mapping and the mapping cannot be rotated properly.

[stkrake]

Okay, so the default C++ mode works for me now! I tried switching to other modes - don't see any difference in terms of performance so either the switching didn't work or the performance is similar - but I'll need to do a proper scene, not just a box with a light. I'll do some logging once I learn how to pipe console output on Windows.

That's great! If the C++ mode works now, we do not really need the other ones. I don't think it is worth to put effort into it.
Maybe I will keep the slow one as last resort :)

BTW: console output on Windows goes like this (you may want to use a full path for the log file):
"C:\Program Files\Blender Foundation\Blender 3.2\blender.exe" > blender_log.txt 2>&1

I had a funny bug at the first try today, when scaling an object up - my eGPU got turned off and I had to reboot.

Maybe an overheating problem? DXR raytracing uses a lot of power and once blRstr has all the data it needs it can reach >95% GPU usage. Which screen resolution are you running?

I'll maybe also open another issue for some node related matters? For instance currently the HDRI environment node does not provide a correct equirectangular mapping and the mapping cannot be rotated properly.

The environment node is a known problem. It is a bit hidden in the readme under point "World shaders are buggy...".
But generally new issues are highly welcome :)

Thank you for your help so far

[m-dr]

As for the GPU, I'm running UHD resolution. It's good to have resolution scaling like in Cycles or Unreal Engine, but a simple scene should be fairly responsive... there's also DLSS but I don't remember testing it much yet in UE.
I'm used to running a full on rendered Cycles all the time and it constantly draws maximum power from the GPU. I've got a 650W seasonic solely for the eGPU, which draws 350W and I got rid of the enclosure- it stands bare on a shelf. So probably not heat or power...

[stkrake]

As for the GPU, I'm running UHD resolution. It's good to have resolution scaling like in Cycles or Unreal Engine, but a simple scene should be fairly responsive... there's also DLSS but I don't remember testing it much yet in UE. I'm used to running a full on rendered Cycles all the time and it constantly draws maximum power from the GPU. I've got a 650W seasonic solely for the eGPU, which draws 350W and I got rid of the enclosure- it stands bare on a shelf. So probably not heat or power...

Yes, that should be enough :)
If it happends again, could you send the log file? The pure "Absolute path of log file"-file would be enough, no need to redirect anything. This file should be there even after a reboot. Maybe there is something to find.