• Advertisement
Sign in to follow this  

Texture atlas generator

This topic is 1145 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

Share this post


Link to post
Share on other sites
Advertisement

Well, from a technical point of view it is better to not use a texture atlases but an array texture (if supported by the targeted hardware). It requires all textures to be of the same size, but  that is probably okay anyway for your use case. It avoids bleeding from the beginning because each texture 2D has its own level. It further does not need a tool to be used to bake the texture. Maybe it is an alternative for you, too!?

Share this post


Link to post
Share on other sites
Listen to haegarr. Texture atlases don’t apply to terrain (except perhaps in 0.0001% of cases). You need to be able to wrap/repeat the textures, meaning the textures need to cover the 0-1 UV range. Texture arrays are for what you are looking.


L. Spiro Edited by L. Spiro

Share this post


Link to post
Share on other sites

One texture Array for texture and one texture array for mask in greyscale and you got it working.

Edited by Alundra

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement