How does unity handle the uv coordinate inconsistency across different API?

[ZenTeapot]

From a user’s perspective I haven’t done anything special to mesh uv, neither did I do special conversion with normal texture sampling. I wonder how unity hides the uv inconsistencies.

A few things I looked, but none seems like a good solution:

1. texture matrix. I saw opengl and dx9 with this api to apply a texture matrix during sampling, but didn’t find the counterpart for dx11 or metal. Maybe this is not a universal thing?

2. special macro UNITY_UV_STARTS_AT_TOP. I searched the unity builtin shader code base, it’s only used in very rare occasions.

3. Compared the compiled shaders for gl and other apis, there is no generated special conversion code either.

So how does unity do it?

[bgolus]

@ZenTeapot

1. texture matrix

This is a legacy fixed function GPU thing. Unity doesn’t support texture matrices anymore.

@ZenTeapot

2. special macro UNITY_UV_STARTS_AT_TOP.

Used for reading from render textures. Stuff gets complicated here because how OpenGL renders to a render texture, and how that render texture is read are different than basically all other Graphics APIs. So Unity does a lot of work to make everything else match OpenGL, to varying degrees of success. It doesn’t help that OpenGL itself isn’t consistent. But that’s a longer topic.

@ZenTeapot

3. Compared the compiled shaders for gl and other apis, there is no generated special conversion code either.

Yep, the shaders stay the same, ignoring UNITY_UV_STARTS_AT_TOP and some related stuff. When it comes to a basic shader on an object in the scene, there’s no difference to the math in the shader or the vertex data on the meshes.

@ZenTeapot

So how does unity do it?

Unity flips the textures upside down before uploading them to the GPU for all non OpenGL platforms.

Yeah, that’s it. If you use something like RenderDoc or some other external GPU debugging / profiling tool and look at the textures, they’re all upside down. A nice benefit of GPU compatible image formats is they’re all relatively trivial to flip vertically without having any affect on the image quality. Uncompressed textures you have to reorder all of the pixels row by row, which you can do by just sorting each row’s range of bytes. Compressed formats you do the same, but then you also need to go block by block and flip each blocks’ index, which is a bit more work, but still doesn’t require fully decompressing the and re-compressing the image to accomplish.

[ZenTeapot]

@bgolus

This is a legacy fixed function GPU thing. Unity doesn’t support texture matrices anymore.

Used for reading from render textures. Stuff gets complicated here because how OpenGL renders to a render texture, and how that render texture is read are different than basically all other Graphics APIs. So Unity does a lot of work to make everything else match OpenGL, to varying degrees of success. It doesn’t help that OpenGL itself isn’t consistent. But that’s a longer topic.

Yep, the shaders stay the same, ignoring UNITY_UV_STARTS_AT_TOP and some related stuff. When it comes to a basic shader on an object in the scene, there’s no difference to the math in the shader or the vertex data on the meshes.

Unity flips the textures upside down before uploading them to the GPU for all non OpenGL platforms.

Yeah, that’s it. If you use something like RenderDoc or some other external GPU debugging / profiling tool and look at the textures, they’re all upside down. A nice benefit of GPU compatible image formats is they’re all relatively trivial to flip vertically without having any affect on the image quality. Uncompressed textures you have to reorder all of the pixels row by row, which you can do by just sorting each row’s range of bytes. Compressed formats you do the same, but then you also need to go block by block and flip each blocks’ index, which is a bit more work, but still doesn’t require fully decompressing the and re-compressing the image to accomplish.

Thanks a lot for this. Indeed a simple flip would do magic in my case.