Simple one really; Game Guru supports LOD, but does it support mipmaps? Seems like an obvious way to free up a lot of texture memory.

AE

Simple answer yes it does, there was an issue with the Mipmaps but I think it as been resolved

Would anyone care to explain how this system works in Game Guru and whether, as an artist, I need to create/specify anything my side to allow Game Guru to use mipmaps?

AE

the shaders will use MipMaps if they are available, when creating your DDS files ensure your software allows for mips they usually go down to 8 0-7 the shader will pick which layer to use depending on distance, I don't use LOD or Mips all the time it depends on the asset.

Each bitmap image of the mipmap set is a downsized duplicate of the main texture, but at a certain reduced level of detail. Although the main texture would still be used when the view is sufficient to render it in full detail, the renderer will switch to a suitable mipmap image (or in fact, interpolate between the two nearest, if trilinear filtering is activated) when the texture is viewed from a distance or at a small size. Rendering speed increases since the number of texture pixels (texels) being processed per display pixel can be much lower for similar results with the simpler mipmap textures. If using a limited number of texture samples per display pixel (as is the case with bilinear filtering) then artifacts are reduced since the mipmap images are effectively already anti-aliased. Scaling down and up is made more efficient with mipmaps as well.
If the texture has a basic size of 256 by 256 pixels, then the associated mipmap set may contain a series of 8 images, each one-fourth the total area of the previous one: 128×128 pixels, 64×64, 32×32, 16×16, 8×8, 4×4, 2×2, 1×1 (a single pixel). If, for example, a scene is rendering this texture in a space of 40×40 pixels, then either a scaled-up version of the 32×32 (without trilinear interpolation) or an interpolation of the 64×64 and the 32×32 mipmaps (with trilinear interpolation) would be used. The simplest way to generate these textures is by successive averaging; however, more sophisticated algorithms (perhaps based on signal processing and Fourier transforms) can also be used.

The original RGB image:

In the case of an RGB image with three channels stored as separate planes, the total mipmap can be visualized as fitting neatly into a square area twice as large as the dimensions of the original image on each side. It also shows visually how using mipmaps requires 33% more memory.
The increase in storage space required for all of these mipmaps is a third of the original texture, because the sum of the areas 1/4 + 1/16 + 1/64 + 1/256 + ⋯ converges to 1/3. In the case of an RGB image with three channels stored as separate planes, the total mipmap can be visualized as fitting neatly into a square area twice as large as the dimensions of the original image on each side (twice as large on each side is four times the original area - one plane of the original size for each of red, green and blue makes three times the original area, and then since the smaller textures take 1/3 of the original, 1/3 of three is one, so they will take the same total space as just one of the original red, green, or blue planes). This is the inspiration for the tag multum in parvo.

Anisotropic filtering:

When a texture is viewed at a steep angle, the filtering should not be uniform in each direction (it should be anisotropic rather than isotropic), and a compromise resolution is required. If a higher resolution is used, the cache coherence goes down, and the aliasing is increased in one direction, but the image tends to be clearer. If a lower resolution is used, the cache coherence is improved, but the image is overly blurry. This would be a tradeoff of MIP level of detail (LOD) for aliasing vs blurriness. However anisotropic filtering attempts to resolve this trade-off by sampling a non isotropic texture footprint for each pixel rather than merely adjusting the MIP LOD. This non isotropic texture sampling requires either a more sophisticated storage scheme or a summation of more texture fetches at higher frequencies.

MIPS in a basic dds file:



creating MIPS in paint.net:



I hope this helps

in engine example :

Please be aware MIPS increase your texture file size.

GraPhix, you're a star - thanks for such a detail explanation!

So it seems like the limiting factor for most users will be Game Guru's memory cap, rather than the end user's texel processing power. Good to know though.

A related point; I never really understood how a 380kb .png was somehow more costly than a 2mb .dds version of the same texture. OK dds is optimised for game engines but surely the .png takes less memory?

AE

Glad it helped here is a brief discussion on PNG vs DDS https://forum.game-guru.com/thread/219617#msg2599620

Must say if not for the TGC community i would have been far behind in my knowledge of game development. Great to learn about the industry techniques that are used.

Mip maps have been around for ages. Any game engine that doesn't support them would be poor indeed. I first learned about them when using DB Classic

PNG is stored on your disk compressed , so GG need to uncompress it to use it, so a:
png 32bpp, 380kb (on disk). 1024x1024 texture will use: 1024x1024x4 bytes in GPU memory = 4096 kb. (32bpp = 4 bytes per pixel).

All the BC versions use 4 or 8 bits per pixel, its in a block compression that can be used directly on the GPU so sample:
dds 8bpp BC3, 1024kb (on disk). will use 1024kb in GPU memory.

To these numbers you need to add the mips maps, and perhaps your dds have a alpha channel also, that all add to the size.

When you save your images in dds format you can see what each of the formats use in bits per pixel (bpp), so if you select a format that use 32bpp+ in dds you might as well save it as a png, they will then use the same amount of memory in GG and on the GPU.

ALL images that are used with GG will have mipmaps, if you as a artist to not generate the mipmaps then GG will do it for you when it loads your images, and it dont matter what format your texture is in dds or png there will ALWAYS be generated mipmaps.

Mipmaps will double the memory used on the CPU and GPU, but are always needed, if not used you would see a lot of flicker on the screen.

thank you for the update Preben I was not 100% sure if GG automagically created the MIPS I thought it did but would not like to say in case I was wrong

Thanks for the explanation Preben, very clear now. I'll be converting my pngs to dds from now on! Also great to hear this...



I've been converting my pngs to dds in Paint.net as GraPhix showed in his mini tutorial, but I'm never quite sure if it works because when I try to open the images in Paint.net and Photoshop (CS4 64-bit), it doesn't load the mipmaps as separate layers like GraPhix's first video showed. I've attached one of my textures which supposedly has had mipmaps generated, would someone mind checking it actually does have mipmaps? No biggie if not, sounds like GG has it covered regardless.

Thanks you for help everyone!

AE

AE: it do have mip maps 10 levels , if you open it in visual studio it will give you all the info

Also i dont think you will notice any difference if you make your textures with or without mipmaps , as most software will use the DX mipmap generator ( from the DX sdk ) and its the same as used in GG so... , unless you custom draw your mipmaps then ...

I remember using that to create them back in the DB days Or at least an older version ;p