Optimization is treated as a problem-solving activity when it should be a planning activity. By the time someone raises a performance concern, the art is already built, the habits are already formed, and fixing it is expensive.
Timing Is Everything
Game development is often a balancing act; you need R&D first to figure out the style and direction of your project. I'm not saying teams should hyper-fixate on optimization at the expense of that process; that's the complete opposite of what I'm getting at. If pipelines are too early in their development, it's genuinely hard to optimize content because the foundation isn't ready yet. Shader optimizations are a good example of this. Setting up LODs, on the other hand, makes sense early in a traditional pipeline, as that work always has to be done regardless of where you are in production.
The moment optimization gets treated as something to deal with later, the cost of dealing with it compounds.
It's Rarely a Disaster, But It's Always a Tax
Contrary to what some might expect, I don't have horror stories. During each project there were challenges developing asset pipelines while tools weren't production-ready yet, which led to learning lessons along the way. That's normal. What's less normal, and worth flagging, is when performance issues get diagnosed too bluntly. Solely watching the performance graph and waiting for it to drop can give false positives. Lowering texture resolution will improve performance, but does it actually solve the underlying problem? Are you missing LODs, uncollapsed draw calls, unoptimized collision meshes? The number going up doesn't tell you that.
What It Looks Like in Practice
Some of the more concrete challenges I encountered: not having all content run through the optimized pipeline, which meant additional manual tweaks were still needed for far-distance LOD meshes. On a cross-platform title, not setting proper LOD distances early caused issues that were expensive to revisit. Skipping the first visual LOD incorrectly. And collision meshes with too many triangles, something with a real CPU cost. There was no hard limit defined for collision triangle counts; it was largely driven by artist experience and the assumption that larger on-screen assets required more accurate colliders. That's fair, but it still came at a cost that wasn't being tracked.
In my experience, most developers had a reasonable instinct around texture resolution — keeping maps at 2K, with 4K as a real exception reserved for cinematics, characters, or full-screen assets. That baseline consistency helped. The problems surfaced, on a different project, where consistency broke down across asset types: environment art with twice the texel density of characters, or assets with triple the average triangle count. The more content is authored without addressing this, the harder it becomes to course-correct later.
Conclusion
Performance matters, but it shouldn't hinder the creative process, and sometimes it does, driven by the loudest voices in the studio. Hyper-fixating on performance for performance's sake is not the way a team should approach it. It's a collaborative and iterative process that has to involve art direction, leads, and producers, so that everyone understands the constraints of the pipeline — and how scalable, or not scalable, it actually is.
This is as much a leadership problem as it is a technical one. The conversation doesn't need to be a blocker; it needs to be on the agenda.
© 2026 Stefan Groenewoud — All views are my own, not those of my employer.