26 minutes ago, JoeJ said:

You would probably globaly use the same modulo, e.g. (1024-32*2), assuming you have 32 texels on the broders. I see to limitations in comparision to your intended wide or high large texture, which would have also only one constant width or height.

But there is no way of automatically knowing which part of the atlas some uv's belong to. I would have to manually assign that.

In the strip atlas I would rarely if ever tile in the vertical direction so no uv' caluations would be needed there. The 3d objects would be exported with the uv's already in place.

Quote

You mean it would limit creativity when level editing? You could automate this, the editor shows one large texture and a tool calculates slicing texture space and adapts UVs. It could even cut meshes if no good solution can be found. This should happen rarely enough to not affect performance.

(Note that i don't really know what you mean with parallax occlusion - in case that matters i might miss something.)

 

Workflow is a big concern to me, I like making it efficient. I will model and texture in 3ds max so I won't have a dedicated editor.

I'm starting to like the idea of having two 1024x8192 textures. What do you think? In the worst case I could go with 4 1024x4096 textures to be safe. That would be 12 textures (4*(diffuse+normal+info)) to manage per level but that is manegable.

8 minutes ago, CarlML said:

But there is no way of automatically knowing which part of the atlas some uv's belong to. I would have to manually assign that.

int arrayIndex = int(u*1024.0) / 1024; u = fract(u);

... ignoring the border stuff but you get what i mean. As long as each vertex in the triangle produces the same index this should work? (never tried myself!)

12 minutes ago, CarlML said:

I'm starting to like the idea of having two 1024x8192 textures. What do you think? In the worst case I could go with 4 1024x4096 textures to be safe. That would be 12 textures to manage per level but that is manegable.

I think living with some limitations is mostly easier than spending too much work to get around them, yes

20 minutes ago, JoeJ said:

int arrayIndex = int(u*1024.0) / 1024; u = fract(u);

... ignoring the border stuff but you get what i mean. As long as each vertex in the triangle produces the same index this should work? (never tried myself!)

 

 

But since tiling is allowed, uv's that belong to different parts of the atlas can be in the same position, so that won't work. Remember I have one big mesh that is already mapped to different parts of the atlas. Your example only works if I export each set of faces seperately and "manually" assign them to the part of the atlas they should belong to.

Quote

I think living with some limitations is mostly easier than spending too much work to get around them, yes

I think the thread is close to reaching its conclusion. 

22 minutes ago, CarlML said:

But since tiling is allowed, uv's that belong to different parts of the atlas can be in the same position, so that won't work. Remember I have one big mesh that is mapped to different parts of the atlas. Your example only works if I export each set of faces seperately and "manually" combine them according to which part of the atlas they should belong to.

I assumed tiling would happen in the v direction, and having triangles spanning two slices in u direction would not be needed.

If you need it, you would need to add duplicated u borders, say of 32 texels each and use  u = (fract(u) * (1024-32*2) + 32) / 1024;

But i'm not sure you can set a different array index per pixel on any hardware efficiently (?)

Preprocessing would be the answer, but... some of work. You might look at Simplygon which is free to use now and has options to merge textures and even materials.

Edit: Of course virtual texturing would be exactly what you want, but i guess hardware support is the same as  16k textures or even less.

Texture coords will cross borders when using parallax mapping. One needs local "atlas coordinates" to calculate the wrapping for each vert but my mesh won't have any such coordinates, it will already be mapped to the atlas. I'm just sayin that determining what local atlas coordinates some uv's belong to can't be done automatically in that case.

I'm not asking for help about how a texture atlas or local texture tiling would work. I understand such things.

In any case I will likely go with 4 1024x4096 textures so i get free horizontal tiling because not having to jump through hoops just to tile some texture is worth lot when it comes to workflow.

Your artists should not have to deal with any texture grouping, even if the only tool is maya or 3dsmax.

Just let them use one material per texture. And when you pre-process the mesh. Merge everything and just add a texture index. At runtime, a texture array is a single texture also, so you are not dealing with N textures either. Or if you go texure atlas, pack the individual texture automatically, do not ask your artists to do it !

24 minutes ago, galop1n said:

Your artists should not have to deal with any texture grouping, even if the only tool is maya or 3dsmax.

 

Just let them use one material per texture. And when you pre-process the mesh. Merge everything and just add a texture index. At runtime, a texture array is a single texture also, so you are not dealing with N textures either. Or if you go texure atlas, pack the individual texture automatically, do not ask your artists to do it !

I'm the only artist that'll be working on this, for now.

The atlas won't consist of combined model textures, rather it will be divided into different materials that parts of the level mesh will reuse all over the place.

The animated models will use unique textures, although models of the same type are batched.

Now that I think about it I can probably live with having many single textures in a texture array. If I automate the loading and export based on material ID's in 3ds max then I won't have to care about if they are many, they will just sit there is some folder anyway... Then I'm not restriced to some textures sizes and can add or remove textures easily. And I get full tiling. Sounds good.

Thanks again!

I just like to point out that Rage and Doom 2016 use very large and rectangle texture atlases on irregular terrain/models (everything on screen pulls from the texture atlas).  If they don't have issues, I do not see why you would.  None of their atlas textures tile either and they don't have bleeding issues at extreme viewing angles.

1 minute ago, Mike2343 said:

I just like to point out that Rage and Doom 2016 use very large and rectangle texture atlases on irregular terrain/models (everything on screen pulls from the texture atlas).  If they don't have issues, I do not see why you would.  None of their atlas textures tile either and they don't have bleeding issues at extreme viewing angles.

I've read that Rage streams textures dynamically so the pixel size of the full atlas might not be so relevant in that case, if they only stream part of it.