- cross-posted to:
- gamedev@programming.dev
- gamedev@lemmy.ml
- games@sh.itjust.works
- cross-posted to:
- gamedev@programming.dev
- gamedev@lemmy.ml
- games@sh.itjust.works
You must log in or register to comment.
It looks like the biggest culprit is poor or non existent lod’s on the models. Strikes me as odd though as that’s a pretty basic art requirement for a game like this. I don’t see how this took them by suprise.
I guess the good news is that’s it’s easily fixable. It’s not like ksp2 which looks like it has some pretty unsolvable core issues.
I read up until the part where it’s using unity HDRP. I haven’t found a way to make that perform remotely well on any hardware they should have just stuck with URP or legacy. The only thing HDRP even gives you on top is volumetric lighting and you’d be better off writing your own or using an asset with how poorly HDRP performs.
I thought the point of a game engine was to do that stuff…
Game dev is not my wheelhouse but from what I gather in the article it is supposed to do some things better but the engine features (HDRP, DOTS, etc.) are still missing important features that led to a low of low-level re-implementations by Paradox…
However AFAIK game engines will not create LODs for you (and certainly won’t prevent you from using overly detailed models) so that part is squarely on Paradox.
At the end of the day a game engine is like any framework, it can make things a lot faster and easier but will not prevent you from shooting yourself in the foot if you don’t know what it is doing.
You’re right, but you totally could make a game engine generate LOD levels for you. Especially for a game like this, where you could get away with a very crude LOD simplifier for tiny, distant objects.
In their case they can probably plug some open source library into their unity asset pipeline without much difficulty.
Honestly I’m just surprised they implemented so much complex stuff but didn’t fix something so basic. Makes me wonder whether these blogs have correctly diagnosed the problem.
I’m sure that there are tools to automate some of the work, but my understanding is that in most cases modelling artists want some kind of control over the generated LODs to ensure they don’t look like shit. Removing vertices on a 3d textured object is not nearly as simple as scaling a 2d picture as far as I understand it. You need to avoid mismapped textures, clipping vertices, the wrong missing details causing obvious pop-in, etc. A triangle in one place can be redundant but another triangle elsewhere may be a critical detail whose removal will be obviously missing from a distance (for example if you model the white house, you really want to keep the small flagpole up top at ALL levels of detail, but automated systems might remove it).
TBF part of the problem is that modern graphics cards mostly can shrug off insane amounts of geometry and badly optimized models, so management must have heard “high prio but not strictly blocking for release” and said “put it in the backlog” (aka “lmao whatever nerd I don’t care then, please focus on Marketing’s feature list happy please and thank you”).
Yeah it’s a super hard problem, but my point is that in the specific case of a city building game most of the models are going to be extremely small on the screen 90% of the time, so you can get away with pretty terrible automated LOD in a way you can’t in most other genres; you just don’t swap to low-poly versions until stuff is extremely far away.
I was actually just thinking they should do this as an interim solution and then make optimized LODs to replace the automatic ones with. In fact, perhaps that would have been the thing to do instead of making advance apologies. Slightly suboptimal image quality at release would probably have been more tolerable than heinously bad performance.
With Unity you can get the problems of poorly documented and maintained third party tooling, with the added benefit of having to make your own in house tools too!
