BoneTown

BoneTown

An alternate entity rendering pipeline for Minecraft Forge 1.15.2.

Features

• Skeletal Animations
• Supports standard 3d modeler output instead of the boxy MC format.
• On GPU Animation and Vertex calculations
• Modern GLSL Shader pipeline (no fixed function)
• Modern layer-based animation blending pipeline
• Treat animations as a resource (mods can introduce animations for
  other mod's entities)
• Extensible Network Protocol for automatically syncing animation state

Supported Formats

Internally we use our own BoneTown Model Format (.bonemf) that is designed
for simplicity and to expose exactly what we need for rendering in Minecraft.
Converters from popular model formats to .bonemf are necessary at the moment
we support the following model formats:

• FBX

Why Use Bonetown?

If you are a modder wanting to develop entities using industry standard software
and provide more detailed animations and models without a performance cost, you should
consider depending on BoneTown.

The basic Minecraft rendering pipeline performs all animation and rendering
calculations on the cpu and submits them every frame. This works fine for most
of the low vertex count default models, but many Minecraft mods introduce significantly
more detailed models. This approach to rendering breaks down both with complexity
of model and complexity of animation.

BoneTown performs nearly all calculations directly on the GPU. Model geometry is only
uploaded to the graphics card once instead of every frame and following that only the
information that changes transfers every frame: lighting information, final positions, and
animation bone data.

In addition to this, animation data can be re-used and shared between mods, opening up
the ability for modders to mod each other's modded entities and introduce new behaviors
significantly more efficiently than in the current Java MC environment.

Downsides of this Approach

There are some downsides to the approach we are taking:

No Custom Forge Armors for these entities

While our biped model supports the default vanilla minecraft biped armor models, it is
not possible to similarly support custom forge armor models. Our biped introduces an additional
joint at the elbow and knees, and really the armor models also need to be associated with skeletal
data to animate them using the approach we use. Our biped model is a recreation of the vanilla biped,
BoneTown is not capable of using the original Minecraft assets, new assets need to be authored to use
with this system.

On the other hand, in the BoneTown system it is possible to register new models for
minecraft armors on a per-model, per-material basis, and to register armor models
for non-biped characters provided they use the same textures. This opens
up entirely new possibilities for for custom armor models and armor integration
in other entities.

No Optifine

BoneTown introduces a new rendering flow that only partially piggybacks off existing
Minecraft rendering. I have no idea what that would mean for Optifine, and it is
possible they could be made to work together, but I'm not really considering it
a priority. Optifine is also closed source so its very hard to look into such
problems.

The Approach

There are 3 key parts to the BoneTown library that differ significantly from vanilla
Minecraft:

• The model format that stores data on disk
• The rendering code that submits the data to GPU
• The representation of animations on server and client and their syncing

BoneTown Model Format

BoneTown loads models and animations from .bonemf files, which are a cbored representation
of geometry and animation data. These files have a format
inspired by the Autodesk FBX format, but significantly reduced in scope to fit the
needs of Minecraft. No material information is preserved for the geometry, instead
that information is controlled by the EntityRenderer as in vanilla. Typically right now
you would convert your FBX files to .bonemf using the FBXToBoneMF command line utility,
you can find a windows build of this software here
or you can get the source and try to compile for other
platforms. Please consider contributing any platform upgrades to master!

Technical Details

• A max of 100 joints (bones) in the model.
• 4 joint (bone) weights per vertex.
• Only 1 skeleton in file

At the moment the software has only been tested with models produced with Maya LT,
as that is what I use. However, if you use 3dsmax or Blender and you experience
issues please contact me and we'll work them out.

Rendering

BoneTown introduces a new rendering pipeline that submits the bulk of the model
data only a single time, and then uploads the minimal changes necessary
to draw that model at a specific place on screen. This is in contrast to
Minecraft's default entity rendering pipeline which transforms the models
into world space and applies animations on the cpu and then sends the final
geometry to the GPU every frame.

Data is submitted to the programmable pipeline instead of the legacy Fixed
Function pipeline. Model data is submitted separately as arrays of primitives
instead of in an interleaved struct format. Lighting, Overlay,
World Space Transform, and Animation data that is normally copied out to
each vertex is instead submitted a single time as uniform values.

The built in shaders included in BoneTown are designed to emulate the legacy
OpenGL Fixed Function pipeline state that Minecraft uses almost exactly. However,
the usage of shaders in BoneTown opens up exciting possibilities for content
authors who are interested in more advanced rendering for their entities.

Animations

Unlike vanilla, animation data is held on an Entity in BoneTown. All entities wanting to
use BoneTown's renderers should implement IBTAnimatedEntity. As part of this
your entity will need to hold an AnimationComponent. The AnimationComponent is responsible
for determining the actual position of the entities joints (bones) and syncing that data
with the relevant clients. This also enables server-side decisions such as spawning a projectile
at the position of a specific bone.

All adjustments of AnimationComponent state should be done using AnimationMessages through the
AnimationComponent::updateState function. Any changes made through this interface will be
automatically recorded, batched as one packet, and sent to the relevant clients.

For an example of the usage of this system see the implementation of TestZombieEntity.

Programming Guide

The best way to learn about these implementations is to take a look at the
com.chaosbuffalo.bonetown.init package to see how the new assets are registered,
com.chaosbuffalo.bonetown.client.render package to see the equivalents of vanilla classes like
RenderLayers and Renderers, and finally the com.chaosbuffalo.entity.TestZombieEntity is an
example of everything coming together in a concrete implementation of a biped.

Directory Structure

Like vanilla, BoneTown expects models (and animations to be located in specific folders),
the directory structure should look like:

Animations location: assets/modid/bonetown/animations

Models location: assets/modid/bonetown/models

So when you load a model with ResourceLocation("yourmod", "test_cube"), BoneTown will
look for a file called test_cube.bonemf at location:

assets/yourmod/bonetown/models/test_cube.bonemf

Registries

There are 4 new registries introduced to manage the additional assets BoneTown supports:

• Materials
• Models
• Additional Animations
• Armor Models

Materials

Materials are at base the shader files that will control how your entities are rendered. The
BTMaterialEntry is the base class for the registry object which will eventually be loaded as an
IBTMaterial implementor. There are 2 materials provided by default: BTMaterial, suitable for
static models, and AnimatedMaterial, suitable for models with skeletal animation.

Models

Similar to Materials, Models are made up of either static or animated data. The BTModel is the
base class for the registry and suitable for static data. There is also a BTAnimatedModel for the
animated data.

Additional Animations

Animations can be loaded separate from the models themselves. Typically you should place one
animation in each file, however if you do choose to use multiple the animations will be named
like yourmodid:animation_name_N where N is the index of that animation in the array. This way
it is possible for other mods to introduce additional animations for existing models.

Armor Models

Armor models can be introduced on a per-model basis, and overrides can be provided for specific
armor materials. If you are producing an entity that you want to be able to wear vanilla armor
you should create your model so that it uses the UVs for the default armor texture in Minecraft.
This should typically be the default armor added to your model. You can then introduce additional
models on a per-armor-material basis if your armor does not use the vanilla UV mapping or you want
additional geometry. Armor models should be rigged to the same skeleton as the model they are
intended for.

Похожие моды

Bee Productive Buffer: Fabric [Discontinued] Kuba’s Nether Ores The Hallow Enter The Beef Zone bruh StadiumCraft Nether Enhancement