Purpose of this PR

Fix shader compilation errors with DOTS_INSTANCING_ON variants. This issue has been introduced a few weeks ago with #5842. However, no one noticed it because of a C++ side bug causing some shader errors not to be logged anywhere. A trunk PR fixing this recently landed and caused these shader compilation errors to become visible (case 1367936). Also, the pathological shader variants were in fact not used at all, which is why we didn't notice any rendering or picking issue :D

Now regarding the problem itself:

• The UnityPerDraw cbuffer doesn't exist with the DOTS_INSTANCING_ON shader variants, which means that unity_ObjectToWorld and friends don't exist as shader constants either. That kind of per-entity data needs to be loaded from the GPU buffer unity_DOTSInstanceData. This is done with a few helper functions that are called when using the UNITY_MATRIX_M macro. unity_ObjectToWorld should never be used directly as a shader constant with DOTS_INSTANCING_ON variants.

• The macros used to fetch per-entity data like UNITY_MATRIX_M don't need, and should not be re-defined by the picking header when using the DOTS_INSTANCING_ON shader variants. It needs to be like this to match the way BatchRendererGroup objects picking is handled on the C++ side.

Testing status

• Manual testing: Building/Running BatchRendererGroup_HDRP + Run BRGGameObjects in Editor

• Yamato PR HDRP on trunk green except for the following:

  • Fail on master as well:
    HDRP on Win_DX11_playmode_mono_Linear on version trunk
HDRP on Win_Vulkan_playmode_mono_Linear on version trunk
HDRP on OSX_Metal_playmode_mono_Linear on version trunk
HDRP on Linux_Vulkan_playmode_mono_Linear on version trunk
Find missing docs - hdrp
  • Instability on master, fail on this PR
    HDRP_DXR on Win_DX12_playmode_mono_Linear on version trunk

• Yamato BatchRendererGroup on trunk green