### API Changes - Interface inject `FabricBakedModel` This change was done to eliminate the constant need to cast `BakedModel` to `FabricBakedModel`, especially when rendering sub-models. The implementations for the methods of `FabricBakedModel` were moved from `BakedModelMixin` to `FabricBakedModel` as default implementations. Some javadoc was updated to reflect this change. - Deprecate the mesh consumer (`Consumer<Mesh>` retrieved from `RenderContext`) This change was done to ensure consistency across all current and future contexts in which a mesh may need to be output to a quad emitter. The preferred direct replacement is the new method `Mesh#outputTo(QuadEmitter)`. Some javadoc was updated to reflect this change. - Deprecate the baked model consumer (`BakedModelConsumer` retrieved from `RenderContext`) This change was done to ensure consistent rendering of sub-models and to eliminate assumptions about what features a model uses. The preferred direct replacement is to use the appropriate `emit` method in `FabricBakedModel`. Some javadoc was updated to reflect this change. Even though the consumer is now deprecated, the default `FabricBakedModel` method implementations still use it and renderers must still implement the getter. This is because Indigo and Indium sometimes apply smooth lighting differently based on if the quad came from a vanilla model or not. The eventual solution to allow all baked model consumer usage to be removed is to allow renderers to override the default `BakedModelMixin` and handle default vanilla models directly. - Fix `QuadView#toVanilla`'s javadoc reporting the wrong minimum array size ### Implementation Changes - Restructure `RenderContext` implementations This change was done to reduce code duplication, improve standardization, and improve readability. Most code of `AbstractQuadRenderer` was moved into a new class called `AbstractBlockRenderContext` (which `BlockRenderContext` and `TerrainRenderContext` now extend), with the main buffering method being moved to `AbstractRenderContext`. - Remove red blue color swap It is unclear why this code was necessary in the first place. Indigo stores vertex color in ARGB format, then converts it to ABGR format only if the native byte order is little endian, and then reads the vertex color in ABGR format when buffering vertex data. This would mean that on big endian systems, all red and blue color components would be swapped. Now, color is read in ARGB format when buffering and no color format conversion or swapping is done. - Encode face normal This change was done to improve the performance of meshes. Meshes already encoded all other geometry data, but the face normal would still have to be recomputed every time a mesh quad was rendered. Now, it is stored in the quad data header, so it is simply decoded, which is significantly faster. - Fix some bugs - Outputting a mesh via the mesh consumer would result in the emitter retaining the data of the last quad in the mesh. - In non-terrain block rendering, the baked model consumer would incorrectly use the random seed provided by the block state instead of the passed random seed argument. - When converting to or from vanilla quad data, the color would not be converted. Indigo uses ARGB format to store color, while vanilla quads use ABGR or RGBA. See the comment near the bottom of `ColorHelper` for more information. - Fix TerrainRenderContext using incorrect overlay value of `0` instead of `OverlayTexture.DEFAULT_UV`. - Improve performance of some code - `QuadViewImpl#computeGeometry()` was being called before transforms and the cull test were applied. These operations can change the geometry and invalidate computed geometry data or cancel the quad outright. Calling the method explicitly in those contexts was also not necessary in the first place. - A single `Vector4f` instance is now reused to transform the vertex position instead of allocating a new `Vector4f` for each vertex. - The random seed lazy computation now uses a separate boolean instead of checking if the seed is `-1`. |
||
---|---|---|
.github | ||
deprecated | ||
fabric-api-base | ||
fabric-api-lookup-api-v1 | ||
fabric-biome-api-v1 | ||
fabric-block-api-v1 | ||
fabric-blockrenderlayer-v1 | ||
fabric-client-tags-api-v1 | ||
fabric-command-api-v2 | ||
fabric-content-registries-v0 | ||
fabric-convention-tags-v1 | ||
fabric-crash-report-info-v1 | ||
fabric-data-generation-api-v1 | ||
fabric-dimensions-v1 | ||
fabric-entity-events-v1 | ||
fabric-events-interaction-v0 | ||
fabric-game-rule-api-v1 | ||
fabric-gametest-api-v1 | ||
fabric-item-api-v1 | ||
fabric-item-group-api-v1 | ||
fabric-key-binding-api-v1 | ||
fabric-lifecycle-events-v1 | ||
fabric-loot-api-v2 | ||
fabric-message-api-v1 | ||
fabric-mining-level-api-v1 | ||
fabric-models-v0 | ||
fabric-networking-api-v1 | ||
fabric-object-builder-api-v1 | ||
fabric-particles-v1 | ||
fabric-recipe-api-v1 | ||
fabric-registry-sync-v0 | ||
fabric-renderer-api-v1 | ||
fabric-renderer-indigo | ||
fabric-rendering-data-attachment-v1 | ||
fabric-rendering-fluids-v1 | ||
fabric-rendering-v1 | ||
fabric-resource-conditions-api-v1 | ||
fabric-resource-loader-v0 | ||
fabric-screen-api-v1 | ||
fabric-screen-handler-api-v1 | ||
fabric-sound-api-v1 | ||
fabric-transfer-api-v1 | ||
fabric-transitive-access-wideners-v1 | ||
gradle | ||
src | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
build.gradle | ||
checkstyle.xml | ||
CONTRIBUTING.md | ||
gradle.properties | ||
gradlew | ||
gradlew.bat | ||
HEADER | ||
LICENSE | ||
README.md | ||
settings.gradle |
Fabric API
Essential hooks for modding with Fabric.
Fabric API is the library for essential hooks and interoperability mechanisms for Fabric mods. Examples include:
- Exposing functionality that is useful but difficult to access for many mods such as particles, biomes and dimensions
- Adding events, hooks and APIs to improve interopability between mods.
- Essential features such as registry synchronization and adding information to crash reports.
- An advanced rendering API designed for compatibility with optimization mods and graphics overhaul mods.
Also check out Fabric Loader, the (mostly) version-independent mod loader that powers Fabric. Fabric API is a mod like any other Fabric mod which requires Fabric Loader to be installed.
For support and discussion for both developers and users, visit the Fabric Discord server.
Using Fabric API to play with mods
Make sure you have install fabric loader first. More information about installing Fabric Loader can be found here.
To use Fabric API, download it from CurseForge, GitHub Releases or Modrinth.
The downloaded jar file should be placed in your mods
folder.
Using Fabric API to develop mods
To setup a Fabric development environment, check out the Fabric example mod and follow the instructions there. The example mod already depends on Fabric API.
To include the full Fabric API with all modules in the development environment, add the following to your dependencies
block in the gradle buildscript:
Groovy DSL
modImplementation "net.fabricmc.fabric-api:fabric-api:FABRIC_API_VERSION"
Kotlin DSL
modImplementation("net.fabricmc.fabric-api:fabric-api:FABRIC_API_VERSION")
Alternatively, modules from Fabric API can be specified individually as shown below (including module jar to your mod jar):
Groovy DSL
// Make a collection of all api modules we wish to use
Set<String> apiModules = [
"fabric-api-base",
"fabric-command-api-v1",
"fabric-lifecycle-events-v1",
"fabric-networking-api-v1"
]
// Add each module as a dependency
apiModules.forEach {
include(modImplementation(fabricApi.module(it, FABRIC_API_VERSION)))
}
Kotlin DSL
// Make a set of all api modules we wish to use
setOf(
"fabric-api-base",
"fabric-command-api-v1",
"fabric-lifecycle-events-v1",
"fabric-networking-api-v1"
).forEach {
// Add each module as a dependency
modImplementation(fabricApi.module(it, FABRIC_API_VERSION))
}
Instead of hardcoding version constants all over the build script, Gradle properties may be used to replace these constants. Properties are defined in the gradle.properties
file at the root of a project. More information is available here.
Contributing
See something Fabric API doesn't support, a bug or something that may be useful? We welcome contributions to improve Fabric API. Make sure to read the development guidelines.
Modules
Fabric API is designed to be modular for ease of updating. This also has the advantage of splitting up the codebase into smaller chunks.
Each module contains its own README.md
* explaining the module's purpose and additional info on using the module.
* The README for each module is being worked on; not every module has a README at the moment