-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Partial incompatibility with Sodium (Flywheel backend) #54
Comments
Haven't found any issues at all with Sodium when Flywheel backend is disabled |
https://github.com/Jozufozu/sodium-forge/commit/9bcfbc28118fc35ee831a01eea7c59b55b94fd26 |
|
Absolutely, ping me if you get it working and I'll help verify |
It seems to work fine with Indium |
Could this be an nvidia issue? |
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:
|
It occurs when chunks are reloaded after the blocks are placed |
Gonna look into this to see what the cause is |
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 |
|
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 |
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 |
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. |
I was trying it a few minutes ago, and everything looked how I'd expect coming from the Forge version. |
Yeah, I see. Okay |
Have you disabled flywheel backend? |
I haven't. |
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. I guess that means it was off the entire time and I just never noticed. |
Known issue with Iris, though we haven't actually opened an Issue about that |
For me it was instancing by default. So before I disabled it i ran just |
Running the |
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. |
There are no shafts on the gearboxes |
Alright I appreciate it but you can both stop updating on every minor detail lol, the issue is known |
Okay, sorry. |
No harm done 😄 |
This was fixed completely in Flywheel as of yesterday, and I am not aware of any issues with Create specifically, so I am closing this issue. If there are other problems please open a new one. |
Create's shafts, belts, crushing wheels, and probably more do not render at all while the Flywheel backend is enabled.
The text was updated successfully, but these errors were encountered: