Skip to content

What does real-world scale mean for game assets?

It means the mesh is authored and exported at true size in metres, so a 1.55 m desk imports as 1.55 m with no scale factor applied. It matters because physics, lighting, navmesh, character proportion and every other prop in your level are all calibrated to metres, and one mis-scaled asset breaks all of them at once.

It means that if the desk is 1.55 metres wide in the real world, it is 1.55 units wide in the file — and when you drag it into Unity or Unreal, it is 1.55 metres in the level with no import scale factor, no 0.01, and no “why is this chair the size of a building”.

That sounds trivial. It is the single most common reason an asset pack costs you an afternoon.

What breaks when scale is wrong

Everything in a modern engine is calibrated to metres, and it is all calibrated to the same metres:

  • Physics. Gravity is 9.81 m/s². A ten-times-too-large crate falls like a feather and a ten-times-too-small one falls like a stone, and no amount of tweaking the rigidbody mass makes it look right.
  • Lighting. Physical light units, attenuation radii and exposure all assume real distances. A room built at the wrong scale lights wrong and no light setting fixes it, because the falloff is happening over the wrong number of metres.
  • Navmesh and character metrics. Step height, crouch clearance, doorway width and agent radius are all in metres. A desk at 1.2× makes a doorway that the character cannot path through for reasons that look like a navmesh bug.
  • Everything else in the level. The moment you mix two packs at two scales, you are hand-correcting forever, and every correction is a number somebody has to remember.

Fixing scale at import by typing a factor is not a fix. It is a note you now have to attach to that asset for the rest of the project, and it will not survive somebody re-importing the file.

The three things that actually have to be true

Real-world scale is one of three properties that decide whether an asset drops in cleanly. All three have to hold:

1. True size in metres. The mesh is authored at real dimensions. Publish them: our pack page lists the size of every asset, so you can check a bookcase is 1.85 m tall before you buy rather than after.

2. Transforms applied. Scale is 1,1,1 and rotation is 0,0,0 on the object and its data. An object that looks right because it carries a 0.01 scale on the transform will misbehave the first time something reads its local bounds, parents to it, or instances it — and physics will read the unscaled mesh underneath.

3. Pivot at the bottom centre. The origin sits on the floor, in the middle of the footprint. Then placing a prop is setting a position, snapping to a surface works, rotating spins it around its own axis instead of swinging it across the room, and dropping it onto terrain lands it on the terrain. A pivot at the mesh centre means every placement is a two-step fiddle.

Wall-mounted and ceiling-mounted pieces are the sensible exception: a wall clock wants its pivot on the mounting face, not on the floor below it.

How to check a pack before you commit

  • Import one asset and read its dimensions in the engine’s inspector. If a desk reports 155 units, the pack is in centimetres and you will be fighting it.
  • Check the transform. Scale should read 1. If the importer had to write 0.01, the pack does not have transforms applied.
  • Drop a prop at the origin and look at where the origin is. If the desk is half underground, the pivot is at the centre.
  • Put a standard capsule next to it. A human capsule is about 1.8 m; if the desk chair comes up to its chest, something is wrong.

Those four checks take two minutes and tell you more about how much work a pack will be than any screenshot on the store page.

Updated 13 August 2026 · LeftPunch Studio

Related

We write these while building. The pack they come from — a 1960s office set of 110 props plus a 30-module architecture kit — is in production and every prop's audit verdict is published, including the ones that failed.

See the pack