The JAR declares that it contains a rendering plugin...

[17:10:40] [main/INFO]: [Indigo] Different rendering plugin detected; not applying Indigo.

However, Sodium does not currently register a renderer, causing mods to crash with a NullPointerException.

java.util.concurrent.CompletionException: java.lang.NullPointerException
	at Not Enough Crashes deobfuscated stack trace.(1.15.2+build.14) ~[?:?]
	at java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273) ~[?:1.8.0_242]
	at java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280) ~[?:1.8.0_242]
	at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1606) ~[?:1.8.0_242]
	at java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1596) ~[?:1.8.0_242]
	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289) ~[?:1.8.0_242]
	at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056) ~[?:1.8.0_242]
	at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692) ~[?:1.8.0_242]
	at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157) ~[?:1.8.0_242]
Caused by: java.lang.NullPointerException
	at net.dblsaiko.hctm.client.render.model.UnbakedWireModel.<init>(UnbakedWireModel.java:102) ~[2660aded-8ccb-49f1-8d34-a98c3def0742.jar:?]
	at net.dblsaiko.rswires.client.RSWiresClient$onInitializeClient$1.apply(RSWiresClient.java:22) ~[rswires-4.0.7-standalone.jar:?]
	at net.dblsaiko.rswires.client.RSWiresClient$onInitializeClient$1.apply(RSWiresClient.java:16) ~[rswires-4.0.7-standalone.jar:?]
	at net.fabricmc.fabric.impl.client.model.ModelLoadingRegistryImpl$LoaderInstance.lambda$new$0(ModelLoadingRegistryImpl.java:66) ~[de705b74-fc81-4d7f-97b0-98efe2a37168.jar:?]
	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) ~[?:1.8.0_242]
	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382) ~[?:1.8.0_242]
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) ~[?:1.8.0_242]
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) ~[?:1.8.0_242]
	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) ~[?:1.8.0_242]
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:1.8.0_242]
	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:566) ~[?:1.8.0_242]
	at net.fabricmc.fabric.impl.client.model.ModelLoadingRegistryImpl$LoaderInstance.<init>(ModelLoadingRegistryImpl.java:66) ~[de705b74-fc81-4d7f-97b0-98efe2a37168.jar:?]
	at net.fabricmc.fabric.impl.client.model.ModelLoadingRegistryImpl$LoaderInstance.<init>(ModelLoadingRegistryImpl.java:54) ~[de705b74-fc81-4d7f-97b0-98efe2a37168.jar:?]
	at net.fabricmc.fabric.impl.client.model.ModelLoadingRegistryImpl.begin(ModelLoadingRegistryImpl.java:201) ~[de705b74-fc81-4d7f-97b0-98efe2a37168.jar:?]
	at net.minecraft.client.render.model.ModelLoader.handler$zkp000$addModelHook(ModelLoader:656) ~[?:?]
	at net.minecraft.client.render.model.ModelLoader.addModel(ModelLoader) ~[?:?]
	at net.minecraft.client.render.model.ModelLoader.<init>(ModelLoader:190) ~[?:?]
	at net.minecraft.client.render.model.BakedModelManager.prepare(BakedModelManager:50) ~[?:?]
	at net.minecraft.client.render.model.BakedModelManager.prepare(BakedModelManager:18) ~[?:?]
	at net.minecraft.resource.SinglePreparationResourceReloadListener.method_18791(SinglePreparationResourceReloadListener:11) ~[?:?]
	at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1604) ~[?:1.8.0_242]
	... 5 more

Would it be possible to have a stub implementation of Renderer that throws a more descriptive error when trying to use its methods?

Thanks for developing this amazing mod!

Sodium 0.3 is now released and contains support for the aforementioned features.

There is now experimental support for block rendering using FRAPI with 22d50ca.

Resolved with d2df183.

Haven't tested with any of those mods, it is possible that it's just RSWires.

Yeah, Campanion doesn't actually cause any calls into the renderer API from what I can see, which is strange. (I also don't yet know how fabric rendering works, so..)

Campanion does use the Fabric rendering api for rope bridges and things, here is an example:
https://github.com/TerraformersMC/Campanion/blob/1.16/src/main/java/com/terraformersmc/campanion/ropebridge/RopeBridgePlank.java

@coderbot16 is this behavior specific to rswires? I don't get a crash with just Campanion, and I don't remember TechReborn crashing either (just fluid cells being invisible).

@NeusFear Is there a reason you're referencing Indigo [1] directly instead of the registered renderer? This would both explain why I don't see any calls into my dummy renderer, and why Campanion doesn't crash when another renderer is registered.

[1] https://github.com/TerraformersMC/Campanion/blob/1.16/src/main/java/com/terraformersmc/campanion/ropebridge/RopeBridgePlank.java#L150

Going to ping @Wyn-Price I don't know the details of the rendering done.

I haven't seen any null pointer exception, but I have noticed that TechReborn's fluid cells are completely invisible and any color rendering of FlowableFluid ends up having the same color as water (even when the sprite is already colored). What I mean by that is, I have several fluids which uses a colored sprite and then load it with all white color so I can display the color of the sprite. This works just fine without Sodium installed, but has the same color as water when Sodium is installed.

TechReborn too references Indigo directly instead of querying for the actual registered renderer. That's how they get around crashing.

I hope it not only support fabric, I like soo much clear glass texture pack, but only work if i use optifine (so i hope this have it in the Future).

How is frapi support

In the discord, it says that JellySquid is going to try and implement support for the fabric rendering API for the 0.1 release, so you will soon have mod compatibility when that happens :)

Is this the essential cause of Wurst-Imperium/Wurst7#287?

@JamesTheAwesomeDude I doubt it, but we don't know and I haven't looked into it. Wurst is not supported (along with any other cheat client) and as such we're not going to investigate it.

I'm hoping that the Fabric Rendering API will be implemented soon.

Since this seems like a fairly significant development, any word on how comp500's Indium project may affect solving this issue? There's still some work to go, but it's making great progress.

As far as I know, the plan is to eventually merge Indium into Sodium

Preliminary support now exists for fabric-rendering-data-attachment-v1 and fabric-rendering-fluids-v1 in the 1.17.x/dev branch.

This is not complete support for what people refer to as "FRAPI", but it's non-zero.

Any update on this?
Just curious to be honest.

Any update on this?
Just curious to be honest.

There is an unreleased mod called Indium that fixes this, and I believe that it may eventually be merged into sodium.

Any update on this?
Just curious to be honest.

There is an unreleased mod called Indium that fixes this, and I believe that it may eventually be merged into sodium.

Yeah I know about that, but it still has some mod incompatibilities

Yeah I know about that, but it still has some mod incompatibilities

We can discuss this further on discord, if you want?

I have locked this issue because the conversation around it has almost entirely devolved into either users asking for progress updates or users incorrectly attributing unrelated issues with the lack of FRAPI support.

As of the time being: There is no ETA for when Fabric Render API support will be implemented. We originally gave an ETA that this would happen in the 0.2 series, but doing that has effectively held the project hostage and made it very difficult for us to break the ice with a new release, as support is still not here for it.

Sodium started out as my pet project, and while the community reception to it has been immense, I am still essentially the only contributor to this project who is pushing forward development with new features, optimizations, bug fixes, and improvements. My time for all this work has been paid, between donations and any other referral sources, at a rate significantly lower than even minimum wage, part-time jobs are offering around me right now.

Right now, whatever time is available for me to work on these projects is often being spent on other goals, such as improving hardware support and re-structuring the code with better abstractions and APIs, etc. This work has made it significantly easier for projects such as Indium and Iris to integrate with Sodium, and while it has brought the mod closer down the path of eventually supporting FRAPI, it isn't really something tangible in the hands of players today.

Summarily... It is difficult enough trying to implement a foreign API with such a large surface area into the project, and even more so when my time and energy has been stretched thin by a full-time job and such.

I would encourage those who are interested in seeing support for FRAPI in Sodium to either contribute upstream to the project or to build their own addons or forks (such as Indium) so we can better understand what work is ahead of us. This is not something I can do alone, and users pushing for me to implement (again, foreign APIs for their own interests) into what is basically a pet project is not a viable strategy.