* Add API for adding custom dynamic registries
Closes#1012, supersedes #1031 and #2719.
* Add missing license headers
* Clarify RegistryLoaderMixin namespace injection
* Replace event with static registration, add skeleton for sorting registries
* Fix typo
* Refactor event phase sorting system for use with dynamic registries (#1)
* Make minor changes to Technici4n's PR
* Add test for nested dynamic objects
* Revert "Add test for nested dynamic objects"
This reverts commit 486e3e1ce0.
* Revert "Make minor changes to Technici4n's PR"
This reverts commit 741bd52c1e.
* Revert "Refactor event phase sorting system for use with dynamic registries (#1)"
This reverts commit bb7c8b8790.
* Remove sorting API
* Add support for defaulted dynamic registries
* Re-add test for nested dynamic objects
* Add missing license headers
* Fix typo
* Remove defaulted dynamic registries; flatten registration methods
* Remove last reference to registry sorting
* Add option to skip syncing for empty dynregs
* Update DynamicRegistrySyncOption docs
Co-authored-by: Technici4n <13494793+Technici4n@users.noreply.github.com>
* Address review feedback
* Add registry namespace to tag paths for modded registries
* Move dynamic registry tests into their own class for readibility
* Finish DynamicRegistries doc
* Only apply tag change to dynamic registries
* Fix checkstyle
* Update fabric-registry-sync-v0/src/main/java/net/fabricmc/fabric/api/event/registry/DynamicRegistries.java
Co-authored-by: Technici4n <13494793+Technici4n@users.noreply.github.com>
---------
Co-authored-by: Technici4n <13494793+Technici4n@users.noreply.github.com>
This PR deprecates and supersedes the old `fabric-models-v0` module.
## Refactors compared to v0
### Model loading hooks
Mods now register a single `ModelLoadingPlugin` for any change they want to make to the model loading process. (Or multiple plugins if they want to). This replaces the old `ModelLoadingRegistry`.
Here is an example:
```java
ModelLoadingPlugin.register(pluginContext -> {
// ResourceManager access is provided like in the v0 API, but in a central place, and can be used for shared processing in the plugin.
ResourceManager manager = pluginContext.resourceManager();
// Model resource providers still exist, but they are called model resolvers now
pluginContext.resolveModel().register(context -> {
// ...
});
});
```
#### `ModelVariantProvider` -> `BlockStateResolver`
`ModelVariantProvider` was heavily reworked, and is now replaced by the `BlockStateResolver`, with a much better defined contract.
#### `ModelResourceProvider` -> `ModelResolver`
The resource provider is mostly unchanged. The biggest difference is that it is now registered as an event listener. This allows mods to use event phases for ordering between conflicting ~~providers~~ resolvers.
#### Removed custom exception
Additionally, `ModelProviderException` could be thrown by a variant or resource provider in the v0 API. This was not explained in the documentation, and would according to the code stop further processing of the providers and log an error.
In the new API, any `Exception` is caught and logged. If that happens, the other resolvers are still processed. There is no custom `Exception` subclass anymore.
### Helper method to get a `BakedModel` by `Identifier` from the manager
The v0 had such a method in a helper class: `BakedModelManagerHelper#getBakedModel`. It is now interface-injected instead. See `FabricBakedModelManager`.
## New model wrapping hooks
New hooks are added for the various needs of mods that want to override or wrap specific models. Thanks to @embeddedt for contributing an initial version of them!
Here is an example of wrapping the gold model to remove the bottom quads, for example:
```java
ModelLoadingPlugin.register(pluginContext -> {
// remove bottom face of gold blocks
pluginContext.modifyModelAfterBake().register(ModelModifier.WRAP_PHASE, (model, context) -> {
if (context.identifier().getPath().equals("block/gold_block")) {
return new DownQuadRemovingModel(model);
} else {
return model;
}
});
});
```
There are 3 events, for the following use cases:
- Wrapping `UnbakedModel`s right when they are loaded. This allows replacing them entirely in dependent models too.
- Wrapping `UnbakedModel`s right before they are baked. This allows replacing them without affecting dependent models (which might not be expecting a model class change).
- Wrapping `BakedModel`s right when they are baked.
Multiple mods have implemented their own version of them. Providing them in Fabric API will make it easier on these mods, and will additionally allow optimization mods that perform on-demand model loading to simply fire the hooks themselves instead of working around injections performed by other mods.
Co-authored-by: embeddedt <42941056+embeddedt@users.noreply.github.com>
Co-authored-by: PepperCode1 <44146161+PepperCode1@users.noreply.github.com>
Co-authored-by: Juuz <6596629+Juuxel@users.noreply.github.com>
* Fix injected resources not overriding certain vanilla resources
* Adjust comment
* Add test blocks for High Contrast pack, too
* Fix `GroupResourcePack`
* Deduplicate logic between `GroupResourcePack` and `FabricWrappedVanillaResourcePack`
* Fix checkstyle
* Delete gravel texture override, change dirt to diamond block
- Adds an event, `ParticleRenderEvents.ALLOW_BLOCK_DUST_TINT`, that checks
if a block dust particle of a specific block can be tinted.
- Bumps Fabric Loader requirement of fabric-particles-v1 to latest to
disable Loader's mixin compatibility mode that ignores slices for
certain At annotations.
* Add builders for BlockSetType and WoodType to replace registries
Adds `BlockSetTypeBuilder` and `WoodTypeBuilder` to replace `BlockSetTypeRegistry` and `WoodTypeRegistry` respectively.
* whoops
* double whoops
* Register and Build now separate methods
Separated the register and build methods, with the former calling the latter. Their relationship is explained in the javadoc.
* Update BlockSetTypeBuilder.java
### 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`.
* Add metadata information to POMs
* Add name, description, url and issue management
Also update the license name and an url to the fabric website
Pulls name and description from the fabric.mod.json
* Fix imports and make git optional
* Remove commit from maven metadata
The ClientPreAttackCallback will fire every tick when the attack key is pressed, before vanilla attack handling. If the callback returns true, then the vanilla handling (breaking block, attacking entity, swining hand) will be cancelled. For multiple callbacks, if the former callback returns true, the later callback won't execute.
This event does not consider attack cooldown.
* Material inspection
- Add MaterialView to get material properties from RenderMaterial and MaterialFinder
- Add MaterialFinder#copyFrom to copy properties from another MaterialView
- Finish todo in QuadView#toBakedQuad
- Move material impl classes to material package
* Add glint material property
- Allow force enabling or force disabling glint on items
- Force enable glint on horizontal sides of pillar item model in test mod
* Fix imports
* Add documentation
* Do not create invalid materials
- Ensure material bits are valid before creating material
- Assert that default MaterialFinder bits are valid
- Remove ordinal checks in MaterialViewImpl since bits are now guaranteed to be valid
- Set default glint mode to default instead of false
- Remove getter overrides in RenderMaterialImpl
* Add MutableQuadView#copyFrom
- Deprecate QuadView#copyTo
* Add missing nullability annotations
* Add toStrings to Storage, ContainerItemContext and Transaction impls
* StorageUtil: Use crash reports for adding context to errors
* Drop Impl suffix from variant impl toStrings
Since they are the only implementations, it offers no meaningful info for
callers.
* Centralise formatting code, include BE inventory position
* Include amount and resource in all ContainerItemContext.toString impls
* Use crash callables in StorageUtil
* Add crash report to FluidStorageUtil
* Add owning thread to TransactionImpl.toString
* Use thread name in TransactionImpl.toString
The other info clutters the message.
* Fix code style
