Crash/Bug on trying to change Video settings from High to Ultra

[TheOceanBreeze]

General Info

Terasology Launcher Version: v4.8.0
Terasology Version: v5.3
Operating System: Fedora Rawhide
Onboard / Dedicated Graphics: AMD RX 580
Java Version: Included Version (v21?)

What you were trying to do

Changing the settings from High to Ultra should not cause a crash. If there is an issue with the hardware used display an error message saying the hardware is unsupported, instead of crashing the game.

What actually happened

The game closed and displayed the crash window. I have uploaded the logs to this issue report.

The error says: RuntimeException: Failed to resolve required asset: 'CoreRendering:prePostComposite'

How to reproduce

1. Select Terasology version v5.3
2. Start Terasology
3. Open Settings
4. Change video settings from High to Ultra
5. See error

Log details

I have attached the appropriate logs.

Terasology-Game.log
Terasology-init.log
Terasology-menu.log

Screenshots

Workaround

N/A

Additional Infos / Context

N/A

[TheOceanBreeze]

Here are some more logs that may or may not be related to this current issue

9:28 PM:

Terasology-Game.log
Terasology-init.log
Terasology-menu.log

9:32 PM:

Terasology-Game.log
Terasology-init.log
Terasology-menu.log

9:45 PM (on a new world):

Terasology-Game_1.log
Terasology-init.log
Terasology-menu.log

[Cervator]

I'm going to guess this is a legitimate bug coming from a refactor in rendering sometime, as I imagine we don't test Ultra all that often - easy for something to have broken without being noticed for a while.

It may not be a hard fix, but effort in rendering land is tricky these days. Not sure when this can get looked at but I'm glad it at least isn't a total blocker for the game. Thank you for the report!

[soloturn]

does this happen with a new version also @TheOceanBreeze ?

[soloturn]

Can this still happen? Yes - traced the code path in the current develop.

prePostComposite isn't special - it's whichever material a preset switch happens to query right after some other shader's permutation fails to compile.

The chain:

1. The video settings screen's preset apply calls ShaderManager.recompileAllShaders(), which does getLoadedAssets(Shader.class).forEach(Shader::recompile) then the same for Material.
2. GLSLShader.recompile() queues registerAllShaderPermutations() via asynchToDisplayThread - with no try/catch. doReload() guards the identical call a few dozen lines down in the same file: try { registerAllShaderPermutations(); } catch (RuntimeException e) { logger.warn(...); }. Same operation, two entry points, only one is safe.
3. registerAllShaderPermutations() compiles the powerset of that shader's feature flags and throws a plain RuntimeException on any GL_COMPILE_STATUS failure - i.e. exactly the combinations a lower preset never exercised together. Ultra turning on SSAO + light shafts + cloud shadows + motion blur simultaneously is a very plausible first trigger for a driver-specific compile bug that lower presets never reached.
4. GLSLMaterial.recompile() is unguarded in both of its own call sites, and clears every existing compiled program before relinking - nothing to fall back to if relinking then fails partway through.
5. LwjglGraphicsManager.processActions() drains the queued display-thread actions with a plain forEach(Runnable::run). Every asynchToDisplayThread caller shares this one queue - recompileAllShaders() alone queues one action per loaded shader - so an uncaught exception from any single action used to abort every action queued after it in the same batch, not just the failing one. That's the most likely reason an unrelated material like prePostComposite is what surfaces: whatever actually failed to compile just needed to be queued ahead of it.

None of the three files above have changed since well before this report (last touch to GLSLShader.java: May 2024), so the mechanism is unchanged today.

What I can't do from here: reproduce the actual GL_COMPILE_STATUS failure - that needs the reporter's AMD RX 580 / Mesa driver stack, which I don't have. So I can't confirm which shader permutation fails on that hardware. But I don't need to, to answer "can this still happen": the unguarded path turns any such failure, on any driver, into a hard crash instead of the degraded-but-running game the report asked for.

Opening a PR that gives GLSLShader.recompile() and GLSLMaterial.recompile() the same try/catch doReload() already uses, and hardens processActions()'s loop so one failing action can't take the rest of the batch with it.

[soloturn]

Fix opened: #5369