mirror of
https://github.com/FabricMC/fabric.git
synced 2024-12-04 21:31:26 -05:00
a025543665
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>
Signed-off-by: modmuss50 <modmuss50@gmail.com>
10 lines
254 B
Groovy
10 lines
254 B
Groovy
archivesBaseName = "fabric-model-loading-api-v1"
|
|
version = getSubprojectVersion(project)
|
|
|
|
moduleDependencies(project, ['fabric-api-base'])
|
|
|
|
testDependencies(project, [
|
|
':fabric-renderer-api-v1',
|
|
':fabric-rendering-v1',
|
|
':fabric-resource-loader-v0'
|
|
])
|