KAIZO / FIELD NOTESperformance

Audit FiveM Collision Meshes Without Breaking Gameplay

A repeatable collision audit for finding excessive geometry, bad boundaries and gameplay failures in streamed FiveM assets.

Audit FiveM Collision Meshes Without Breaking GameplayKAIZO Team
Editorial cover image.

Collision optimization is not a contest to produce the smallest possible .ybn file. A collision resource must remain accurate enough for vehicles, players, projectiles and scripted interactions while avoiding geometric detail that contributes nothing to gameplay. The useful question is measurable: does the asset preserve required behavior under representative player load without introducing repeatable frame-time spikes, collision gaps or unnecessary streaming work?

Urban environment used to illustrate a FiveM collision audit route

Define the collision contract first

Before opening a model editor, define what must collide. Structural floors, stairs, walls, counters used as cover, vehicle barriers and accessible rooftops normally affect gameplay. Ceiling trim, cables, tiny handles, decorative grooves and unreachable roof equipment usually do not need matching physical detail. Record exceptions explicitly. If a prop supports an interaction target or blocks a firing angle, its collision is functional even when the geometry looks decorative.

Build one repeatable test route

  1. Start outside the asset's streaming area, approach at normal road speed and stop at the primary entrance.
  1. Walk every accessible floor, staircase, ramp and doorway without changing the route between builds.
  1. Drive a standard vehicle against curbs, gates, walls and parking stops at controlled low speed.
  1. Cross the outer boundary from at least four directions and repeat one approach at high speed.
  1. Finish with the busiest expected roleplay setup, including representative vehicles, players and scripted props.

Keep the client build, graphics settings, spawn position, weather, time and enabled resources fixed. Capture at least three passes after an initial warm-up pass. The first approach may include cold streaming behavior that is still worth recording, but it should not be averaged blindly with warm passes. Label both conditions so a later edit cannot appear successful merely because the cache state changed.

Separate script cost from collision symptoms

Use resmon 1 to watch resource CPU time while running the route, but do not treat a quiet resource row as proof that its streamed assets are cheap. Resource Monitor is strongest for script activity. Collision, rendering and streaming problems can appear as client frame-time instability, delayed physical surfaces or visible transitions without a matching Lua resource spike. Record resmon alongside frame behavior and observed asset failures instead of forcing every symptom into one metric.

A collision audit passes only when the numbers remain stable and the physical behavior remains correct. Either result on its own is incomplete.

Log route checkpoints instead of relying on memory

local checkpoints = {}

RegisterCommand("colmark", function(_, args)
    local ped = PlayerPedId()
    local pos = GetEntityCoords(ped)
    local label = table.concat(args, " ")

    checkpoints[#checkpoints + 1] = {
        label = label ~= "" and label or ("point" .. #checkpoints + 1),
        time = GetGameTimer(),
        x = pos.x,
        y = pos.y,
        z = pos.z
    }

    print(json.encode(checkpoints[#checkpoints]))
end, false)

The command does not measure collision cost directly. It creates reproducible evidence. Mark the moment a vehicle hits an invisible wall, a player falls through a seam or a surface appears late. Store the coordinate, direction of travel, build identifier and whether the pass was cold or warm. A defect that can be reproduced at a coordinate is substantially easier to isolate than a report saying the interior felt unstable.

Inspect the collision shape, not the render mesh

  • Replace curved architectural detail with the fewest convex or planar shapes that preserve movement and vehicle contact.
  • Remove collision from objects that cannot be reached, targeted or used as cover.
  • Check adjacent floor pieces for gaps, overlapping planes and height changes that can catch wheels or player capsules.
  • Avoid collision extending beyond visible walls, doors or shutters unless the blocked area is intentional.
  • Test thin surfaces from both directions; a wall that works from inside may still permit entry from outside.
  • Review material assignments when footsteps, traction or projectile behavior depend on the collision material.

Do not automatically derive final collision from the highest-detail render mesh. Render geometry contains bevels, recesses and small repeated features intended for lighting and silhouette. Copying them into collision can create dense surfaces and snag points while providing no useful physical fidelity. Build collision around gameplay planes: where a tire rests, where a player walks, where a projectile should stop and where the camera must not pass.


Test collision and LOD transitions together

A collision defect can be mistaken for an LOD problem when the visible model changes before or after the physical boundary behaves as expected. Approach the asset slowly while watching major silhouettes such as walls, ramps and rooflines. Then repeat at driving speed. Record visible swaps, physical impacts and load delays as separate timestamps. The collision should support the same gameplay footprint represented by the visible state, even when their internal geometry is intentionally different.

Use acceptance criteria that can fail

  • Zero fall-through events across three warm route passes and one cold pass.
  • Zero invisible barriers on documented player and vehicle paths.
  • No repeatable wheel snag on flat traversal surfaces at the recorded test speed.
  • No collision boundary extending into an adjacent road, doorway or unrelated interior.
  • No new sustained script-time regression during the representative roleplay scenario.
  • Every observed spike or late load has a coordinate, timestamp and reproduction status.

Compare one controlled change at a time: original build against simplified floor collision, then simplified walls, then removed decorative shapes. Preserve each build and its measurements. If several collision files, texture changes and scripts are replaced together, the test may reveal improvement without identifying the cause. That prevents informed rollback and makes the next asset harder to optimize.

The final deliverable should include more than edited geometry. Package the resource with its route, checkpoints, known exceptions and before-versus-after observations. If a collision remains detailed because it supports cover, vehicle alignment or a scripted interaction, document that decision. Advanced optimization is not indiscriminate deletion; it is removing cost while proving that the intended FiveM roleplay behavior still works.

Keep the ideas going

More from the journal.

View all guides