Discreet benefits of a Texture Atlas & specifically w/landscapes

So I started using Texture Atlases. I can see some obvious benefits:

  • using less sampler-slots since there is a 1-to-many relationship w/regards to slots and textures (the Z/W UV coordinate).
  • the ability to UV a slice is nifty too, since it can be mathed/logic’d out
  • it seems like it also uses less memory? I took 3 2k textures, listed @ 10MB in the asset-viewer, scrunched them up into an Array that was listed at ~24MB. Can someone confirm?

I know that physical, mechanical moving/loading of data, multiple textures, addressing distinct resources vs a single, larger one, etc; ‘administrative-overhead’ is a thing. So I would presume that having a single (albeit, larger) atlased texture is still better since it’s a ‘single’ thing and overall, smaller (less push required to move it around)?

I know these are small-potatoes in the overall scheme, but am I accurate? Anything-else I might be overlooking, no matter how mundane?

A texture atlas is a double edged sword. You can have extra data that will reduce texture updates, but if you have too much in the atlas you will drain available vram.

It would only be a 100% usefull if none of it goes to waste (all “slots” are used at all times)

You also need to leave some room for post processing and other effects that use vram.

And im not sure if it would work with mipmaps well

In my case it would be taking existing textures (layers in a landscape) and pushing them to a single-container. Ultimately nothing new-new is added, and some maths are simpler for me too.

If you have 1 color layers then you could push specific effects to a single channel of the rgba texture map and have 4 in 1 (just use a mask to isolate them later)

I get that.

In my case it’s strictly a case of I have X layers in this landscape material, using x distinct samplers, associated overhead with single textures, whatever-else is there too. :smiley:

My thinking is since there are apparent-savings (of whatever sort), with binning the textures, I could push all the basecolors into a single TexArray and claw-back what I can. Same for packed-normal/height, and then GlossRoughAO. Essentially, I’d be able to cut some overheads to 1/3 and simplify some layer-maths.

I get this approach doesn’t work for all materials, etc, but for situations like above? I WANT to say landscapes are likely going to shoot me in the foot for something it does underneath the covers, otherwise, it looks like a win?

Landscapes tend to be large so, you might hit the upper texture limit size with an atlas for terrains.

g2know, thanks. but wouldn’t RAM be an apples-to-apples comparison here? If what I am already using simply takes-less isn’t that straight-win?

I’m not trying to spend more with what I claw back, strictly spend-less.

going to leave the question up for a day or two, but this was insightful, thanks.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.