Pokemon Z-A Entire City as Single 3D Model Causing Performance Nightmares
Description
A social media post from user 'terramythos' on what appears to be Tumblr or a similar platform. The first post says 'what do you MEAN the entire city in pokemon z-a is a single model' followed by a reply from the same user showing a 3D wireframe/debug view of the city model -- a massive circular disc-shaped city rendered in neon green, blue, pink and purple polygons viewed from an elevated angle, with buildings and structures visible across the entire surface. The follow-up reply reads 'are you people fucking insane????????? "damn wonder how we can fix frame drops" NOT BY DOING THAT'. The image reveals that the game developers built the entire city of Lumiose from Pokemon Z-A as one monolithic 3D mesh instead of properly chunking/streaming it, which explains the game's performance issues
Comments
44Comment deleted
Game Freak applied the microservices-to-monolith migration pattern to 3D meshes -- turns out, a single model architecture has the same scaling problems as a single database
I heard it's actually the hologram map in the museum Comment deleted
that's got to be it Comment deleted
actually this is probably fine Comment deleted
It’s actually far cheaper to render a single large mesh with a single material than a ton of small meshes with tons of materials Comment deleted
aye, that Comment deleted
especially if it static and low poly Comment deleted
of course if you do different materials bruh Comment deleted
Then we’re having many submeshes each rendered with its own material situation Comment deleted
no we don't Comment deleted
but that’s gonna be a huge ass model and textures + you’re going to need some custom culling i doubt switch 1/2 can afford that Comment deleted
If you don't have LODs and object culling Comment deleted
modern GPUs are weird and unintuitive like that Comment deleted
There is a solid reason behind that Comment deleted
The main bottleneck being having to transfer either one continuous block of data in one go from the CPU to the GPU or many blocks of data located god knows where in memory in many go’s setting up contexts and render queues and stuff over and over again Comment deleted
that's just not true, see chat Comment deleted
Do you have any idea how modern game engines and Graphics APIs work? Comment deleted
yes, have you read the chat(not comments)? Comment deleted
transfer speeds less of a problem for integrated GPUs (I'm not sure how nintendo connects the GPU to the rest of their system but I'm sure they're using their hw in a way that isn't entirely stupid) and certainly not a big issue for low-fidelity games like this Comment deleted
It’s not just transfer speeds or rather bus throughput, read again Comment deleted
…bus throughput means literally the same as transfer speed Comment deleted
That’s what “rather” means 🙃 Comment deleted
oh yeah this time I misread "or" as "but", my b. point still stands tho Comment deleted
yes yes context and render queues and such. not saying that's wrong. because it isn't. this is exactly why I originally said what pokémon is doing here is fine Comment deleted
I can refute one argument while upholding the other. mindblowing I know (not meant in a mean way) Comment deleted
Argument queue Comment deleted
plus, regardless of if it's one or several models - it's static, they can just save it in VRAM. which they're probably already doing anyway, texture atlas and all Comment deleted
anyway, as I said in the chat, one can issue multiple draw calls for different models using the same program keeping the same queue, and even within the same render pass. That's exactly what they're for. And having to render orders of magnitude less geometry (within the same render pass) will be quicker than rendering orders of magnitude more geometry, even if the case with less geometry will be less contiguous Comment deleted
That true Comment deleted
I will say, pokémon Z-A has a serious problem with things looking unpolished. but perf seems to be fine from what I've seen and heard Comment deleted
I think that's just how every Pokémon game looks, no? The Switch game had its pokédex decimated to save resources and it still looked a PS2 era game Comment deleted
nono, the graphical fidelity is fine imo, it just looks unfinished in a lot of places. compare: https://www.youtube.com/watch?v=kAk_dIrvAck - the opening from 0:15 to 0:54 looks amazing - after that it just looks like a normal cheap game - look at the buildings at 1:37, pretty terrible lack of detailing - at 7:45 there's serious clash of textures, and then a whole wall with balconys baked into the texture instead of actually being modeled - at 1:18:28 there's a building just … floating I think the main issue is that the pokémon and character models actually look pretty good, so everything else always looks shit in comparison. Comment deleted
I think if anything, the building exteriors needed a lot more work, but the rest of the game is more or less fine Comment deleted
Idl looks like a LOD to me Comment deleted
true that Comment deleted
it's certainly some kind of result of a renderpass imo. Not really proof of the premise that this even is handled as a single large model in-game. I wonder how they got that image, surely it's either directly from a jailbroken console, or from a blog showing off some pictures from a jailbroken console Comment deleted
the alternative is that this is indeed a data-mined model, imported into some software that just so happens to produce a render that looks exactly like the result of a renderpass. which I find hard to believe Comment deleted
Such LOD is overkill for a minor prop. Comment deleted
this must be misinformation Comment deleted
furthermore, there are many advantages in dividing your open world into sectors, especially if you factor in floating point precision issues Comment deleted
It's gotta be a huge ass world for the float precision errors to kick in in a meaningful way, like KSP big big Comment deleted
eh, i guess it depends on the implementation. i've personally had problems even with only a couple or so of thousands of in-engine units, especially with physics Comment deleted
if you do close up character animations, you will see them much sooner Comment deleted
unless you move the world instead of the character, but there are caveats in this solution Comment deleted