Partial incompatibility with Sodium (Flywheel backend)
AeiouEnigma opened this issue · 45 comments
Create's shafts, belts, crushing wheels, and probably more do not render at all while the Flywheel backend is enabled.
https://github.com/Jozufozu/sodium-forge/commit/9bcfbc28118fc35ee831a01eea7c59b55b94fd26
No doubt sodium's internals have changed, but this needs to be fixed on their end
Jozufozu/sodium-forge@9bcfbc2 No doubt sodium's internals have changed, but this needs to be fixed on their end
Okay it's not quite as plug-and-play as I was hoping. No improvement when flywheel backend is enabled, and making that change to sodium as-written also newly breaks things when flywheel backend is disabled
This task is officially beyond me lol
It seems to work fine with Indium
Possibly, Sodium has had problems with driver-specific things in the past
Here's a small update: It fixes it, but only for a period of time, and then it spams the following error in the console:
[22:42:44] [Render thread/INFO]: OpenGL debug message: id=1282, source=API, type=ERROR, severity=HIGH, message='Error has been generated. GL error GL_INVALID_OPERATION in (null): (ID: 173538523) Generic error'
It looks like that when a chunk reload is triggered via world reload, f3+a, or unloading a chunk, FlyWheel removes the models it needs to render, and Sodium's renderer doesn't call the methods that FlyWheel uses to put them back
ChunkRenderDispatcher$RenderChunk$RebuildTask$handleBlockEntity (ChunkBuilder$BuiltChunk$RebuildTask$addBlockEntity on yarn) isn't called on sodium's side, and that's what FlyWheel uses to re-add the BlockEntities.
Same issue exists on Canvas Renderer, unsure if I should create a new issue since it might be the same error causing it on both renderers.
As of the latest version, It straight up crashes during startup due to a mixin conflict with LevelRendererMixin and MixinWorldRenderer on Flywheel and Sodium respectively
As of the latest version, It straight up crashes during startup due to a mixin conflict with LevelRendererMixin and MixinWorldRenderer on Flywheel and Sodium respectively
The crash will be fixed in the next Flywheel update.
Partially fixed in builds 343 and 344. Still crashes occasionally but it works now. World launches, belts and entities are rendered properly. Even Shaders are partially working. Great job, @AeiouEnigma
Appreciate it, but truly the credit needs to go to Jozufozu and Pepper :)
I only took 2 minutes to merge the existing code from the forge version.
To avoid crashes, just make sure to set /flywheel backend off. Shaders seem to work fine with contraptions if you use Iris's new configuration menu to disable shader-based shadows, if the option exists for your particular shaderpack.
To avoid crashes, just make sure to set
/flywheel backend off. Shaders seem to work fine with contraptions if you use Iris's new configuration menu to disable shader-based shadows, if the option exists for your particular shaderpack.
Will try that. Thanks!
Why is this issue still open?
Because using Sodium, even with Indium installed, still results in severe rendering issues when the Flywheel backend is enabled.
Running /flywheel backend batching crashed the game instantly. Running /flywheel backend instancing does the same.
Known issue with Iris, though we haven't actually opened an Issue about that
Running /flywheel backend batching crashed the game instantly.
Running /flywheel backend instancing does the same.
I guess that means it was off the entire time and I just never noticed.
I was trying it a few minutes ago, and everything looked how I'd expect coming from the Forge version.
Why is this issue still open?
Because using Sodium, even with Indium installed, still results in severe rendering issues when the Flywheel backend is enabled.
Yeah, I see. Okay
I was trying it a few minutes ago, and everything looked how I'd expect coming from the Forge version.
Have you disabled flywheel backend?
Wait, is it off by default? I just noticed that text on the right, but I haven't run that /flywheel backend off command.
Wait, is it off by default? I just noticed that text on the right, but I haven't run that /flywheel backend off command.
Not sure. Maybe it should be Off
@AeiouEnigma should Flywheel be marked as Off in F3 menu
Running /flywheel backend batching crashed the game instantly. Running /flywheel backend instancing does the same.
I guess that means it was off the entire time and I just never noticed.
For me it was instancing by default. So before I disabled it i ran just /flywheel backend and it printed default value which was instancing for me.
Running the /flywheel backend instancing or /flywheel backend batching commands with sodium installed results in various blocks having messed up or non-existent rendering
Yeah, Iris does not like this.
Turning shaders on made contraptions (the windmill) disappear, and turning them back off just crashed the game.
With Iris off, it's defaulting to Instancing, and I'm seeing the same issues as here.
Batching just makes it all disappear:
Yeah, Iris does not like this. Turning shaders on made contraptions (the windmill) disappear, and turning them back off just crashed the game.
With Iris off, it's defaulting to Instancing, and I'm seeing the same issues as here.
For shaders disable Realtime shadows. This fixes the Windmills
If the world loads while the flywheel backend is enabled, things will probably look just fine until the renderer reloads.
Contraptions not rendering with certain shaders enabled is another known issue. If the shaderpack has an option to disable shadows, that may 'fix' the problem.
Interestingly, newly-placed blocks seem to render just fine, but toggling Flywheel or using F3+A makes things disappear.
The cogwheel was even spinning.
Alright I appreciate it but you can both stop updating on every minor detail lol, the issue is known
Alright I appreciate it but you can both stop updating on every minor detail lol, the issue is known
Okay, sorry.
