On Wed, Sep 25, 2013 at 4:46 PM, Tomash Brechko <tomash.brec...@gmail.com> 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 ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
