Hi,

I am looking for a tool capable of generating texture atlases. The intended usage is terrain texturing, which naturally must not suffer from the well known problem of bleeding. In that regard, I really like the solution described here: https://mtnphil.wordpress.com/2011/09/26/terrain-texture-atlas-construction/
Also, direct support for various formats (DXT1, DXT5, BC5 etc.) would be nice but that could be deferred to another tool. Plus, a configurable layout would be a handy feature too.
Now, does such tool exist or should I write my own one ? I looked everywhere for one but could not find any suitable.

Thanks!

I should have been more specific. I am still targeting DirectX 9, so I cannot use texture arrays.
The tools recommended above are simple texture packers and ignore the issue of colour bleeding for wrapping, mip-mapped textures.
It is probably wise to write my own tool for texture processing, considering that I will need additional engine-specific features in the future.
Cheers.

It is probably wise to write my own tool for texture processing,

Not if you still think texture-atlasing will solve your problems.

You just said it yourself:

ignore the issue of color bleeding for wrapping

As I said in my original reply there is no wrapping with texture atlases.

Assume your grass image is from U = 0-0.5 (both directions—it takes a quarter of the texture). The hardware isn’t going to wrap 0.6 down to 0.1 for you—0.6 is a valid coordinate as far as the hardware is concerned and the only result you will get is to bleed into the rock texture sitting next to the grass texture.

How are you going to get the hardware to wrap coordinates above 0.5 back to 0.0? Manually? That’s likely slower than just using 4 smaller textures and letting the hardware wrap them all.

As I said, keep your textures in the 0-1 range and let the hardware wrap them. If you can’t use arrays, use texture slots.

L. Spiro

I am well aware of the technical limitations of texture atlases vs arrays vs slots. In the case of texture atlases, naturally I would manually unwrap the texture coordinates in the pixel shader and use tex2Dgrad (or equivalent function) for fetching the data. This approach has been used for more than a decade by tons of engines; I am simply looking for an existing bleeding-aware tool to pack textures.

Simple slots are not a solution in my case, as I want to support 64 textures and I want to dynamically fetch different textures per-pixel based on a material mask.

I would manually unwrap the texture coordinates in the pixel shader and use tex2Dgrad (or equivalent function) for fetching the data.

Do you have any idea what that entails? 64 unwrappings requires 64 specific start-end coordinates and the 64 manual wrapping calculations associated with each.

This approach has been used for more than a decade by tons of engines;

Then why this:

I am simply looking for an existing bleeding-aware tool to pack textures.

So many engines for so long, why doesn’t such a tool already exist?



Would it be wise for you to make your own solution? Not sure, because:

I want to support 64 textures and I want to dynamically fetch different textures per-pixel based on a material mask.

You never identified texture filtering as your main problem, and instead blamed texture wrapping.
If you’re already comparing your solution to an existing one’s, the bleeding is not caused by wrapping (it would be though), it is caused by bilinear-filtering.

I’m not sure you can make a better tool than one that exists because I am not sure you understand what is causing the artifacts you are seeing.

L. Spiro