Cities: Skylines 2 Performance Woes Due to High-Poly NPC Teeth

Level 1: Way Too Detailed

Imagine you built a model city with thousands of little toy people. Now, picture deciding to give each tiny plastic person a full set of realistic teeth carved into their tiny mouths. 😄 It’s a ton of tedious work that you’d never actually notice just by looking at the city – they’re so small that you can’t even see those teeth without a magnifying glass! But you spent all that time on every single person’s teeth anyway. As a result, it took you forever to finish your city, and if this were a computer, it would run really slow because it’s doing way too much extra work. That’s exactly what happened in this funny scenario: the game developers made each little on-screen person in the city far more detailed than anyone can appreciate, even including things as silly as individual teeth. The end result? The computer is working overtime to draw pointless details, and the game starts to chug and lag. It’s funny because it’s such a ridiculous overkill – kind of like using a giant machine to crack a peanut. The joke is basically that the game is way too detailed in a place it doesn’t need to be, which is both absurd and a little bit silly, so we can’t help but laugh at it.

Level 2: Tiny People, Huge Detail

Let’s break down what’s going on in simpler terms. In video games (especially city-builders), you often see little computer-controlled people walking around – those are NPCs (Non-Player Characters). Now, each NPC is represented by a 3D mesh, basically a model made up of lots of tiny triangles (polygons). When we say a model is high poly, we mean it has a high polygon count – thousands or even millions of these tiny triangles, which allows for very fine details (like fingers, facial features, teeth, etc.). High-poly models look great up close because they’re very detailed, but they are also heavier for the computer to draw. Conversely, a low poly model has far fewer triangles – it’s more blocky or simplified, but much faster to render.

In game development, there’s a crucial concept called Level of Detail (LOD). LOD means you use different versions of a model depending on how far it is from the camera. Think of it like having a detailed version of a car for when you’re standing next to it, a simpler toy-like version when it’s down the street, and maybe just a colored blob when it’s a mile away. The idea is you won’t notice the lost detail when it’s far, but the computer definitely “notices” the reduced work and can run the game faster. This is a common performance optimization technique in GameEngines: it cuts down unnecessary detail. Almost every big game uses LODs or similar tricks because there’s usually a performance tradeoff between graphics quality and frame rate. You want the game to look good and run smoothly, so you don’t draw every little thing when it’s not needed. For example, if 1000 people are in your city and each one is just a few pixels on the screen, you normally tell the engine to use a very simple model (or even nothing at all for the farthest ones).

Now, what happened with Cities: Skylines II (a big city-building game) is pretty wild: apparently the game was using the super detailed version of each person all the time, even when those people appeared tiny on the screen. Imagine those little pedestrians on the sidewalk – in the game they might look like tiny dots wearing red or blue jackets. But behind the scenes, the computer was actually drawing a full 3D person for each of them with every little detail: individual fingers, and yes, believe it or not, individual teeth in their mouths! There was no LOD in effect for these models, meaning no simpler model was ever used. The Reddit post in the meme even confirmed it by showing a wireframe image (green mesh) of an NPC’s head and jaw packed with hundreds of triangles. That’s an insane amount of detail for something so small on screen. This is what we call rendering overkill or being over-detailed. All those extra polygons (triangles) add up – the computer has to work much harder to draw thousands of high-detail people than if they were low-detail.

Because of this, the game’s performance suffered. Players noticed the game was running slowly (low FPS, frames per second) and started digging into why. They discovered this quirk: the developers left every NPC’s model in ultra-high detail with no simplification. In practical terms, it’s like the game was trying to draw every tooth of every person in the city, which is overkill and causes the frame rate to drop dramatically. It was a big bug (or oversight) in the game. For anyone learning about GameDevelopment, it’s a great example of why we need to balance detail with performance. Too much detail in the wrong place – like high-poly NPCs with all their teeth visible at all distances – can make even a powerful PC struggle. The meme is basically poking fun at this crazy mistake. It’s saying, “This city-builder game is even rendering each NPC’s dental records in 4K!” – which is a joking way to express that the game is doing absurdly unnecessary work. The takeaway: even in cutting-edge games, you sometimes find silly issues where something is way more detailed than it should be, and it ends up hurting performance big time.

Level 3: LODs of Trouble

For seasoned developers, this meme hits like a facepalm-inducing postmortem of what not to do in game optimization. Cities: Skylines II launched with notorious performance issues, and one culprit was hilariously specific: every NPC wandering the streets was rendered in full high poly glory, down to each tooth in their mouth. The tweet in the meme sums it up with incredulity – “thousands of people walking around your city, including their individual teeth.” That absurd level of detail is funny on the surface, but it’s also a cringe-worthy nod to a GameDevelopment oversight. We have high_poly_npc_meshes meant for up-close inspection being used en masse with zero simplification. In industry terms, the game lacked any proper LOD system for its pedestrians. This is the kind of glaring issue that senior GraphicsProgramming engineers lose sleep over: it’s an obvious performance killer that should have been caught in profiling.

Why is this so humorous (and painful) to devs? It’s the sheer overkill of it. Imagine reviewing a colleague’s code or assets and discovering that the crowds in a strategy game have ultra-detailed teeth models usually reserved for first-person character close-ups. It’s a meme-worthy mix of over-engineering and missed optimization. The humor comes from the contrast: on screen those NPCs are tiny–little more than a few pixels tall–yet under the hood each one is treated like a main character in a cutscene, complete with a full dental record in 4K detail. It’s a classic case of premature fidelity: someone invested effort (or neglected to reduce effort) in an area that yields no benefit to the player experience. Every experienced dev knows the mantra “work smarter, not harder” – here the game’s engine is working much harder for virtually zero visual gain. It’s hard not to chuckle (or groan) at that miscalculation.

From an architectural perspective, this scenario likely arose from an asset pipeline misstep. In a typical AAA workflow, artists create a high-detail model (say, a richly detailed human with teeth, fingers, etc.) but then generate several lower-detail versions for use at distance – these are the LODs. The engine is supposed to automatically swap in those cheaper models when an NPC is far away, a distance-based trick to save on rendering cost. The fact that “no LOD as far as I can tell” became a talking point means that either the developers didn’t include those lower LOD models, or the engine isn’t using them due to a bug or oversight. It’s a performanceOptimization 101 failure. The meme’s Reddit screenshot even shows a wireframe of the head and jaw, revealing an extremely dense mesh. Any senior dev looking at that wireframe knows immediately that those polygons are way too fine for something seen from a city-wide camera. It’s like seeing a blueprint where someone put intricate carvings on the doorknobs of a skyscraper – you’d shake your head and say, “Nobody will ever see that, and it’s just wasting resources!”

The consequence of this LOD lapse is a performanceIssue so severe that it drags down frame rates for the entire simulation. Each pedestrian became a tiny performance bomb. Draw calls – which involve the CPU telling the GPU to render an object – likely shot through the roof because thousands of detailed models each need separate processing. (In tech jargon, we’d say the draw call overhead was off the charts.) Even if the GPU could technically handle the raw triangle load, the overhead of managing so many complex objects is enormous. The engine essentially treated a crowd scene with the same fidelity as a close-up scene, and the hardware choked on the excess work. As a result, players experienced choppy frame rates, leading them to investigate why. The discovery of teeth-level detail in NPCs became an instant meme in the community – it perfectly encapsulated why the game ran poorly. It’s a symptom and a symbol: a tiny detail (teeth meshes) representing the larger issue of poor optimization.

For veteran devs, there’s also a tinge of “there but for the grace of God go I.” We’ve all seen how production pressures can lead to cutting corners on optimization. Perhaps the team focused on new features and didn’t get around to LOD tuning before release. Maybe they assumed modern PCs could brute-force it (spoiler: they couldn’t, not at this scale). Performance tradeoffs are tough – if you’re rushing to ship, you might leave detail in and hope it’s okay. Unfortunately, this became a public lesson: ignoring established best practices like LOD will come back to bite you (pun intended, because those teeth definitely bit the frame rate!). The meme is both funny and educational. It’s funny because, really, who expected teeth of all things to be rendered for tiny NPCs? And it’s educational as an “anti-pattern” – a clear example of why we always budget polygons and enable LOD in large simulations. In the end, the situation is almost poetic: a city-building game brought to its knees by the pearly whites of its citizens. As a fellow dev, you have to laugh, shake your head, and maybe grind your own teeth a little in sympathy.

// What should have happened (simplified pseudo-code):
for (NPC npc : city.npcs) {
    if (distance(camera, npc) < closeThreshold) 
        drawModel(npc.highDetailMesh);   // High detail (teeth visible) only up close
    else 
        drawModel(npc.lowDetailMesh);    // Switch to low-poly mesh for far away NPCs
}

// What actually happened in CS2 (conceptually):
for (NPC npc : city.npcs) {
    drawModel(npc.highDetailMesh);       // Oops: always using highest detail, even when tiny on screen
}

In summary, the meme’s core joke highlights a performanceOptimization failure that all graphics engineers can learn from. It’s a cautionary tale: if you don’t implement LOD properly, your frame rate will be gnawed away byte by byte, tooth by tooth.

Level 4: Polygon Budget Blowout

At the cutting edge of graphics programming, every 3D game must respect a polygon budget – a limit on how many triangles can be drawn per frame without tanking performance. In a large-scale city simulation like Cities: Skylines II, that budget is precious. However, this game famously blew the polygon budget out of the water by rendering every tiny pedestrian with a high-poly mesh (thousands of triangles) that even includes individually modeled teeth. The fundamental issue is a complete lack of Level-of-Detail (LOD) scaling – an advanced concept in game engines where lower-detail models replace high-detail ones as objects get smaller on screen. Normally, a distant NPC would switch to a simplified mesh (fewer polygons) or even a billboard sprite, drastically cutting down rendering workload. But here, with level_of_detail_absent, even far-away citizens are drawn with the exact same dense geometry as if you were zoomed in to inspect their molars. This is rendering overkill at a theoretical level: the engine is pushing an insane number of vertices through the GPU pipeline for details no player can actually perceive. It’s like using a supercomputer to calculate the physics of each snowflake in a blizzard – technically impressive, but performance suicide when scaled up.

From a hardware perspective, modern GPUs can process millions of triangles per second, but they have limits on throughput and memory bandwidth. When thousands of high-poly NPC meshes appear, the vertex shader stage overflows with work. Each tooth, each facial vertex chews up GPU cycles and cache, contributing to a massive draw_call_explosion (each character might involve multiple draw calls for body, head, individual_teeth_geometry, etc.). Without LOD, the triangle count on screen stays perilously high regardless of camera distance, violating a core principle of real-time rendering: don’t spend resources on what the player can’t see. Historically, graphics pioneers introduced mesh simplification algorithms (like iterative edge collapse and quadric error decimation) precisely to avoid this scenario. It’s almost surreal that in 2023 – decades after GameDev learned to manage poly counts on the PS1 and N64 – we’re revisiting a brute-force approach where a city-builder sim renders crowd NPCs with cinematic detail. The result? A textbook example of a performance tradeoff gone wrong: by prioritizing maximum fidelity on every object, the game runs into fundamental hardware limits. In essence, this asset_pipeline_misstep turned a city simulation into an unintended stress test of GPU geometry throughput, illustrating the hard truth that no amount of raw power can save you from a polygon_budget_blowout if you ignore scalable LOD design.