• 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
  • 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

Intro to Models

The model system is Minecraft’s way of giving blocks and items their shapes. Through the model system, blocks and items are mapped to their models, which define how they look. One of the main goals of the model system is to allow not only textures but the entire shape of a block/item to be changed by resource packs. Indeed, any mod that adds items or blocks also contains a mini-resource pack for their blocks and items.

In order to link code to models and textures on disk, there exists the class ResourceLocation. One may recognize them from the registry system; however, their original purpose was to identify files on disk; they just happened to be useful as unique identifiers as well. A ResourceLocation is a simple object composed of 2 Strings: a namespace and a path. When a ResourceLocation is represented as a plain string, it looks like namespace:path. When a ResourceLocation is created and a namespace isn’t explicitly given, the namespace defaults to minecraft. However, it is good practice to include the namespace anyway.

The namespace of a ResourceLocation in the model system represents a directory directly underneath assets/. Usually, the namespace is the same as the modid (e.g. in vanilla Minecraft the namespace is always minecraft). The path portion of a ResourceLocation represents a context-sensitive path to file underneath the namespace. What the path means and where exactly it points depends on what’s using it. For example, when refering to a model, the path is normally resolved under models, but when refering to a texture it’s under textures. Therefore, mod:file means assets/mod/models/file in one context but assets/mod/textures/file in another. When something is described as requiring a ResourceLocation, it will be defined what exactly the path means.

All strings related to the model system (especially ResourceLocations) should be in snake case (meaning_all_lowercase_and_underscore_separated_words_like_this). This is enforced since Minecraft 1.11.

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