this post was submitted on 06 Nov 2023
123 points (96.9% liked)

Games

16369 readers
609 users here now

Video game news oriented community. No NanoUFO is not a bot :)

Posts.

  1. News oriented content (general reviews, previews or retrospectives allowed).
  2. Broad discussion posts (preferably not only about a specific game).
  3. No humor/memes etc..
  4. No affiliate links
  5. No advertising.
  6. No clickbait, editorialized, sensational titles. State the game in question in the title. No all caps.
  7. No self promotion.
  8. No duplicate posts, newer post will be deleted unless there is more discussion in one of the posts.
  9. No politics.

Comments.

  1. No personal attacks.
  2. Obey instance rules.
  3. No low effort comments(one or two words, emoji etc..)
  4. Please use spoiler tags for spoilers.

My goal is just to have a community where people can go and see what new game news is out for the day and comment on it.

Other communities:

Beehaw.org gaming

Lemmy.ml gaming

lemmy.ca pcgaming

founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] tal@lemmy.today 73 points 10 months ago* (last edited 10 months ago) (9 children)

There's a lot of detailing what the author did to try to investigate the issues. That's interesting, but if one just wants what he found, one can skip to the end, which summarizes the results:

So why is Cities: Skylines 2 so incredibly heavy on the GPU? The short answer is that the game is throwing so much unnecessary geometry at the graphics card that the game manages to be largely limited by the available rasterization performance. 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. Similarly Unity’s virtual texturing solution remains eternally in beta, so CO had to implement their own solution for that too, which still has some teething issues.

Here’s what I think that happened (a.k.a this is speculation): Colossal Order took a gamble on Unity’s new and shiny tech, and in some ways it paid off massively and in others it caused them a lot of headache. This is not a rare situation in software development and is something I’ve experienced myself as well in my dayjob as a web-leaning developer. They chose DOTS as the architecture to fix the CPU bottlenecks their previous game suffered from and to increase the scale & depth of the simulation, and largely succeeded on that front. CO started the game when DOTS was still experimental, and it probably came as a surprise how much they had to implement themselves even when DOTS was officially considered production ready. I wouldn’t be surprised if they started the game with Entities Graphics but then had to pivot to custom solutions for culling, skeletal animation, texture streaming and so on when they realized Unity’s official solution was not going to cut it. Ultimately the game had to be released too early when these systems were still unpolished, likely due to financial and / or publisher pressure. None of these technical issues were news for the developers on release day, and I don’t believe their claim that the game was intended to target 30 FPS from the beginning — no purebred PC game has done that since the early 2000s, and the graphical fidelity doesn’t justify it.

In even shorter form:

  • Highly-detailed models coupled with a lack of lower-level-of-detail models for viewing at a distance.

  • Limited culling (avoiding drawing things that aren't actually visible onscreen).

  • Some gambles made on external work-in-progress software that turned out not to be ready at release time, forcing the developer to implement their own solutions.

[–] ayaya@lemdro.id 33 points 10 months ago* (last edited 10 months ago) (3 children)

This tracks with my experience using Unity in the past. They like to add a bunch of half-baked new features while simultaneously deprecating old ones that worked fine. Which means you have to choose between using a "worse" feature you know will no longer be supported or using a "better" feature that's not fully finished yet. When your release window is 2+ years out it is really hard to make that decision.

And they do it directly in their stable builds and label individual features as "beta" rather than keeping them in a separate beta branch which is remarkably stupid. It makes them seem like the features are ready for production when they're clearly not.

[–] HolyDuckTurtle@kbin.social 4 points 10 months ago

The moment I saw HDRP mentioned I thought "Yup, that'd do it"

load more comments (2 replies)
load more comments (7 replies)