Hello,
Firstly, thank you for your work; I've been using it for quite some time now.
Recently, a serious open-source alternative to Optifine, called Oculus, has emerged.
This alternative offers support for some of the best Fabric mods ported to Forge, such as Sodium with Rubidium.
It would be highly beneficial to provide support for these mods instead of Optifine, especially for users seeking better-optimized client/server experiences or those who prefer open-source mods.

Here is a list of some relevant URLs:

• Connectedness
• Reforgium
• Enhanced Block Entities Reforged (Unofficial)
• Radium Reforged
• Oculus
• Rubidium
• Embeddium

Have a great day!

Works now, see #88 (comment)

I’d love to be able to support these mods, rubidium especially and I intend to add support for them (and to make NoCubes able to run entirely on Fabric) at some point. I don’t have much time to spend working on the mod currently so this won’t happen for a while though.

Okay, no problem.
Do you have any ideas or suggestions for tasks that need to be completed to achieve this? (Either gradually to allow for step-by-step changes without needing to overhaul the entire codebase, or in parallel to allow support for either Optifine or Rubidium, depending on which mods are available.)
I'm not a modder, but I am a software engineer, so perhaps I can learn modding to try to help. (I created some mods in the past, but things have changed, so I'd need to learn again. ;) )

I’m a SWE by day too, adding support for Rubidum/Oculus should be pretty straightforward, it’s the same as switching/upgrading a library/framework for a normal software project but with a couple extra steps. I’d love some help, if you’d like to get up to speed on the mod there’s an overview of how the mod works in README.md#HOW and instructions for setting up a dev environment are there too. FYI nocubes is rather different from other mods, and writing code for it is rather different for other mods too, there’s very little messing with registries or game logic, it’s almost all just rendering and optimising.

I do have an idea for how to do this, here’s a general flow of an improvement loop for adding compatibility:
Get the mods running together in a dev environment -> make code changes to stop them crashing (repeat until it works) -> with the understanding gained of the other mod, get a single feature working (repeat until all features work) -> simplify and optimise.
Step by step this would look something like:

1. Add Rubidum as a development dependency so it can run in a dev environment (done, will push to master soon)
2. Disable some (or most) of NoCubes’ rendering changes (Mixins) until the mods load together (likely just the world renderer & chunk renderer changes)
3. Inspect Rubidum’s rendering pipeline and how it differs from Vanilla’s and OptiFine’s, specifically chunk rendering
4. See how to implement the flow described in the How section of the readme into Rubidum’s pipeline
5. Do exploratory implementations, refining them until NoCubes’ rendering works (i.e. create new code for Rubidum - don’t reuse existing vanilla/optifine code)
6. Aggressively refactor the existing and newly created code to deduplicate, generify and optimise it so that it is production ready

Thank you for these explanations.
I was able to clone and build/run the normal configuration.
As expected, uncommenting the Rubidium dependency led to a crash. I will see what I can do in the next two weeks.

If you comment out the code in WorldRendererMixin.java and src/main/resources/…/nocubes-transformer.js the game should load (without NoCubes’ rendering)

My discord is Cadiboo#8887 and there’s also a discord server for the mod (https://cadiboo.github.io/projects/nocubes/discord) - it’s much better for quick communication if you want to share ideas or talk about how the mod works. I hope to have some spare time in the next two days to work on this compatibility as well

Update on this: I’ve done steps 1-4 and pushed the code to master.
Step 5 seems relatively straightforward, though it seems as though very little of the vanilla/optifine rendering code can be reused - sodium/rubidium uses a completely separate render pipeline that doesn’t use any of the existing vanilla code. All that seems to be necessary though is hooking up the output of the mesh generation to sodium/rubidium’s renderer which will hopefully be mostly boilerplate/glue code (i.e. straightforward to someone already familiar with OpenGL, though likely arcane to someone unfamiliar).