Good evening,

I have to render a landscape with terrain and lots of buildings in it. Some of them are landmarks. A landmark is a building with a texture. Usually, there are relatively (compared to the overall buildings) few landmarks on screen and they are far apart, but they tend to have textures with high resolution. I have to code for a system where video memory is a concern and where only around 30 MB would be available for the landmarks textures at a time. With potentially dozens of landmarks on screen at a time and texture sizes in the mb range, this is a problem. My question is now what the most appropriate technique would be for me to keep texture memory usage low. My first thought would be something like Virtual texturing / Megatexture but is this really necessary if the landmarks are so sparsely distributed or would some simple customized mipmapping scheme be more appropriate?

Thanks for any suggestions.

Load couple low level of mips for all landmarks always. Then just stream higher levels for nearest(in locality or time) N landspaces.

Assuming landmarks are going to be VERY distant buildings that will get close as the character comes near them.

Like the person above says, you want to mipmap them. 512x512 might be too much as well for theses distant objects. You can get away with tightly packed 128x128 textures. When they get near, go ahead and start loading in higher res textures.

So my current plan is to create a large texture atlas (2048 x 2048) that consists of 128x128 tiles where each tile contains the low res texture of a landmark. For landmarks close to the camera I will use the individual high res textures.

Can someone sum up for me why Virtual Texture would be overkill in this situation?

512x512 might be too much as well for theses distant objects. You can get away with tightly packed 128x128 textures

512*512 is indeed waaaaaaay too big. Even 128*128 may quite possibly be "high resolution" for distant objects. A distant object which is for example only 64*64 pixels on screen will only need a mipmap at most 64*64 texels large. However, an object with a screen size of 128 (or larger) can still get away with a 64*64 (or smaller) texture with very little, if any visible difference. Atmospheric attenuation, scattering, and similar effects have it that distant objects appear darker and less saturated, and with fewer details. So, a somewhat darkened, undersampled mipmap is perfectly believeable for far-away marker objects.

Large textures are generally only ever needed for objects that are very close, and these tend to fill most of the screen (naturally, since they're both close and big). So you will only ever need one (or maybe two, in a very unlucky case) high resolution texture with a full-resolution mipmap at any time.

If you have support for sparse textures, this is immensely helpful. But otherwise, you can play with minimum/maximum mip level settings (the disadvantage is that you have to throw everything away and redefine the complete texture, and you have to physically provide the whole range that you define as "valid", whereas with sparse textures you can simply not commit what levels you don't use, and commit them later when you do, that is of course a lot more efficient).

So would it be more efficient to blit the downscaled textures to an atlas or should I just enable standard mipmapping and hope that opengl moves them into memory efficiently?

I would personally not use an atlas, even though you could possibly save a little memory with clever packing. However, using a texture atlas means not only having to do math on texture coordinates, but also having discontinuities (ugh... did I spell that right...). Not sure saving a few bytes justifies these disadvantages.

Especially the latter (discontinuities) aren't nice as it means you have to calculate derivatives and determine mip level by hand. If you leave that to the hardware, it will come out wrong with weird lines and whatnot artefacts that nobody can explain (well, you can explain the reason now!).

Once upon a time, before array textures were available, texture atlasses were soooo awesome, a "kind of must" for a lot of things (how would you do terrains with detail maps!) but nowadays they're pretty obsolete if you ask me. Except maybe as spritesheet for 2D. There it doesn't matter whether you have discontinuous texcoords either, since they don't wrap around anyway.

I would personally not use an atlas, even though you could possibly save a little memory with clever packing. However, using a texture atlas means not only having to do math on texture coordinates, but also having discontinuities (ugh... did I spell that right...). Not sure saving a few bytes justifies these disadvantages.

Especially the latter (discontinuities) aren't nice as it means you have to calculate derivatives and determine mip level by hand. If you leave that to the hardware, it will come out wrong with weird lines and whatnot artefacts that nobody can explain (well, you can explain the reason now!).

Once upon a time, before array textures were available, texture atlasses were soooo awesome, a "kind of must" for a lot of things (how would you do terrains with detail maps!) but nowadays they're pretty obsolete if you ask me. Except maybe as spritesheet for 2D. There it doesn't matter whether you have discontinuous texcoords either, since they don't wrap around anyway.

What do you mean with discontinuities? Every building has only one texture and it is already rectangular.

Atlas does not seem to give any advantages here. Atlas is always just an optimization so only use it when its give more benefits than problems.