* Deprecate FabricBlockSettings
* Deprecate FabricItemSettings
* Start on 24w03a
* Main menu :)
* Update mappings
* PayloadTypeRegistry
* Networking part 2 of many
* Networking part 3 of many
* Networking part 4 of many
* Recipe api
* Port Item API to 1.20.5
* Is this even right?
* Port FabricParticleTypes to 1.20.5
* Remove redundant fuel caching logic
* Remove fabric-containers-v0, deprecated since 2020
* Regsync work
* Adapt screen handler to new networking
* Update yarn + more work
* More mapping updates
* Compile fixes
* Checkstyle + small fixes
* Single and multiplayer fixes
* Handle play packets on main thread.
* Update mappings
* Even more networking
* Networking tests
* Fix todo's
* Update javadocs
* Networking API improvements
* Some small regsync refactors
* Fix handling of null NBT in NbtIngredient
* Update fabric-object-builder-api-v1/src/main/java/net/fabricmc/fabric/api/object/builder/v1/block/FabricBlockSettings.java
Co-authored-by: ErrorCraft <51973682+ErrorCraft@users.noreply.github.com>
* Update fabric-object-builder-api-v1/src/main/java/net/fabricmc/fabric/api/object/builder/v1/block/FabricBlockSettings.java
Co-authored-by: ErrorCraft <51973682+ErrorCraft@users.noreply.github.com>
* Add context objects
* ChannelInfoHolder.getPendingChannelsNames -> fabric_getPendingChannelsNames
* Fix crash
* send `c:register` packet for play phase instead of config (#3544)
* Bump version
---------
Co-authored-by: ErrorCraft <51973682+ErrorCraft@users.noreply.github.com>
Co-authored-by: apple502j <33279053+apple502j@users.noreply.github.com>
Co-authored-by: Drex <nicknamedrex@gmail.com>
Co-authored-by: deirn <deirn@bai.lol>
Breaking changes:
- `FabricBrewingRecipeRegistry.registerPotionRecipe` takes `RegistryEntry<Potion>` instead of `Potion`
- `SculkSensorFrequencyRegistry.regster` takes `RegistryKey<GameEvent>` instead of `GameEvent`
- `FabricLanguageProvider.add` takes `RegistryEntry<EntityAttribute>` instead of `EntityAttribute`
- `FabricTagProvider.GameEventTagProvider` was removed replace with `FabricTagProvider<GameEvent>`
- `FabricItem.getAttributeModifiers` returns a Multimap with a key of `RegistryEntry<EntityAttribute>` instead of `EntityAttribute`
- `ModifyItemAttributeModifiersCallback.modifyAttributeModifiers` takes Multimap with a key of `RegistryEntry<EntityAttribute>` instead of `EntityAttribute`
* Add cull check and item transformation mode getter to FRAPI
* Terminally deprecate `fallbackConsumer` and `bakedModelConsumer`
* Fix uvs in octagonal column test mod
* Review comments
(cherry picked from commit 39a511ba53)
* Improve flat shade
- Use AO mode to make flat shade calculation consistent with shade applied by smooth lighting
- Use face normal to calculate shade if necessary
- Use normal shade even if no custom normals are set
* Improve FRAPI test mod
- Add octagonal column to test irregular face lighting
- Use obsidian sprite instead of missing sprite for frame mesh
- Simplify and organize registration
- Inline `simple` package
* Fix crumbling on 45 degree faces
- Fix checkstyle
- Give octagonal column a non-zero hardness
* Fix checkstyle
* Improve PillarBakedModel to fully support custom block appearance
* Explain OverlayVertexConsumer fix
* Update to loom 1.3
* Fix more 1.3 deprecations
* Opps
* Move to mod publish plugin
* Revert some changes
* Fix some more Gradle deprecations
* Fix names
* Remove extra stuff
* Cleanup
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>
### 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`.
* 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
# Breaking changes
- `VillagerPlantableRegistry` replaced with `ItemTags.VILLAGER_PLANTABLE_SEEDS`
- `FabricItemGroup.builder()` no longer takes an `Identifier`
- `FabricItemGroup.build()` no longer registers the ItemGroup, this now needs to go in the vanilla registry.
- `ItemGroupEvents.modifyEntriesEvent` now takes a `RegistryKey<ItemGroup>` in place of an `Identifier`
- `FabricLanguageProvider` now takes a `RegistryKey<ItemGroup>` in place of an `ItemGroup`
- `IdentifiableItemGroup` removed, replaced with vanilla registries.
- `FabricMaterialBuilder` removed, no replacement.
- `HudRenderCallback.onHudRender` now passed a `DrawableHelper` in place of `MatrixStack`
- `ScreenEvents.beforeRender` now passed a `DrawableHelper` in place of `MatrixStack`
- `ScreenEvents.afterRender` now passed a `DrawableHelper` in place of `MatrixStack`
- `Screens.getItemRenderer()` removed. Replace with `MinecraftClient.getItemRenderer()`
`DrawableHelper` is likely to be renamed soon, see: https://github.com/FabricMC/yarn/pull/3548/
* Apply disabled shade from vanilla quads directly to material
- Remove QuadViewImpl.shade
* Fix enhanced AO calculation and respect non-terrain culling state
- Fix AoCalculator using AO face data computed with a potentially different shade state
- Move non-cached computation code to separate method in AoCalculator
- Turn AoCalculator's brightnessFunc and aoFunc into abstract methods
- Do not check null check world in non-terrain AO calculation since it cannot be null
- Pass through lightFace and shade state as method arguments in AoCalculator methods to prevent additional lookups
- Do not check for the axis aligned flag in AbstractQuadRenderer.shadeFlatQuad
- Respect cull parameter passed to non-terrain rendering by merging TerrainBlockRenderInfo into BlockRenderInfo
- Use reusable search pos when calling Block.shouldDrawSide to prevent additional BlockPos allocation
- Change BlockRenderContext.render and TerrainRenderContext.tessellateBlock to return void since return value is no longer used
- Remove QuadViewImpl.vertexStart since it is unused
* Add suggestions
- Mark Direction parameter to BlockRenderInfo.shouldDrawFace as Nullable
- Reuse MaterialFinder in FrameBakedModel
(cherry picked from commit 3a95925af4)
* Fix#2639: Indigo fallback consumer does not respect BlendMode or emissivity
* Change renderer testmod to test material change
* Remove presumably unneeded `quad.geometryFlags()` call
* Also test emissivity
* Call emitBlockQuads in the testmod
* Allow passing the block state explicitly to the fallback consumer. Fixes#1871
* Expand testmod to also test item models
* Also fix fallback consumer ignoring material for items
* Slight changes
* Introduce new interface for the expanded fallback consumer
* Add javadoc to ModelHelper
* Add block appearance API
* Add class javadoc for FabricBlock and FabricBlockState
* Address reviews
* Remove OverrideOnly from getAppearance
* Fix javadoc issues
The following classes have been made final and unconstructible:
- All convention tags classes
- `FluidVariantAttributes`
- `FluidVariantRendering`
The following classes have been made unconstructible:
- `BiomeModifications`
- `ClientEntityEvents`
- `ClientTickEvents`
- `LootTableEvents`
- `FabricDefaultAttributeRegistry`
- `MinecartComparatorLogicRegistry`
- `StorageUtil`
The following classes have been explicitly marked as final. Note that actually extending such class has always been impossible due to missing public constructor:
- `VillagerInteractionRegistries`
- `VillagerPlantableRegistry`
- `ModelHelper`
- `StoragePreconditions`
While the first two are technically breaking changes, there is no actual or observed usage for any of those.
A common source of crashes on modded Minecraft servers comes from modders accidently calling client only code from the client, this PR is another large step towards elimitating that.
This PR has been months in the making and years in the planning, requiring major changes to Loom & Loader. In recent Minecraft versions Mojang has made it easier than ever to cleanly split the jar, going against the status-quo of merging the client and server into one jar.
From the start we have designed Fabric to have a very clear split between client and common (client & server) code. Fabric has always encoraged keeping client only code seprate from the server, this can be seen at a fundamental level with the entrypoints in Loader. Fabric API's have all been designed with this mind.
This PR provides a compile safety net around Fabric API using client only code on the server. Even though there are almost 400 changed files, minimal changes beyond moving the files were required to achieve this in Fabric API, thanks to the effort of all contributors in the past.
These changes should not affect modders or players in anyway, a single "universal" jar is still produced. Im happy to awnswer any questions.
