Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Texture Atlas Border/Padding Size

Most malevolent Doomsday Mastermind,
In the Optimization Tips section, on the 3D Model Assets page of the manual, it reads:
All textures used by a model are stored in a large atlas. This means there are no restrictions on texture sizes, i.e., they do not have to be powers of two (e.g., 1024×1024). However, because the atlas needs borders and other padding around the textures stored in it, it is recommended that the model's textures are a bit smaller than power-of-two sizes. For instance, four 1000×1000 textures will easily fit on an atlas of 2048×2048; however, only one 1024×1024 texture would fit.

I’m looking for the exact borders and other padding the engine needs for my model textures to be optimized. The “a bit smaller” wording is unsatisfactory to my inferior robotic mind.

My current quandaries:
  • Would a single pixel difference work, where four textures at 1023x1023 px would fit into a 2048x2048 atlas?
  • Or, is a single pixel border for all four edges required, where four textures at 1022x1022 px would fit into a 2048x2048 atlas?
  • Or, is there some other specifications hidden inside “borders and other padding” I should consider when optimizing/maximizing my pixel budget?

Comments

  • The key consideration here is mipmapping: when an atlas is mipmapped, the padding size determines how many levels you can use before things start blending together. You can think of it like this: at each level, the padding size is halved. How many times can you halve the paddings before they become smaller than a pixel?

    For example, in the new 3.0 renderer I'm using a padding of 16 pixels that allows using mipmap levels 0-4 without major artifacts at borders.

    When it comes to model rendering there is a slight issue, though: the model shaders don't do any mipmapping at the moment, and consequently the automatic atlas builder uses a padding size of 1.

    The atlases are allocated as 8192 x 8192.

    I'm thinking that to enable mipmapping in models we'll need to use 8 pixel padding so mipmap levels 0-3 are available. (Level 3 is 1/8th of the original size.) My atlas allocator seems to apply the padding on all sides of allocated images, so assuming equal-sized images:
    • 1 image: 8 + 8176 + 8
    • 2 images: 8 + 4084 + 8 + 4084 + 8
    • 3 images: 8 + 2720 + 8 + 2720 + 8 + 2720 + 8
    • 4 images: 8 + 2038 + 8 + 2038 + 8 + 2038 + 8 + 2038 + 8
    • 5 images: 8 + 1628 ...
    • 6 images: 8 + 1356 ...
    • 7 images: 8 + 1161 ...
    • 8 images: 8 + 1015 ...
  • Fantastic! This is great. Thank you @skyjake
  • @skyjake
    Are the mentioned artifacts at borders due to compression, resampling, or something like that? My model UVs/textures have some padding and currently have a base size of 2048x2048 so I don't foresee any problems but I'd like to be sure.
  • They are due to downsampling: when scaled small enough, the neighboring image starts blending into the edge.
  • Okay. That's good. Thanks again!
  • @NiuHaka are you able to share some examples once you have got everything looking good?

    I'm sure it can help us improve the dhmp
  • @KuriKai
    If you are referring to when I mentioned my current UV/texure sizes, those don’t have mipmapping yet. I was simply stating the current texture sizes to help illustrate that artifacting at the lower mipmapping levels shouldn’t be much of a concern for myself, partly because of the padding I built into the model UV maps.

    If you’d like, I could create a mipmapped version of my textures so you could see how that would effect artifacts from downsampling. At different levels/distances. That could be helpful since presently it isn’t something we can test in DE2.
  • that would be great
Sign In or Register to comment.