FiveM LODs and Draw Distance: Fixing Buildings That Pop In, Vanish or Flicker at Range

You drop a custom apartment block into Mirror Park, spawn next to it, and it looks incredible. Then you walk to the end of the street, turn around, and there is a hole in the skyline. Not a blurry version of your building. Nothing. The fence you placed in front of it is still there, hovering over an empty lot, heroically guarding some air. Walk twenty metres back and the whole block snaps into existence like it was never gone. That is a FiveM LOD problem, and it is one of the few map issues where the values you need live in three separate files that are all allowed to disagree with each other.

So let’s go through what the LOD chain actually is, which distance value the game reads at runtime, why a number lifted off a Rockstar tower misbehaves on your build, and why raising every distance on the map costs you thirty frames.

What a LOD actually is in GTA V

A building in GTA V is not one model with a quality slider. It is a family of separate models: the HD model, an LOD model, then SLOD1 through SLOD4. Each has its own drawable, its own archetype in a .ytyp, and its own entity in a .ymap. HD has the door handles and the drainpipe. LOD is a cheap shell with the detail baked into the texture. SLOD is the vaguely building-shaped lump that makes up the city when you are on Mount Chiliad squinting at it.

The engine never simplifies anything at runtime. It swaps which member of that family is in the draw list, based on camera distance. Think of Russian dolls that all have to agree about who is holding whom, because any disagreement leaves a hole.

Rockstar splits the family across files too. HD entities sit in one ymap, LOD entities sit in another, and the HD ymap names the LOD ymap as its parent. Inside the ymap, every entity carries a lodLevel saying where it sits in that chain: LODTYPES_DEPTH_HD, LODTYPES_DEPTH_LOD, the SLOD tiers, and LODTYPES_DEPTH_ORPHANHD for anything with no parent at all. Most custom map problems turn out to be that last one wearing a trench coat.

lodDist and childLodDist: which number the game actually reads

In the .ytyp, the archetype has a lodDist and an hdTextureDist. That is the model’s default, the value an entity inherits when it gets placed. In the .ymap, the entity has its own lodDist, plus childLodDist, lodLevel, a parent reference and a child count. The entity’s value is what the game works from once the map loads, which is why editing the ytyp and seeing nothing change is such a popular way to spend an evening. Set both to the same number.

An entity’s lodDist is the maximum camera distance at which it draws. Its childLodDist is the distance at which its children stop drawing and it takes over from them. A correctly wired pair is a relay handover: the HD entity has a lodDist of 120, its LOD parent has a childLodDist of 120 and a lodDist of 500. Inside 120 metres you see the detailed model, from 120 to 500 the shell, and past that whatever SLOD covers the district.

hdTextureDist is a separate axis, and it explains the building that keeps its shape but turns to mush at medium range. Geometry and textures are tuned independently, so a low texture distance on a large model gives you a crisp silhouette with soup for cladding.

Why the value you copied off a Rockstar building doesn’t work

Culling measures against the entity’s bounding sphere, not its origin. The archetype carries bbMin, bbMax, bsCentre and bsRadius, and if that sphere is small or sitting off to one side, the engine measures from the wrong place. Merge geometry in Blender, export, forget to recalculate bounds, and you get a sixty metre tower carrying the bounding sphere of a phone box. It gets culled like a phone box too.

Entity scale in the ymap has the same trap. Scaling an entity does not touch the archetype’s bounds, so a building stretched to 1.5x is still distance-checked at its original size. Recalculate extents after any geometry or scale change, before touching a distance value.

Then there is the reason the copied number specifically fails: Rockstar’s 200 is tuned for a model that has somewhere to go at 201 metres, and yours usually does not. Their entity degrades into an LOD shell, yours deletes itself. Same number, opposite outcome.

The client’s Distance Scaling graphics setting also scales all of these distances, so a map can behave perfectly on your machine with the slider maxed and fall apart for a player running it at half. If a building pops for your community and not for you, check that first. You cannot fix a settings difference with a ytyp.

Why custom props vanish instead of getting simpler

Props almost always ship HD only. They are ORPHANHD, they have no parent, and nothing sits behind them in the chain. When the camera crosses lodDist the prop is not simplified, it is gone. Correct behaviour for a wheelie bin, a disaster for a forty metre gantry crane or the custom bridge railing somebody streamed in as a prop because it was easier than building it into the map.

You have three honest options: build a real LOD model and parent it, push the prop’s lodDist up and pay for it in draw calls, or choose better assets in the first place. The distance a pack ships with tells you whether the creator ever looked at it from across the street, so read the file contents when you shop for custom props for your map rather than judging from a render.

Props spawned by a script are a different animal. An object created at runtime never joins the streaming LOD chain, so no ytyp value will change how it behaves. Those follow object draw distance and the networking rules, which brings its own pile of surprises around entity ownership and network IDs. If a prop only disappears for other players, stop reading ymaps. That is a network problem wearing a streaming costume.

Flicker and z-fighting at the swap distance

When a building shimmers at one specific range, the handover is misaligned. There are two ways to get it wrong and they look nothing alike.

If the parent’s childLodDist is smaller than the child’s lodDist, both models draw at once in that band. The LOD shell usually sits within a few centimetres of the HD surfaces it replaces, so you get coplanar faces fighting over which is nearer the camera. That is the crawling stripey shimmer across walls and roofs, and it moves as you move because the depth comparison keeps flipping.

If the parent’s childLodDist is larger, you get the opposite. The child has stopped drawing and the parent still thinks the child is handling it, so nothing renders at all. The building blinks out for a band of distance then reappears further away, which is baffling the first time you see it, because “it comes back if I keep walking” is not a symptom anyone expects.

The rule is boring and reliable: a parent’s childLodDist should equal the largest lodDist among its children, exactly rather than approximately. And if the flicker happens at every distance instead of one, check whether the building got placed twice across two ymaps. Two identical entities in the same spot will fight forever, and no distance value saves them.

Buildings that go dark before they disappear

Lights are attributes on the HD drawable. Stream the HD model out and its lights go with it, which is why the custom nightclub is a black rectangle at 150 metres while the vanilla block behind it is still glowing.

GTA V solves this with a separate lighting system for range. The ymap carries LOD light and distant LOD light arrays holding position, colour, intensity, falloff and flags for which time of day they switch on. They are independent of the light attributes on the model, with their own distances, and CodeWalker can generate them from your HD entity lights instead of making you place each one by hand. Skip the step and your map has a curfew.

It fails in reverse too, and that one is funnier: light data with a longer reach than the geometry leaves a constellation hanging in the dark where a building used to be. Very atmospheric, not what anyone ordered.

What CodeWalker shows you, and what to change first

Open the ymap in the Project window and click an entity. The panel gives you lod level, lod distance, child lod distance, the parent link and the child count in one place. Open the ytyp alongside it for the archetype’s lod distance, HD texture distance, and the bounding box and sphere. Everything in this article lives on those two panels, which is the good news.

Change things in this order, because each step invalidates the ones after it. Bounds first, since a wrong bounding sphere makes every distance value lie to you. Then make the ytyp and the ymap agree, then check the parent and child pairing. Raise lodDist last, once the first three are clean. Back away with a free camera while you test and write down the actual metre reading at which the model changes, because debugging by vibes is how a map ends up with every value set to 750 and nobody able to remember why.

The performance trade nobody mentions until it’s too late

lodDist is really answering one question: how much of Los Santos should be in the draw list right now. Raise it on one problem building and you pay for one building. Raise it across a whole map because popping annoys you, and you have asked every client to render a chunk of the city at full detail permanently.

Draw calls climb, streaming memory fills, the entity budget runs out. When the streamer thrashes, buildings fail to appear and textures stay blurry, which is the exact symptom you set out to fix, now applied to the whole map instead of one apartment block. Keep HD distances short and let the LOD tier carry the range. That is what the tier is for.

Measure it rather than trusting your eyes on a dev box with a good GPU. Frame rate is client side and will not show up in server telemetry, but a baseline from proper FiveM server monitoring answers the “is it me or the server” question in ten seconds instead of an evening.

Diagnosing a popping building, in order

Describe the symptom precisely. Vanishing, degrading to a blob and flickering are three faults with three causes.
Rule out the client by reproducing at the reporter’s Distance Scaling setting rather than yours.
Read the entity’s lodLevel in the ymap. ORPHANHD with no parent will always vanish, and no tuning changes that.
Check the bounding sphere covers the model, and recalculate extents if anything was scaled or re-exported.
Make the entity’s lodDist in the ymap match the archetype’s in the ytyp.
If there is a parent, compare its childLodDist against the child’s lodDist. Bigger is a gap and a vanish, smaller is an overlap and a flicker.
Confirm the ymap’s parent field points at the LOD ymap and both files ship in the same resource.
Retest at night before you call it fixed.
Only then raise a distance, on that one entity, and check your frame rate after.

Most popping buildings turn out to be step three or step six, and both take two minutes to check once you know where to look. Get the chain agreeing with itself and the handover goes invisible, which is the entire goal. Nobody should ever notice an LOD swap, they should just notice your city looks solid from the freeway. And your fence gets to go back to guarding an actual building instead of a very well protected patch of nothing.

Blog