Support FRAPI on NeoForge#3818
Conversation
|
Does this mean that it will route usage of FRAPI through our FRAPI implementation on NeoForge? Or is it somehow using a different FRAPI implementation and piping into our meshing system on another path? |
|
Closes #3766 |
The former is the case here, yes. The Forgified Fabric API provides the original FRAPI to mods on NeoForge, so from Sodium's perspective, nothing changes. On FFAPI's end, the FRAPI implementation uses additional context and extension methods added by NeoForge to integrate with its rendering APIs. |
douira
left a comment
There was a problem hiding this comment.
I'm in favor of this PR, it looks ok to me, I'm just wondering about the double mod presence check.
The issue
Sodium currently declares it contains a FRAPI renderer implementation on NeoForge, but does not actually include it. See #3766 for details.
The proposal
This PR adds support for FRAPI rendering on NeoForge by bundling the FRAPI module currectly included on Fabric. Services and mixins provided by this module are loaded conditionally only when FRAPI is present, ensuring that existing behavior remains unchanged.
Changes
PlatformModelEmitterandFRAPIRegistrar(renamed fromFRAPIProvider) servicesTesting
I tested the integration in a 26.1.2 NeoForge 26.1.2.77 instance with the following mods installed:
I used a Chisel to create a chiseled block, which is rendered using the
FRAPIEmitter. The results appear to be the same as when only Sodium is installed.Alternatives
I tried running Sodium alongside FFAPI without the
contains_renderermetadata attribute and everything appeared to work fine - I was able to load into the world and all blocks had the expected appearance. Therefore, as a temporary measure until this PR is merged, I'd suggest at least removing thecontains_rendererattribute to prevent the game from crashing.Closes #3766