17 minutes ago, CarlML said:

but it becomes a headache when dealing with something like an irregular cliff wall that is not easily divided into square chunks.

Can you show and example of your cliff wall or anything. At this point I am stabbing in the dark. 

I want to tile the texture using uv's... If you won't let me have that then there's not much more to say.

22 minutes ago, CarlML said:

If you won't let me have that then there's not much more to say.

What I am pointing out is what your doing isn't normally done. Working with textures this way is could to lead to unnecessary problems.

The question is if it matters, but the answer will always be: it depends.

If you plan on doing this only once or twice then chances are low that it will impact your game. Keep doing with all your textures and you will be wasting a lot of resources. Doing it once already prevents the game from working on all computers.

A atlas is made to map any object and any shape. Texture bleeding only happens when you use poor UV maps or auto UV maps.

I hope that somewhere among this you have found a suitable answer. Good luck with your game.

How would it waste resources? It would in fact save a lot of geometry (and time). The concept itself is solid but the question is if the size of the texture is preventive,  which is why I'm here asking. DirectX 11 is already required for the game so that won't change because of this.

I all you want is pack together 1024 textures to tile. Just use a texture array…

5 minutes ago, galop1n said:

I all you want is pack together 1024 textures to tile. Just use a texture array…

Hmm. The idea is to have one large static level mesh that samples from one texture (atlas). Using texture arrays, you could then perhaps store per vertex which texture each part of the mesh uses? Because I don't want to split up the mesh and generate more draw calls. I'll have to think about that.

35 minutes ago, CarlML said:

How would it waste resources?

It depends again on what your doing.

Lets say your making some kind of scrolling texture, for a background. Then things will be fine.

If your just storing textures into a atlas and they have nothing to do with animating, then your wasting time by making them tile.

However your talking about cliffs and odd geometry. That makes it sound like your trying to tile textures on a mesh. If this is the case then there is no point in tilling the full texture. Only the texture in the mesh needs to tile.

This is a image I made for a other topic, I modeled one corner then tiled it:

That is the texture. Notice how the brick wall is tilling but it's 2048*2048 texture isn't tiling. It is this small to keep texel density with the floor.

When making your UV maps you should leave space between UV maps, for baking and such.

So when using texture atlases for lots of objects we re map the UV to the atlas. When you do this you will discover lots of space cleared up, this is often the small spaces you left on the UV maps.

If you just mapped every texture next to each other for a 1024*16384 texture you waste space, because re mapping your UV will often clear a full texture after the 10th texture: (10% open between mapped objects 10% * 10 = 100% a full texture).

Atlasing 3D models often reduce the needed textures for a full game by twenty or so textures. That is 20 * 4K textures. A lot of resources.

But again, I have no idea why your tiling your textures.

4 minutes ago, CarlML said:

Hmm. The idea is to have one large static level mesh that samples from one texture (atlas). Using texture arrays, you could then perhaps store per vertex which texture each part of the mesh uses? Because I don't want to split up the mesh and generate more draw calls. I'll have to think about that.

What what ? Why would you need to cut  draw calls ? You can store the slice index in the mesh stream, and you are done.

Texture array have nice wrapping properties and you can pick the slice per pixel but restrict over format and size. Atlas have ugly needs for wrapping and mip filtering and also have format restriction.

Ideally, bindless dx12 is the best to access many textures in a single draw call.

How many draw calls are you trying to save anyway ?

You can just store per vertex the slice index, take that advantage by packing your UV in FLOAT16 instead of FLOAT32

Probably many hundred drawcalls can be saved by batching everything. It all adds up and I'm targeting a high framrate.

I have to read up on texture arrays a bit before determining if it's something to use but thanks for the suggestion!

6 minutes ago, CarlML said:

Probably many hundred drawcalls can be saved by batching everything. It all adds up and I'm targeting a high framrate.

I have to read up on texture arrays a bit before determining if it's something to use but thanks for the suggestion!

If the only things that change between your draws are a few texture binding, you can push thousands of draw calls before you start to fill a cost here !

Do not forget, early optimisation is root of all evils. Unless you have decades of experirence at profiling GPUs and Graphics API, It is dangerous to jump into thinking something is fast or slow.

Make your render visually correct first, then optimize based on real profiling if it is needed only.