Rig Backends, Display Parts, Wheels, and ModelEngine

Vehicle MC separates vehicle physics from vehicle rendering.

That split is one of the plugin's biggest strengths:

• Vehicle MC stays in charge of movement, collision, seats, and interaction
• the rig backend decides how the vehicle is visually drawn

If the vehicle drives correctly but looks wrong, this is the layer to fix.

The three rig layers

Vehicle MC rigs are easiest to understand as three separate layers:

1. the physics authority root
2. the visual rig backend
3. the hitbox and interaction layer

The visual rig is not the same thing as the movement authority. That is why you can retune rendering without rewriting the entire vehicle controller.

Backend choices

Vehicle MC supports three visual backends:

• DISPLAY
• ARMOR_STAND
• MODELENGINE

Global default:

entities:
  rig:
    backend: DISPLAY

Per-vehicle override:

rig:
  backend: MODELENGINE

Public rule:

• use DISPLAY for the main modern path
• keep ARMOR_STAND for legacy parity or special fallback cases
• use MODELENGINE when you want external model and animation playback, while Vehicle MC still owns physics

Display backend basics

The Display backend is where most modern Vehicle MC setups should start.

Important global knobs:

entities:
  rig:
    display:
      baseScale: 0.625
      viewRange: 128.0
      teleportDurationTicks: 3
      interpolationDurationTicks: 3
      interpolationDelayTicks: 0
      teleportEveryTick: true
      offsetsFollowTilt: true

What these do:

• baseScale is the first thing to check if all rigs look too big or too small
• viewRange controls how far away rigs stay visible
• teleport and interpolation values affect smoothness
• offsetsFollowTilt decides whether parts move with pitch and roll or mainly stay yaw-driven

rig.root

rig.root defines the main carrier entity and visual root item.

Common fields:

rig:
  root:
    entity: ARMOR_STAND
    equipment:
      helmet: minecraft:diamond_hoe{Damage:10}
    options:
      marker: false
      invisible: true
      gravity: false
      small: false

This is where you decide:

• what the base rig model is
• whether the carrier is visible
• whether the carrier uses small or full-size options

offset on the root is especially useful for fixing a model that sits too low or too high visually without moving the true vehicle authority.

Seat entities

rig.seatEntities controls the supporting entities used for seats.

That is different from seats[item] in the vehicle data:

• seats[item] describes who can sit where
• rig.seatEntities describes how those seat carriers are represented

Keep the seat-entity layer consistent unless you have a strong reason to change it.

Anchors

Anchors are named attachment points for other systems.

rig:
  anchors:
    exhaust_left:
      offset: [0.0, 0.2, -1.2]
      rotation: [0.0, 0.0, 0.0]

Good uses for anchors:

• exhaust points
• muzzle points
• rotor centers
• hose origins
• custom FX attachment points

Anchors let you keep those positions reusable instead of scattering hard-coded offsets everywhere.

Parts

rig.parts[item] is where most visible sub-objects live.

Each part can define:

• id
• model item
• local offset
• local rotation
• per-part options
• scale

That means you can build a readable visual hierarchy instead of one giant fused model description.

Part animation

Parts can also carry animation instructions.

Example:

animation:
  type: ROTATE_Y
  when: DRIVER
  idleDegPerTick: 0.0
  activeDegPerTick: 0.0
  steerMaxDeg: 35.0
  smoothing: 0.35
  pivot: SELF

This is useful for:

• steering visuals
• spinning details
• driver-only animated behavior
• lightweight visual feedback without external animation middleware

Two important real-world uses already appear in the current source examples:

• a dirt bike handlebar part that follows steering input
• a helicopter rotor part that spins faster when a driver is actively flying

Example steering part:

- id: handlebars
  steeringYaw:
    enabled: true
    maxDeg: 19.0
    smoothing: 0.35
    invert: true
    pivot: SELF

Example rotor part:

- id: rotor_center
  tiltPosFactor: 0.9
  animation:
    type: ROTATE_Y
    when: DRIVER
    idleDegPerTick: 8.0
    activeDegPerTick: 20.0
    activeSpeedThreshold: 0.05

Interpretation:

• steeringYaw is for a normal rig part that should visibly follow input
• tiltPosFactor is useful when a large part such as a rotor should not fully translate with pitch and roll
• animation.when: DRIVER is a clean way to tie a visual state to occupancy without inventing a full ModelEngine state machine

Wheels

rig.wheels[item] is the dedicated wheel system, not just another part list.

Example:

rig:
  wheels:
    - partId: front_left
      radius: 0.38
      spinEnabled: true
      spinAxis: X
      steer:
        enabled: true
        maxDeg: 19.0
        smoothing: 0.35

Wheel config handles:

• rolling spin
• steering yaw
• suspension probes
• axle behavior
• speed-based blur or swap behavior

If your wheels look wrong, do not try to fix that only through generic part offsets.

If you want a practical wheel-first walkthrough for pivots, suspension, axle roll, and hybrid ModelEngine bodies, continue into native Wheels, Suspension, Axles, and Hybrid ModelEngine Rigs.

If you want the concrete source-backed examples for:

• dirt bike steering assemblies
• four-wheel native jeeps
• hybrid ModelEngine bodies
• tank-style ModelEngine rigs
• helicopters and rotor parts

continue into advanced Rig Examples: Dirt Bikes, Jeeps, Tanks, Helicopters, and Input-Driven Parts.

pivotOffset

pivotOffset is the important fix when a wheel or axle appears to orbit the wrong center.

Use it when:

• the wheel model was exported off-center
• steering looks correct but rotation looks wrong
• the whole wheel seems to circle an invisible point

This is one of the most important wheel-specific knobs in the plugin.

Suspension and axle behavior

Vehicle MC also supports visual suspension and axle roll behavior.

These are useful when:

• the vehicle should react visibly to uneven terrain
• a solid axle should tilt between left and right wheel probes
• ground contact needs to read better without rewriting physics

For basic setups, keep these modest. Overdoing them can make a clean rig look unstable.

ModelEngine backend

ModelEngine is optional, but the backend is already clearly defined.

Example:

rig:
  backend: MODELENGINE
  modelEngine:
    enabled: true
    modelId: "tank7"
    hideBaseEntity: true
    overrideHitbox: false
    applyPitchToRoot: true
    states:
      idle:
        animation: "idle"
        lerpInTicks: 5
        lerpOutTicks: 5
      drive:
        animation: "walk"
        lerpInTicks: 3
        lerpOutTicks: 3
      turn_left:
        animation: "sprint"
        overlay: true

Important public point:

• Vehicle MC still owns the authoritative physics pose
• ModelEngine is the body-render and animation layer
• hybrid setups are often the best answer when you need premium body art plus native wheel behavior

If a ModelEngine rig is selecting the wrong state or following the wrong pose, continue into rig Debug Commands, Pivot Tools, and Live Diagnostics after this page.

That makes it a visual backend, not a replacement for the Vehicle MC runtime.

Canonical ModelEngine state keys

Vehicle MC already has a clear state vocabulary:

• base states: idle, drive, reverse, airborne
• overlay states: turn_left, turn_right

Use those state names consistently so your models and your config stay readable together.

Suggested order

1. Get the vehicle driving correctly first.
2. Choose one visual backend per vehicle family.
3. Fix root scale and offset before tuning individual parts.
4. Add anchors before hard-coding lots of repeated FX offsets.
5. Tune wheels as wheels, not as generic decorative parts.
6. Use ModelEngine when you need a richer external animation path, not just because the option exists.

Related pages

• runtime Modules, Physics, and Safety
• vehicle Bases, Controllers, Stats, Seats, and Hitboxes
• native Wheels, Suspension, Axles, and Hybrid ModelEngine Rigs
• advanced Rig Examples: Dirt Bikes, Jeeps, Tanks, Helicopters, and Input-Driven Parts
• surfaces, FX, and Terrain Response