GLES2 Renderer not working in Headset (OpenVR reports: 105)

[NeoSpark314]

Godot: current master (d482a1d8e8b4e68f2f386ba618cd091c79c20424)
Windows 10
SteamVR 1.7.15
godot_openvr: current master (3f170b7)
Compiled with Visual Studio 2019

When using the GLES3 renderer everything works as expected but when using the GLES2 renderer there is an infinite loading screen inside steam vr an the console outputs:
OpenVR reports: 105

This can be reproduced with the included demo project when switching to GLES2 but any other project I tried so far produced the same error and infinite loading inside the headset.

Note that both the desktop mirror screen as well as the tracking still work with GLES2. Only inside the headset there is the infinite steam loading screen.

[beniwtv]

Is there anything more in the line with "OpenVR reports"?

[NeoSpark314]

No; this is the only output (but repeated).

[beniwtv]

ok, found where that error is written in the module, it's when we try to submit a texture to OpenVR. Error 105 seems to mean 'texture in unsupported format' there.

Any ideas @BastiaanOlij ?

[BastiaanOlij]

That means that the texture format godot uses for the color output in gles2 is not supported or expected as an input for openvr Really weird because this used to work, i had my vehicle tutorial running in gles2 with openvr. It’s possible this may have changed when we did the work with Valve to make OpenVR work with RGBA16F buffers. I’ll have a closer look tonight when i get home

On Fri, 1 Nov 2019 at 11:41 am, Benedikt ***@***.***> wrote: ok, found where that error is written in the module, it's when we try to submit a texture to OpenVR. Error 105 seems to mean 'texture in unsupported format' there. Any ideas @BastiaanOlij <https://github.com/BastiaanOlij> ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#70?email_source=notifications&email_token=AAO262JCMPEHHBKN2TNXVJDQRN3LVA5CNFSM4JG65NB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECZVEUQ#issuecomment-548622930>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAO262JGB2MN42HB7ADEM73QRN3LVANCNFSM4JG65NBQ> .

-- Kindest regards, Bastiaan Olij https://www.facebook.com/bastiaan.olij https://twitter.com/mux213 https://www.youtube.com/BastiaanOlij <https://www.youtube.com/channel/UCrbLJYzJjDf2p-vJC011lYw> https://github.com/BastiaanOlij

[BastiaanOlij]

If you use the latest Godot master this should work fine now. This was all a result of the workarounds we put in place to make MSAA work on Quest. Now that that is implemented properly OpenVR should work fine. Just make sure you set the MSAA mode properly.

[BastiaanOlij]

Sorry I am mixing up issues :)
I'm able to reproduce this issue. Really weird one, this used to be ok

edit ok I don't know if this changed recently on our end or if OpenVR changes something but the problem is that we're using RGB buffers in the GLES2 driver. OpenVR requires RGBA buffers. You can force it to work by turning the viewports transparent background property on:

$get_viewport().transparent_bg = true

But you loose your background (sky etc), fine as a work around for indoor games.

@akien-mga any chance you can do your blame magic and find out if this piece of code was changed recently:
https://github.com/godotengine/godot/blob/master/drivers/gles2/rasterizer_storage_gles2.cpp#L4587
That is switching to an RGB buffer if transparency is off.

I can see that in the Godot 3.1 branch this code did not exist and an RGBA buffer was always created.

[akien-mga]

@akien-mga any chance you can do your blame magic and find out if this piece of code was changed recently:
https://github.com/godotengine/godot/blob/master/drivers/gles2/rasterizer_storage_gles2.cpp#L4587
That is switching to an RGB buffer if transparency is off.

Just replace blob by blame in the URL :)
https://github.com/godotengine/godot/blame/master/drivers/gles2/rasterizer_storage_gles2.cpp#L4587

Probably related to godotengine/godot#28518 (and subsequent changes), CC @clayjohn.

[clayjohn]

If the issue is using RGB instead of RGBA textures than that was added here godotengine/godot@aab8f44

I think he added RGB as default because it is more efficient on some of the really low end hardware? Im not sure what the rationale was, but I respected the format with my changes to MSAA and post-processing buffer.

[akien-mga]

If the issue is using RGB instead of RGBA textures than that was added here godotengine/godot@aab8f44

That commit is in 3.1-stable and 3.1.1-stable though - when did the rendering issue start for OpenVR? Does it work in 3.1 or only 3.0.x?

[BastiaanOlij]

There is more to this, just got feedback from Valve that GL_RGB8 should be supported. So either there is a difference between GL_RGB and GL_RGB8, but i can’t imagine what, or we do something else to the buffer that makes it incompatible. I’ll do some more experimenting tonight after work

On Tue, 19 Nov 2019 at 3:02 am, Rémi Verschelde ***@***.***> wrote: If the issue is using RGB instead of RGBA textures than that was added here ***@***.*** <godotengine/godot@aab8f44> That commit is indeed in 3.1-stable and 3.1.1-stable though - when did the rendering issue start for OpenVR? Does it work in 3.1 or only 3.0.x? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#70?email_source=notifications&email_token=AAO262MBQ26SSQB3FTLJDMTQUK4BFA5CNFSM4JG65NB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEK6DAY#issuecomment-555082115>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAO262IWQICEV3EG2CR4Z4TQUK4BFANCNFSM4JG65NBQ> .

-- Kindest regards, Bastiaan Olij https://www.facebook.com/bastiaan.olij https://twitter.com/mux213 https://www.youtube.com/BastiaanOlij <https://www.youtube.com/channel/UCrbLJYzJjDf2p-vJC011lYw> https://github.com/BastiaanOlij

[clayjohn]

We should likely be explicit and just use gl_rgb8 I've heard that it is better for a lot of hardware. For a lot of hardware GL_RGB doesn't necessary resolve to GL_RGB8.

[BastiaanOlij]

You can see we do the same in GLES3:
https://github.com/godotengine/godot/blob/master/drivers/gles3/rasterizer_storage_gles3.cpp#L6879

I'll experiment with it and if it works I'll also make sure the texture at the end gets the proper values.