LightLayers with Instanced rendering

Hi, sorry for the very long delay. So yes, sadly the Unity API for everything relying on drawprocedural or draw procedural indirect don’t allow to configure the light layers in HDRP. There is work plan, but will be for 2021 year.

And there is no possible workaround :frowning:

Hi @Shaunyowns , @SebLagarde - circling back because I think that there might be something that caused this issue to resurface. I’ve upgraded my project from HDRP 10.0.0-preview.27 to 10.2.2 (with Unity 2020.2.1f1) and the issue with the lack of light on instanced meshes when using LightLayers is back sadly :frowning:

Could you check this one out? Do I have to submit another (the same) bug request?

@Shaunyowns , @SebLagarde
I submitted another bug report, with the updated reproduction project. It got a case number 1303589. I really hope for the fix since it seems to be a regression. It worked in HDRP 10.0.0-preview.27 and it is broken again in HDRP 10.2.2.

Hi, I experience the same issue.
HDRP 10.2.2
The sphere on the left is created from the editor. The sphere on the right is DOTS entity instantiated from the original but it is not affected by the sky.

That is a different DOTS specific issue. Hybrid Renderer doesn’t yet have proper indirect lighting support.

Thanks for the info, I thought its the same because the same shader worked fine with 2019 + DOTS + Hybrid renderer 1

-    "com.unity.entities": "0.10.0-preview.6",
-    "com.unity.render-pipelines.high-definition": "7.4.3",
-    "com.unity.rendering.hybrid": "0.5.0-preview.6",

I also believe that it is a different issue despite that it seems related.
Nevertheless, my bug report was successfully reproduced and there is a ticket on an issue tracker: Unity Issue Tracker - [HDRP] Instances drawn with DrawMeshInstanced are not lit up when Light Layers are enabled in HDRP settings

I really encourage you guys to vote on it, maybe it will speed up the resolution of this regression.

Indeed, disabling the light layers option in the hdrp settings does not affect my case.

hi @Shaunyowns
any updates on the bug? Is there any ETA?

When was the last email you got from case 1303589?

The last email that I’ve got from case 1303589 was from Jan 5, but this case was a duplicate and was closed in favor of 1268590.

The last email regarding 1268590 was sent to me on Jan 18, but it contains no info besides that there is no ETA atm. I am inquisitive about what to do about it - it blocks me from upgrading, it is a regression, and there is no info. The bug was discovered by me almost 9 months ago :frowning:

I am sorry that this has stopped your work :frowning: I’m looking at the bug ticket too and I do see there are still working on it, so it’s not a case of it being sat in a queue doing nothing. It’ll be a case of remaining patient. The QA team will certainly email you when they have any updates.

Just to add a bit more pressure, this issue really problematic for us too, could you please hurry up and fix this issue and while at it could you please stop adding new stuff that can potentially break useful stuff?

1 Like

@CosmosBear_1 have you voted on the issue on the issuetracker? I don’t know a better way to increase the UserPain value of an issue rather than this.

Hey!

I was trying to workaround that issue for an important milestone build, and I found out that if you disable and enable light layers on your camera frame settings, it kind of return to the previous HDRP behaviour.

Long story short that works for me:

 [RequireComponent(typeof(Camera))]
    public class DemoLightLayersHack : MonoBehaviour
    {
       
        private void OnEnable()
        {
            Debug.Log("Light layer hack applied");
            StartCoroutine(Hack());
        }

        private IEnumerator Hack()
        {
            var camera = GetComponent<Camera>();
            if (camera == null) yield break;
            var cameraData = camera.GetComponent<HDAdditionalCameraData>();
            var frameSettingsOverrideMask = cameraData.renderingPathCustomFrameSettingsOverrideMask;
            cameraData.customRenderingSettings = true;
            yield return null;
            frameSettingsOverrideMask.mask[(uint)FrameSettingsField.LightLayers] = false;
            cameraData.renderingPathCustomFrameSettingsOverrideMask = frameSettingsOverrideMask;
            yield return null;
            frameSettingsOverrideMask.mask[(uint)FrameSettingsField.LightLayers] = true;
            cameraData.renderingPathCustomFrameSettingsOverrideMask = frameSettingsOverrideMask;
        }
    }

ahh, thank you! I’ll try this but only as a last resort. I suppose it won’t work during edit time and so it won’t be really convenient to work with.

I’m going to make a change. org petition, so they fix it… jk, I voted for the issue

1 Like

@UnityMaru how come anyone altered the issue on the issue tracker and changed the regression parameter from yes to no? Afaik it is important for calculating the UserPain and it is clearly a regression. I would really like some explanation over here.

Sorry for the bump, but I think it is okay since no one is answering and this is really disturbing (I mean changing the regression parameter at this point without any explanation).
Maybe @Shaunyowns can take a look?

Still marked as not regession. @Shaunyowns please?