Shell Interiors vs Real MLOs: What Actually Runs Better on Your Server

Every FiveM server owner eventually faces the same shopping decision: the interior you want exists as a cheap shell and as a more expensive MLO, and the store pages look identical. Same screenshots, same furniture, same lighting on the promo shots. The difference only shows up after you install it, and it shows up in your players' frametime.

This article explains what is technically different between the two, why that difference matters for performance, and how to decide which one your server actually needs.

What a shell interior really is

A shell is a single large prop, usually a YDR drawable with an embedded or companion collision file, that contains the entire interior as one model. Creators place it far under the map or high in the sky, and a script teleports players into it when they enter a door.

The engine treats a shell exactly like it treats a dumpster or a street lamp: it is one entity. When the entity is within streaming range and not fully occluded as a whole, the game renders it. All of it.

That is the key limitation. A shell has no concept of rooms. If your shell is a two-story nightclub with a basement, an office, a bar and four bathrooms, standing in one bathroom still renders the office, the dance floor and every bottle behind the bar. The renderer cannot skip any of it, because from its point of view there is only one object.

• One entity, one draw decision: visible or not
• No per-room culling of props, lights or decals
• Dynamic lights inside the shell stay active across the whole model
• Collision is one big mesh, loaded as a unit

What a real MLO is

MLO stands for Multi-Level Object. It is an interior defined in a YTYP file with a special archetype that describes the interior as structured data: a list of rooms, the portals that connect them, and the entities that belong to each room.

That structure is what unlocks the engine's interior pipeline:

• Room definitions. Every prop, light and decal is assigned to a room. The renderer knows what belongs where.
• Portals. Doorways, windows and stair openings are declared as portals between rooms. The engine walks the portal graph from your camera position and only renders rooms that are actually visible through the chain of openings.
• Occlusion culling. Standing in the bathroom of that same nightclub, the engine renders the bathroom, checks which portals you can see through, and skips everything else. The office and the bar simply do not get drawn.
• Entity sets. Named groups of props inside the MLO that scripts can toggle at runtime. One MLO can ship a clean variant, a party variant and a construction variant without duplicating the interior.
• Per-room ambience. Timecycle modifiers and audio settings attach per room, so the basement can be dark and muffled while the entrance stays bright, with a smooth blend as you cross the portal.

-- Entity sets are controlled from script, per interior instance:
local interiorId = GetInteriorAtCoords(-1568.0, -3016.0, -76.0)
ActivateInteriorEntitySet(interiorId, "party_lights")
DeactivateInteriorEntitySet(interiorId, "default_furniture")
RefreshInterior(interiorId)

None of this exists for a shell. There is no interior ID, no rooms, no portals, nothing to toggle.

Where the FPS actually goes

The performance gap between the two approaches comes from three places.

Draw calls. A detailed interior can easily contain several hundred props. In an MLO, the visible set at any moment is whatever the portal graph says you can see, which in a normal room is a fraction of the total. In a shell, the visible set is the entire interior, every frame, from every angle inside it.

Dynamic lights. Lights are among the most expensive things you can render. MLO lights belong to rooms and get culled with them. Shell lights are either baked into the model, which looks flat, or placed as script-created lights that stay active for the whole interior.

Collision and physics. A shell's collision loads as one large mesh. MLO collision loads with the interior's assets through the streaming system, and the physics broadphase deals with smaller, room-scoped pieces.

The practical result: on mid-range hardware, a furnished shell interior commonly costs two to three times the frametime of an equivalent MLO once you are inside it. On low-end machines, which is a large share of the FiveM player base, that is the difference between a smooth 60 and dips into the 30s.

When a shell is actually fine

Shells earn their place in specific situations:

• Instanced apartments. If players teleport into a private, routing-bucket instance of a small apartment, there is no world context to cull against and the prop count is low. A shell is cheap to make and cheap enough to run.
• Small, simple interiors. A 10x10 office with a desk and two chairs does not need a portal graph. The culling gains would be negligible.
• Prototyping. Blocking out a location to test gameplay before commissioning the real MLO.
• Deep underground or sky boxes. Interiors that never interact with the exterior world avoid a shell's other weakness, which is the lack of proper exterior portals for windows.

When you need the real MLO

• Interiors connected to the street. If players should see inside through windows or an open door, only an MLO can do it properly. Shells sit in another part of the map, so their "windows" show void or fake backdrops.
• Large or multi-room layouts. Nightclubs, hospitals, police stations, apartment lobbies. This is where portal culling pays for itself.
• Prop-dense builds. The more furniture and clutter, the bigger the gap between rendering everything and rendering the visible rooms.
• Interiors that change state. Entity sets let one MLO serve renovations, seasonal decoration and job progression without shipping three versions.

How to tell what you are buying

Store pages rarely say "shell" out loud. Ask, or check for these signals before paying:

1. 01Ask for the interior's coordinates. A real MLO sits at its street location. A shell usually lives at strange coordinates far from its supposed address.
2. 02Ask whether it has working portals and rooms. A seller of a real MLO can answer immediately.
3. 03Ask for a video standing at a window. If the outside world is visible and correct, it is an MLO with exterior portals.
4. 04Check resource size against prop count. Shells bundle everything into a few large drawables; MLOs ship many smaller assets plus a YTYP.

For a deeper look at what asset streaming does to performance, read our guide on why your FiveM server lags. And if your loading times balloon after installing big interiors, the loading screen guide explains what players are actually waiting for.

Every script in The Orb catalog is built with the same performance-first mindset we applied here, resmon-measured and optimized before release.

FAQ

Can I convert a shell into an MLO?

Not automatically. An MLO needs room definitions, portal placement and per-room entity assignment, which is authoring work in tools like CodeWalker. Converting means rebuilding the interior data around the existing meshes, and in most cases commissioning a proper MLO is faster.

Do shells cause texture loss or streaming issues?

They can contribute. A shell is a heavy drawable, and combined with 4K texture packs it competes for streaming memory with everything else around it. MLOs spread their assets across smaller files that stream in and out per room.

Are all paid interiors MLOs?

No. Price is not a reliable signal. Some expensive interiors are beautifully decorated shells, and some cheap MLOs are excellent. Verify the format before buying, using the checks above.

Does OneSync change any of this?

OneSync affects entity sync between players, not how interiors render on each client. A shell costs the same frametime with 5 players or 500. What OneSync does change is how many players can be inside the same interior instance, which makes performant interiors matter more, not less.