SkyBox shows certain textures as white

[JohnMH_]

I've been working on what's essentially a toy game engine, which uses Irrlicht for graphics. While implementing a wrapper for skyboxes, I noticed some interesting behavior.

When I load all 6 textures before a SkyBox scene node is ever created, all textures render properly. Any textures loaded after the first skybox scene node appear as white.

When are loaded beforehand:


When half are loaded after creating a skybox:


I noticed something in one of the tests that noted white textures under certain circumstances with the OpenGL driver, which I'm using on all platforms. I think it's possible that I'm running into that here.

Any ideas? I'm loading my textures from IReadFiles immediately before adding the SkyBox to the SceneManager.

[devsh]

Post an APItrace or similar GPU debug program output (except for RenderDoc, that doesn't work without ogl core profile).

[CuteAlien]

This textures loading later - just asking - we are talking about same thread? As Irrlicht is not multithread-safe.

[JohnMH_]

All calls to Irrlicht are made from the same thread. When I say "loading later", I'm referring to IVideoDriver->getTexture(IReadFile) and then oldSkyBox->remove(), ISceneManager->addSkyBoxSceneNode()

[JohnMH_]

I have uploaded an APItrace trace file here: https://openblox.org/~johnmh/lt-openblox-studio.trace

[JohnMH_]

In case any Qt stuff got thrown in, here's a trace of the same code without the Qt cruft and a much lower frame count: https://openblox.org/~johnmh/lt-openblox.trace

[devsh]

Do Qt and Irrlicht use the same OpenGL context for rendering?

If thats the case you may have a special case of good old GL-state pollution.

Btw, in your API-trace

85506 @1 glGenTextures(n = 1, textures = [0])

glGenTextures should only ever return non zero texture handles!

Its really impossible to get under normal driver usage, which implies that you have must lost the GL-context somewhere along the way
https://stackoverflow.com/questions/298 ... eturing-0s

Irrlicht and QT are not playing nice

[JohnMH_]

Qt doesn't use the same OpenGL context, and the results are the same whether Qt is used or not (which is why I uploaded a trace without Qt).

[devsh]

The fact that glGenTextures returns a 0 handle is down to 2 things:
a) you don't have a GL-context
b) you've called glGenTextures a ridiculous amount of times (doesn't happen here I guess)

So for option A there are only two possibilities:
1) You've lost your GL context
2) You're calling in a thread that never had a GL context (loading textures done by some QT callback, which would actually be threaded)

I think its likely you lost your context if Qt caled MakeCurrent somewhere else (if its in a different thread then ApiTrae may have not caught it, or caught it out of order).

This says that it can acutally initialize the context in a deferred way, i.e on first draw.
https://stackoverflow.com/questions/813 ... gl-with-qt

Make sure this love machine is not being called in the same thread as your irrlicht one
https://doc.qt.io/qt-5/qopenglcontext.html#doneCurrent

[JohnMH_]

Qt isn't doing anything with this GL Context. However, I'm now 90% positive that our asset cache runs on a different thread, and we're calling getTexture in a hook from that.

[JohnMH_]

Yep, that was indeed the issue! I'd forgotten my own 2 year old code. Oops.