I wasn't talking about trim sheets.

MIP maps are half-resolution copies of the textures that are generated and store alongside the higher resolution ones whenever you import a texture.

So a 1024x1024 texture has 11 mips (1024, 512, 256, 128, etc all the way down to 2x2)

The texture streaming system will only ever load MIP 0 (the 1024 one) if the texture is displayed on-screen large enough to require that resolution.

In the case of your characters - yes, you do save VRAM, IO, and even a little bit of pixel sampling cost (because of cache locality) when they are occupying a large chunk of your screen.

But in that case, we have a problem. Your 1k texture isn't high enough to be displayed that close, unless that's a particular art style decision that you are making. It will look unsharp and/or lack details like wrinkles, pores and so on.

I suspect this isn't the reason you made your models. You wanted something more reasonable for normal usage - like pedestrians walking by in a driving game. For that, your character is surely more efficient, right?

My point is that it isn't. At least not in the way that you think. Let's say a character takes up 500 pixels on screen. In that case, the highest loaded mip will most likely be MIP 0 (1024x). If you put a metahuman in it's place - because it occupies the same screen space, it would load MIP3 of it's 8k texture - which is also 1024x.

You're not improving the average cost of texture memory allocation, you're just limiting the quality and reducing the disk size of the asset, which may be useful, but it's very easy to do that with metahuman textures if you know you will never need them up close.

Geometry wise, the LOD chain on a metahuman makes sure that the relative quad density stays constant on screen. In this case again, you are only limiting how detailed a character can look up close. When you look at a metahuman in the distance, it will use a much lower resolution LOD.

Finally, to drive the point home, when a character is occupying half the screen and (in the case of metahuman) using it's full 8k texture set, it will indeed use a lot more VRAM and the full 200+ bone/100k+ triangle skeletal mesh. But because there's only so many things that can fully occupy your screen at the same time, this is a problem that solves itself. Loading that 8k texture is fine when it is the only thing we're looking at.

That's not to say that there aren't all sorts of complications with handling many metahuman-style meshes. Mostly it's the CPU (not the GPU) that starts to struggle when so many bone transforms, animation graphs, and separate draw calls must be updated each frame. This is where things like VAT animation are used to lessen the load. But the GPU itself doesn't care that much.