Render Texture format is confusing

Hello

In the constructor for render texture i have too overlaods one that gives:

DefaultFormat and one that gives GraphicsFormat

I need (r,g,b,a) with full float 32 precision.

From the options there is:

RenderTextureFormat.ARGB32
GraphicsFormat.R32G32B32A32_SFloat

These are the only two that seem to look 32 bit or something, but i don’t understand why there are different formats - what is a Graphics format and how is that different to a RenderTexture Format? It’s very confusing.

RenderTextureFormat types show (generally) the total bit depth,
GraphicsFormat types show the per component bit depth.

ARGB32 is an 8 bit UNORM per component. You want RenderTextureFormat.ARGBFloat, which matches GraphicsFormat.R32G32B32A32_SFloat.

1 Like

RenderTextureFormat.ARGBFloat & GraphicsFormat.R32G32B32A32_SFloat

Why do they both exist if they are the same?

The RenderTextureFormat enum has been around for a long time. Over a decade now. It’s always been an incomplete list of “common” render texture formats, both in terms of those people might want to use and supported by GPUs. It also tried to be “human readable” for each of the render types in terms of the length of each enum. Over time it’s grown longer and longer as they’ve added more formats, both as they’ve needed them internally and as they’ve been requested by users, but it’s always been, and always will be an incomplete list.

The GraphicsFormat enum is new, added for Unity 2018.2, and is part of the experimental APIs that were added when they were adding the Scriptable Render Pipeline related stuff. It seems to be intended to be a more complete list of all possible formats… though oddly it is still an incomplete list and missing some formats RenderTextureFormat has! It’s also shared between render textures and traditional (2D, 3D, Cube, 2DArray) textures, with most of the formats supported by both. Though all of the compressed formats at the end of the list (DXT, BC, PVRTC, ETC, EAC, & ASTC) cannot be used for a render texture and are for traditional textures only. I assume the goal is for the GraphicsFormat enum to eventually replace the RenderTextureFormat and TextureFormat enums entirely for script based texture creation. I would expect them to keep something like the later two around indefinitely for user facing UI lists, like for render texture assets and the texture importer, though the texture importer already uses an entirely custom list that’s even more limited than the internal TextureFormat enum. That plus it missing some of the special auto “formats” RenderTextureFormat has. Depth, Shadowmap, Default, & DefaultHDR specifically, which aren’t actually specific formats but change based on the rendering API, platform, and project settings.

5 Likes

Ah i see, so is it best to just use GraphicsFormat since that will likely be the end goal unless they decide to make yet another enum in the future ! :eyes: