Hacker News Reader

Comment by luaKmua | Hacker News Reader

No love for Unity here, their licensing debacle was horrendous, but I've seen no indications that DOTS is responsible for CS2 perf issues. Everything I've seen points to other things lacking in the engine (a decent LODing system for example), general optimization issues that'd be present in any game shipped too early, and inefficiencies in the rendering pipeline.

View on HN

"Unfortunately a lot of the graphics-related issues are indirectly caused by the game’s use of DOTS"

"The cause for unnecessary geometry is both the lack of simplified LOD variants for many of the game’s meshes, as well as the simplistic and seemingly untuned culling implementation. And the reason why the game has its own culling implementation instead of using Unity’s built in solution (which should at least in theory be much more advanced) is because Colossal Order had to implement quite a lot of the graphics side themselves because Unity’s integration between DOTS and HDRP is still very much a work in progress and arguably unsuitable for most actual games"

https://blog.paavo.me/cities-skylines-2-performance

I think if a game development team is going to try ECS for gameplay, they need to have the resources to go ensure it’s comprehensive enough for their needs. It can be challenging to “bolt on” a data-oriented design and have it interface with the rest of the code base. Conway’s Law will apply if not everyone’s on board with it.

At some point, that in house engine is going to be cheaper and easier to work with.

Alternatively, a tough conversation needs to be had with the team about complying with unity's way.

Battlebit runs on the same engine, but I think they made exactly the right trade offs to achieve their experience.

I don't care if the game world looks realistic. I just want it to be fun. Simulations are a nuanced point of this, but even so if CS2 looked no better than the original, I probably wouldn't have noticed.

I was wondering if and how they were using DOTS with HDRP since (from brief pokes, I of course can't speak for all of DOTS) to my knowledge, there was no major work done integrating HDRP/URP. Both were moving targets that were probably moving even faster than DOTS.

I guess the answer is an unfortunate "we did not" as of now. Real shame because the ideas of a proper DOTS renderer (not a literal renderer, moreso an ECS oriented way to deliver data to the GPU. Likely HDRP/URP) was one rumbling for years. And probably still is. And with all the industry layoffs/leavings I hope they don't drain too much of the brain to get that off the ground.

No game engine can save a game from someone dedicated to being inefficient, like rendering high poly teeth on pixel tall models.

I would have assumed the game engine would be responsible for culling occluded objects. Isn't that one of the most basic parts of a 3D renderer?

Yes I would expect that from a 3d engine that I pay a license fee towards, but I also expect the developer to performance test and fix some of these things before release

Developer prioritize features and fixes. You don't know if there were worse issues before release. It should be on the managers and the publisher to set reasonable timelines and delay release when it can't meet expectations.

Occlusion culling is pretty usecase dependent if you want a performant solution. Unity implements frustum culling and Umbra which is a pre-computed solution. The latter is probably not great for CS2 and the former is basically the minimum. Unity have definitely slept on introducing more alternatives though.

Even if a 3D object is culled by the renderer, the mesh is still loaded in memory

For a zoomed out view with tiny people walking around, that would be mostly be a case for LOD, not culling. That is, you wouldn't render a highly-detailed character model and cull out each tooth mesh individually, which would still be very expensive, but you should render a simplified mesh to begin with.

In the case of this game, the mouths were never open, the teeth were never visible at all. Which is obviously a massive failure of the developers (using a prefab model with a ton of completely unused detail is a waste of everyones bandwidth, storage and memory), but the teeth should at least never be rendered by the engine.

For anybody else reading this and thinking (like I did) that these comments about teeth are a deliberately silly example invented for the purpose of this discussion - it turns out that Cities Skylines 2 really did have NPCs with teeth in their models, per this[1] story from up the thread.

1: https://blog.paavo.me/cities-skylines-2-performance/

this is very computationally expensive to do such operation (to understand that teeth is completely occluded by something else like mouth)

this is called occlusion culling and usually it brings a lot of problems on its own (it's CPU intensive and you need to apply it smartly only where it helps)

and even if this occlusion culling would be cheap, the way how it is usually done requires precomputing a lot of data - so occluders are static geometry

since character head is skinned mesh - so dynamically changes every frame based on joints positions - that will be another level of complexity

game engines are not really helpful here

Considering how long it takes to load games like Battlebit (super low poly 3D) or Graveyard Keeper (2D), speed/efficiency/optimization is not something I expect to see much of with Unity. While there are exceptions, its performance seems pretty consistently bad.

Reply on news.ycombinator.com