|
From: Gary N. <gr...@gm...> - 2013-09-25 21:39:17
|
On Wed, Sep 25, 2013 at 4:46 PM, Tomash Brechko <tom...@gm...> wrote: > 100 / cos(45), but you get the idea ;) OK, I see what you're getting at now-- the selection of the mipmap for rendering rather than the memory footprint. Yes, that makes sense to me-- the engine should be able to choose a mipmap that best fits the screen scale based on distance, so for a larger base image it's dropping down deeper into the mipmaps. There is still the issue of resources. A 4096x4096 texture without an alpha channel is about 50MB, a 1024x1024 is about 3MB. Add +33% for mipmaps. So a single 4096 texture would buy a lot of 1024's. Also, I believe the larger the image, the more initial overhead is necessary to create the mipmaps, unless the image is a DDS type in which case mipmaps can be pre-generated. So the larger the image, the more memory resources required, and there's a bigger load hit when the resources are initially loaded. I've felt my machine come to a crawl while certain planes are loaded in MP-- I had to remove some because they were too much of a hit for my poor aging system. -Gary |