I am working with Unity QA to sort out the _CameraSortingTexture issue, and as it seems here is what I found :
The apparent set up is to create a new layer (sorting layer?) in front of the layer that the _CameraSortingTexture is rendering to and use the texture on the objects that is on that new layer which comes after the layer which _CameraSortingTexture is writing to.
So it is :
Layer for rendering _CameraSortingLayerTexture
Layer for any other objects that uses the above texture.
Which is fair enough, but after fiddling with it, I found the following
There is no lighting applied to the _CameraSortingLayerTexture which makes the whole thing kinda useless, because it is not actually capturing the game view like how it is for the grabpass.
Scene view camera is affecting the result of the _CameraSortingLayerTexture which makes the whole process extremely difficult to work with, confusion comes along as to trying to figure out what the hell is happening inside Editor with both game view and scene view open at the same time.
Even with the scene view not visible the result is not what you would expect when you combine the multiple cameras with different renderdata.
It gets worse and confusing when you try and render the _CameraSortingLayerTexture using 2Drenderer lit pass… result is just so confusing and not what you would have expect, because there is just huge difference between rendering it using unlit pass or lit pass.
Nothing really seemed to be documented anywhere to try and figure out how to properly make a use of the _CameraSortingLayerTexture. We need real example project with proper shader that makes use of the _CameraSortingLayerTexture.
Trying to communicate this with QA team does not feel like it is getting anywhere. A proper example project would be appreciated a lot.
Ok, after working more with Unity QA, we have found some working case so I am going to share it here.
You need to create another sorting layer in front of anything that _CameraSortingLayerTexture is being rendered to.
Then the object that uses the _CameraSortingTexture needs to be using that new sorting layer.
The scene camera can still get in a way of working with _CameraSortingTexture in some setups but we are still investigating it.
The one thing you have to watch out for when you are working with this is the sprite group which can mess with the sorting layer and so even if your sorting layer is different, the sprite group can override it.
I still feel like a good example from Unity can benefit everyone on learning how to make use of _CameraSortingTexture.
So right now there is a single texture stored for _CameraSortingLayerTexture, it is captured after a layer is fully rendered and it is expected to be used in the same frame for a given camera. It is allocated as temporary memory and freed at the end of rendering for that camera. I believe _CameraOpaqueTexture for URP does the same thing (but I need to look into this). If you do decide to use this value on the next frame it may work if you are only seeing the game view, but you also might also get garbage if something allocates the memory pointed to by _CameraSortingLayerTexture. If you have a scene view camera open it’s very likely you would get garbage from the scene view.
For the moment, I would like to be consistent with how the _CameraOpaqueTexture works and just see if more time needs to be put into this.
I totally agree with you about samples. Rus and I will be putting together a number of samples for some of the features implemented in 2021.1 & 2021.2. Using _CameraSortingLayerTexture will be one of them. I’m not exactly sure when this will be out, I would suspect there will be an announcement of some sort for it though.
I’ll try and update the docs on this sometime in the next few weeks as well.
As for why the lighting doesn’t get captured, I’m not sure. It definitely should if you have a lit sprite since part of the rendering for a lit sprite include the lighting. It could be a problem if you have volumetric light though as that is rendered separately from the rendering of the sprite.