• Forums

Navigation

  • Home
  • Style Guide
  • Getting Started
    • Home
    • Structuring Your Mod
    • Forge Update Checker
    • Dependency Management
    • Debug Profiler
  • Concepts
    • Sides
    • Resources
    • Registries
    • The Fingerprint Violation Event
    • Internationalization and localization
  • Blocks
    • Home
    • Intro to Blockstates
    • Interaction
  • Animation API
    • Intro to the Animation API
    • Armatures
    • Animation State Machines
    • Using the API
  • Tile Entities
    • Home
    • Special Renderer
  • Items
    • Home
    • Loot Tables
  • Models
    • Intro to Models
    • Model Files
    • Blockstates
      • Intro to Blockstate JSONs
      • Forge Blockstate JSON
    • Connecting Blocks and Items to Models
    • Coloring Textures
    • Item Property Overrides
    • Advanced Models
      • Intro to Advanced Models
      • IModel
      • IModelState and IModelPart
      • IBakedModel
      • Extended Blockstates
      • Perspective
      • ItemOverrideList
      • ICustomModelLoader
        • accepts
        • loadModel
        • onResourceManagerReload
  • Rendering
    • TileEntityItemStackRenderer
  • Events
    • Basic Usage
  • Networking
    • Home
    • Overview
    • SimpleImpl
    • Entities
  • Data Storage
    • Capabilities
    • World Saved Data
    • Extended Entity Properties
    • Config Annotations
  • Utilities
    • Recipes
    • OreDictionary
    • PermissionAPI
  • Effects
    • Sounds
  • Conventions
    • Versioning
    • Locations
    • Loading Stages
  • Contributing to Forge
    • Getting Started
    • PR Guidelines

ICustomModelLoader

Recall that when a model is requested for a ModelResourceLocation, every ICustomModelLoader is queried to find the one that volunteers to load the model from the ModelResourceLocation. In order to actually use a custom implementation of IModel, whether it be a full blown model format like OBJ models or a completely in-code model generator like ModelDynBucket, it must be done through an ICustomModelLoader. Even though it has “loader” in the name, there is no need for it to actually load anything; for in-code models like ModelDynBucket, the ICustomModelLoader will normally be a dummy that just instantiates the IModel without touching any files.

If multiple ICustomModelLoaders attempt to load the same ResourceLocation, the game will crash with a LoaderException. Therefore, care must be taken to keep the namespace of an ICustomModelLoader safe from being infringed upon. The Forge OBJ and B3D loaders do so by requiring that the namespace of a ResourceLocation be registered to them beforehand, and they only match ResourceLocations with the appropriate file extension.

In order for an ICustomModelLoader to actually be used, it must be registered with ModelLoaderRegistry.registerLoader.

accepts

Tests whether this ICustomModelLoader is willing to load the given ResourceLocation. Preferably, this should be based on the ResourceLocation alone and not on the file contents. If two ICustomModelLoaders accept the same ResourceLocation, a LoaderException is thrown. Therefore, care should be taken to make sure that the namespace of the ICustomModelLoader is unique enough to avoid collisions.

loadModel

Get the model for the given ResourceLocation. Note that it doesn’t need to “load” anything. For example, completely in-code models will simply instantiate the IModel class and totally ignore the file.

onResourceManagerReload

Called whenever the resource packs are (re)loaded. In this method, any caches the ICustomModelLoader keeps should be dumped. Following this, loadModel will be called again to reload all the IModels, so if the IModels kept some caches in themselves, they do not need to be cleared.

Built with MkDocs using a custom theme. Hosted by Read the Docs.
Enable Dark Theme