Bone Behaviors
In Model Engine, it is possible to use specific prefixes (called Tags) in the bone name or specific bone ids in order to give bones special behaviors.
Please note that the id of each bone is the name of the bone without the Tag. For instance, if we had a bone called
phead_playerhead
phead_playerheadwould be the Complete name of the bonephead_would be its Tagplayerheadwould be its Id
There are several types of Tags, and each of them brings about a different behavior.
The following is a list of all of them:
General tags
Head
**Tag: h_**
When mobs look around, the head turns before the rest of the body does. You can do this in Model Engine too!
All bones rotate like a body by default. If you want a bone to rotate like a head, you need to use the h_ Tag. Model
Engine will interpret this as a head bone, remove the h_ in the resource pack, and move this part like a normal head.
A model can have multiple head bones so you can create models with multiple heads. Head bone can also have child bones,
but all child bones would also need the h_ flag in front to act like a head.
Inherited Head
**Tag: hi_**
Same as the Head behavior, but with this tag every child bone will also inherit the
head behavior without the need of using the h_ tag
Head Parameters
**Tag: h[...]_ or hi[...]_**
Head bones can be limited and slowed down with parameters in square brackets. For example, h[yaw=60;pitch=30;speed=10]_head
turns at most 60 degrees to each side and 30 degrees up and down, by at most 10 degrees per tick.
| Parameter | Description |
|---|---|
| yaw | Turns at most this many degrees to the left and to the right |
| pitch | Turns at most this many degrees up and down |
| minyaw | The furthest the head turns to the left, in degrees (negative) |
| maxyaw | The furthest the head turns to the right, in degrees |
| minpitch | The furthest the head looks up, in degrees (negative) |
| maxpitch | The furthest the head looks down, in degrees |
| speed | The most the head turns per tick, in degrees. Not set means instant |
A plain h_ or hi_ head behaves exactly as before. The limits and speed can be changed at runtime with
HeadConfig, and HeadTarget makes the head look at an
entity or a location.
Mount
**Id: mount**
If you want your mob to be controllable, you can set a specific location to mount on.
Create an empty bone named mount and place it wherever you like. The mount point can be animated, and if it is
parented to another bone, it will follow the parent bone. Otherwise, it will follow the base mob.
Note: In your mob's MythicMob code you'll want to add
drive=trueinto your model spawning mechanic to enable mounting, then use Model Engine'smountmodelmechanic instead of MythicMob'smountmechanic for mounting the model. (Don't worry about this part until you get to coding!)
Seat
Tag: p_
You can create multiple passenger seats for other players/mobs to mount on. Unlike the driver seat, they cannot control
the mount, and can have more than one point.
Create an empty bone and place it wherever you like, then add p_ in front of the bone name. The passenger point can be
animated, and if it is parented to another bone, it will follow the parent bone. Otherwise, it will follow the base mob.
Note: Same as the driver seat, you should add
ride=truein your model spawning mechanic, and usemountmodel{driver=false}to mount your entity.
Item
Sometimes you would like items to be synced in your model.
You can do so by creating special, cube-less bones with a specific tag written before the actual bone name. Depending on
the tag used, the item that will be displayed will be treated as if it was equipped in the corresponding slot.
Head Display
Tag: ih_
Main Hand Display
Tag: ir_
Offhand Display
Tag: il_
You can create as many item bones as you want. You can then equip items there via
the SetItemModel mechanic.
Ghost
Tag: g_
Normal ghost bones (bones without cubes inside) are only used internally and do not spawn armor stands. Marking them as
rendered would cause them to spawn an entity, but will not display any models
You can set the model of a rendered ghost bone using the ChangePart mechanic
Nametag
Tag: tag_
To display the name of the model, or add an HP bar on top, you would need a name tag bone.
Each model can have as many name tag bones as you need. They don't need to be centered, and they can have animations.
To create a name tag bone, add tag_ in front of the bone name.
Once you get to coding, if you want to use a specific tag bone as the display bone of your model, you can use the model mechanic's
nametagattribute to specify one.
Example: if you had a bone calledtag_yournametag, your would need to usemodel{mid=your_model;nametag=yournametag}
Leash
**Tag: l_**
By making a cube-less bone and using a special tag before the bone name, you can mark a bone as the attachment point
when being leashed.
You can create as many bones as you want. You can leash the model using the Leash or LeashSelf mechanics
Inverse Kinematics
Segment
**Tag: seg_**
Segment bone is a special type of bone that is animated procedurally, following the parent bone using the least amount of movement required through rotation or position. This is very useful when creating long, dynamic models such as worms.
This bone tag would mark the bone as a child pivot of the model, where child bones will originate from the new pivot instead of the base pivot. If your segments are long enough that some bones will not move in world space when the base entity moves, use this behavior. Otherwise, check the Tail behavior.
As of R4.0.7, segment tag can only be used on cube-less bones. The pivot point of the bone should also be placed at the back. The bones can be further configured by using the Segment mechanic.
The seg_ tag places the segment's pivot at the back of the bone. If you want the pivot at the front instead, use the
segf_ tag.
Check out this segment demo as reference for how to set up the bones and use the segment mechanic.
Tail
**Tag: tl_**
Tail bone visually works exactly the same as segment bone, however instead of creating a separate pivot for display entities, the bones would use the base pivot. If your tail bones move a lot and generally stay around the base model, use this behavior. Otherwise, check the Segment behavior.
As of R4.0.7, tail tag can only be used on cube-less bones. The pivot point of the bone should also be placed at the back. The bones can be further configured by using the Segment mechanic.
The tl_ tag places the tail's pivot at the back of the bone. If you want the pivot at the front instead, use the
tlf_ tag.
Blockbench IK
Model Engine solves Blockbench's (5.2+) inverse kinematics in game. Add a null object, set its IK Target to the end bone of the chain (a bone or a locator), and optionally set an IK Source and an IK Pole. Animate the null object and the chain follows it.
- A chain is active while a playing animation has position keyframes for its null object, which is how Blockbench exports
it. Use IK with
alwaysactive=trueto keep it on. - IKTarget makes the chain reach for an entity or a location instead.
- "Lock IK Target Rotation" is supported.
- The null object and the pole cannot be inside the chain. Such chains are skipped with a warning.
- Chains can also be created at runtime with the IKChain mechanic.
Joint Limits
**Tag: ik[...]_**
Limits how far a joint of an IK chain can rotate, in Blockbench degrees. For example, ik[minx=0;maxx=140]_elbow lets an
elbow bend one way only. The parameters are minx, maxx, miny, maxy, minz and maxz; axes that are not set are
free. The tag needs the square brackets, so existing bones named ik_... are not affected. Limits can be changed at
runtime with the IK mechanic.
Physics
**Tag: jig_ or jig[...]_**
Physics bones swing with inertia when the model moves, turns or is animated: ears, antennas, tails, ropes, chains.
A single jig_ bone springs around its animated pose. jig_ bones placed inside each other form one chain that swings as
a whole, like a rope or a tail. Inner links copy every setting they do not set themselves from the link above them.
| Parameter | Description | Default |
|---|---|---|
| stiff | How fast the bone returns to its animated pose, from 0.01 to 1. Low values make loose ropes |
0.15 |
| damp | How fast the swinging dies down, from 0.01 to 1 |
0.25 |
| grav | Gravity in blocks per second squared. Ropes look right around 20 |
0 |
| angle | How far the bone can swing away from its animated pose, in degrees, from 0 to 180. One value limits the swing in every direction. Three values x,y,z limit it around each of the bone's own axes separately, for example angle=10,20,10 |
45 |
| repeat | How many links this one bone becomes, see "Repeating a link" below. Inner links do not copy it | 1 |
Examples:
jig_earmakes a springy ear.jig[stiff=0.01;damp=0.1;grav=20;angle=180]_rope1>jig_rope2>jig_rope3makes a hanging rope.jig[angle=10,20,10]_tailswings up to 20 degrees around its Y axis and up to 10 degrees around X and Z. For a bone that hangs down, X swings it forward and back, Z swings it to the sides and Y only twists it.
Setting up links: put the pivot of each link where it hangs from, usually the top of the link. A link points at the
pivot of the next link, and the last link points at the center of its cubes. That center is also the point that gets
tied. To tie a rope by its very end, finish the chain with an empty jig_ group at the end and tie that bone. A link
whose pivot sits in the center of its cubes has nothing to swing around and does not move.
Repeating a link: model one link and let Model Engine copy it. jig[repeat=16]_rope_segment turns one link into 16,
each copy hanging from the end of the one before. Anything inside the link, like an empty jig_rope_end group with a hook,
moves to the last copy, so iktarget{p=rope_end} always ties the real end. A copy hangs at the pivot of the link's first
child bone, or at twice the distance to the center of its cubes when it has none. The copies reuse the link's model, so the
resource pack does not grow, but each copy is still one more display entity. They are named rope_segment_2,
rope_segment_3 and so on, and the count can be changed live with ik{p=rope_segment;repeatjig=24}. Repeat does not work on
bones of a Blockbench IK chain.
By default a new count is applied at the far end of the chain, all at once. With repeatjigat=start, for example
ik{p=rope_segment;repeatjig=4;repeatjigat=start}, links are added or removed one per tick where the chain hangs from,
so the far end stays in place and the rope reels in or out like a winch. The count a model spawns or loads with is always
applied at once.
Tying the end of a chain:
- To an entity or a location: use IKTarget on the last link, for example
iktarget{p=rope_end;y=1.2} @trigger. To tie it to a bone of another mob's model, even while it animates, add the bone:iktarget{p=rope_end;tp=arm} @target. The rope sags between both ends. When the target is farther away than the rope is long, the rope goes straight and stops short. - To another part of the model: make a Blockbench IK chain out of
jigbones and place its null object where the end should be tied, for example on the second post of a rope bridge. Such chains are always tied to their null object.
Notes:
- Settings can be changed live with IK and are saved with the model. JiggleImpulse kicks the bones.
- Physics bones do not collide with blocks, never stretch, and never pull the entity they are tied to.
- Lower links follow the links above them but do not pull them, unless the end of the chain is tied.
- Every link swings around the link above it, so swinging adds up along a chain. A long chain that should keep its
modeled shape, like a cord wrapped around a body, can swing harder and harder toward its end with the default
settings. For such chains set
damphigher thanstiff, for examplejig[stiff=0.8;damp=0.9;angle=8], and only make the part that hangs free a physics chain. - Physics bones ignore
ik[...]joint limits, the IK pole and global rotation keyframes. Useangleto limit the swing. - A bone with more than one
jigchild ends the chain there, and each child starts its own chain. - IK mechanics with no
partidaffect every IK bone of the model, physics bones included.
Hitbox Tags
Model Engine allows you to add different kinds of sub-hitboxes to the model. Depending on the type, the specific functionalities will vary. The following is a list of all possible sub-hitbox you can employ in your model.
Axis Aligned Bounding Box
**Tag: b_**
They are like the normal hitbox, but cannot collide with blocks and take suffocation damage. These hitboxes would act
like bones and follow their parent, however, they will not rotate with the parent bone, and they must still be
square-based.
Create a sub-hitbox by adding a bone starting with b_ and a cube inside. The size of the cube is the hitbox size. Same
as the normal hitbox, it must obey Minecraft's hitbox limit, and X and Z values must be the same.
Oriented Bounding Box
**Tag: ob_**
This type of bounding box is, essentially, an Axis Aligned Bounding Box with the ability to be rotated. These hitboxes
would act the same as normal sub-hitboxes, but they can rotate with the parent bone, and they can be any size.
Similar to a normal sub-hitbox, create a bone with a cube inside, but the bone name starts with ob_, and unlike normal
hitboxes, your cube can be any size you want, meaning the X and Z values can be different.
Player Limbs Tags
Player limb tags allow a model to use player skin and limb. You can recreate the entire player model, only use parts, or
have multiple of the same parts.
To create a player limb bone, create a bone that starts with one of the tags listed below. Any cubes inside these bones
will be ignored automatically.
You can apply a skin to the bone using the ModelPlayerSkin Mechanic
If you need some guide on how to create these bones, check out this demo player model (right click and save link as).
This is a modified version of Bradleyq's Stable Player Display. It requires core shader, works on vanilla, optifine and sodium, but does not work when modded shaders are used.
Massive thanks to them for sharing this technology. For more information, check out their repository.
| Tag | Player Part |
|---|---|
| phead_ | Head |
| prarm_ | Right Arm |
| plarm_ | Left Arm |
| pbody_ | Body |
| prleg_ | Right Leg |
| plleg_ | Left leg |
Custom User Limbs
**Tag: limb[type=X]**
limb is a separate, more granular player-limb system. Instead of the six fixed parts above, it renders a single limb
region of the player skin chosen by the required type parameter, which lets you split a model into finer pieces such as
an upper and lower torso, or upper and lower arms and legs. As with the tags above, any cubes inside the bone are ignored
unless you set cube=true, and you apply a skin with the ModelPlayerSkin mechanic.
The available type values are:
| Type | Skin Region |
|---|---|
| head | Head |
| chest | Upper torso |
| body | Lower torso |
| right_arm | Right upper arm |
| right_forearm | Right lower arm |
| left_arm | Left upper arm |
| left_forearm | Left lower arm |
| right_leg | Right upper leg |
| right_foreleg | Right lower leg |
| left_leg | Left upper leg |
| left_foreleg | Left lower leg |
For example, a bone named limb[type=right_forearm]_myarm renders the lower half of the player's right arm.
Cube Size
**Tag: limb[type=X;cube=true]**
By default a limb always has the vanilla player proportions. With cube=true, the limb takes its size and position from
the cube inside the bone instead, so limbs can be longer, thicker or smaller than a player's. For example,
limb[type=right_arm;cube=true]_myarm. The skin region of the chosen type is stretched over the cube.
- Use one cube per bone. Cubes whose name starts with
hat_are skipped because the outer skin layer is drawn automatically. - The cube's size in Blockbench is used. Its inflate and rotation are ignored.
- Slim (Alex) skins make arm limbs 3/4 as wide, like vanilla, keeping the side that faces the body in place.
A plain limb[type=X] bone behaves exactly as before.