Emissive Textures generated at runtime don't apply unless inspected

Unity Engine
, ,
1

Hey Team,

I’ve happened across something breaking to my project with regards to both URP and HDRP.

A quick summary of my process;

Bullets travel in a level, causing a glowing light. Rather than using lights since there may be over 3 000 bullets, i’m opting to build a texture, and use the emissive property of the grid.

Generating the texture at runtime, either in Start, Awake or Update is successful, and applies to the material correctly, but won’t be reflected in the Game or Scene views, unless the material is unfurled in the inspector.

This seems to only able to be rendered by inspecting the material, and the same issue happens in Standalone builds, leading to the texture never being rendered (since there’s no inspector)

I’ve attempted recalculating the DynamicGI, and requested the renderer update its GI materials, all to no avail.

I’ve reproduced this in a contained environment on Unity 2019.4.13f1 (LTS) here; GitHub - UserAnon91/UnityEmissionBug: Repository to host the Unity emission bug i've encountered in my original project

This bug is still present on the newest version of unity, with the latest version of HDRP

A demonstration of the perceived bug is here;

The code used to reproduce is simplified here;

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class EmissionBugReproduce : MonoBehaviour
{
    public Material newNewGridMaterial;

    public Texture2D gridTexture;
    public Renderer ourRenderer;

    // I've originally split this into awake or start,
    // then update the texture every 0.1 seconds with the same result
    void Awake()
    {
        gridTexture = new Texture2D(100, 100);

        for (int i = 0; i < 100; i++)
        {
            for (int j = 0; j < 100; j++)
            {
                if (i % 2 == 0 && j % 2 == 0)
                {
                    gridTexture.SetPixel(i, j, Color.magenta);
                }
                else
                {
                    gridTexture.SetPixel(i, j, Color.black);
                }
            }
        }
        gridTexture.filterMode = FilterMode.Point;

        gridTexture.Apply();

        ourRenderer.material.SetTexture("_EmissiveColorMap", gridTexture);

        /*******************************/

        /*
        Additionally, i've attempted to use:

        newNewGridMaterial.EnableKeyword("_EMISSION");
        newNewGridMaterial.EnableKeyword("_Emission");
        newNewGridMaterial.EnableKeyword("_Emissive");
        newNewGridMaterial.SetTexture("_BaseColorMap", gridTexture);

        ourRenderer.material = newNewGridMaterial;

        DynamicGI.SetEmissive(ourRenderer, Color.white);
        ourRenderer.UpdateGIMaterials();
        */
    }
}
1 Like
2

Hopefully I can get a workaround or fix for this as it’s breaking my builds. Does anyone have suggestions on how to fix this temporarily?

3

Y-Hello there,

[Edit] Forgot to ask. Did you try to build the prj? Does it wield the same result?

I’ve tried your script, yes there’s a weird bug but can be fixed with a workaround which is actually better for this case scenario.

instead of:

ourRenderer.material.SetTexture("_EmissiveColorMap", gridTexture);

you can try:

ourRenderer.sharedMaterial.SetTexture("_EmissiveColorMap", gridTexture);

the first is actually creating an instance of the material you are referencing, while the latter is using the actual material you set up.

Idk if that’s the final code, but I wouldn’t create that texture at runtime, just save it and use it.

1 Like
4

Hey @UserAnon91 , I have logged something as it’s indeed surprising that we need to inspect the material for it to be updated in game view. I will update here once we have more info on this.

In the meantime, don’t forget to set your “_EmissiveColor” property to white (it’s black by default), otherwise, even with the sharedMaterial workaround, your emissive won’t show.

2 Likes
5

ok! so i changed it to sharedMaterial and it’s looking like it’s only working in editor when you have the material on the object inspected/uncollapsed.

from the inspector standpoint, making the new instanced material using material.setTexture was collapsing the menu, which had me need to click on the material, but since it’s the same material with sharedMaterial.setTexture, it doesn’t collapse that menu and is always inspected. So by proxy, this is in fact helping, but i need to have the object the material is assigned to inspected and its material panel opened at all times. This is much closer, but still won’t work when the project is built and run.

The code snippet i put here in the original post is a very slimmed-down version of my go-live code for the sake of reproduction, there are reasons i need to edit the texture every n-frames for the sake of game logic, but I don’t need to recreate it every frame, you’re correct.

I’ve uploded a revised version of the bug here;

https://www.youtube.com/watch?v=k8XA-sqdxYA

As for your post @chap-unity , thank you for making a report on it! My emission is set to white on the material at all times,
7107211--847714--upload_2021-5-4_12-48-46.png

Is there anything else that you can think of that might help remediate this issue in the meantime? Progress can technically continue on the project while this bug is affecting me, i’ll need to have an inspector panel locked to have this material showing at all times, but builds aren’t able to contain this core feature i’m working on, which is a shame.

Let me know and thank you for your help so far!

6

@UserAnon91 sorry to read that, I didn’t test it properly.

This is a weird looking bug, good finding, worth of a bug report if there’s none.

Anyhow, I’ve tried also with MaterialPropertyBlock workaround with no success.
The only things that seems to work is to pre-assign a base emissive texture (it could be a white 1x1 px) and than assigning the grid one at runtime, I’ve tested this and it does work in Editor and in Build.

Hopefully is a workaround that works for you until a fix is found.

1 Like
7

WOW, Legend!

So this actually works for me now, with a few notes:

I’ve created a 1x1 #FFFFFF pixel and assigned it to the emission colour texture channel in-editor.

With sharedMaterial, it overwrites this channel, and on stopping play leaves that channel empty because the texture i created no longer exists.

I switched back to material from sharedMaterial, and with the 1x1 white pixel texture in the emission channel, it will load it every time, both inspected, not inspected, and even in builds!

A very strange issue, and the bug still very much exists, but putting a texture inside that channel before runtime seems to be the fix, and as far as workarounds go, pretty mild!

Thank you so very much for your help @M4dR0b , that’s a great in-the-meantime fix for what i’m trying to do :slight_smile:

7108033--847843--EmissiveTextureResult.gif

8

Glad that worked out for you.

That luminous grid is looking dope, are you doing that with unity internal lights or you built your own?

1 Like
9

I’m not using any lights in the scene at all, it’s all emissive using a texture that i update every N seconds. The base is a transparent grid that emits white, then i emit my custom coloured texture via the emission albedo texture.

Each square is recorded by the GameManager and used by the GridCreator to generate a radius per-cube based off its colour.

I bred this from a need to not have several thousand lights i a scene for a bullet hell i’ve been working on. This is much more performant, as you can imagine.

1 Like
10

Got more info on this one !

In the end, there’s no issue, if you want to modify a material property at runtime you need to make sure the feature is enabled in the shader you’re using.
If it’s not the case before runtime (like for example not having a emissive texture) the specific variant won’t be included and you won’t be able to modify it in play mode. (and won’t be included in your unity player as well)

To include the variant, you need to enable the specific keywords that triggers it;
You can find the list by right clicking on the Lit Shader and click edit shader, there you’ll find the list of keywords after #pragma prefixes.

In your case it’s “_EMISSIVE_COLOR_MAP”, and puting this line before editing the “_EmissiveColorMap” field fixes the issue.

this.GetComponent<Renderer>().material.EnableKeyword("_EMISSIVE_COLOR_MAP");

7177072--860434--upload_2021-5-26_10-34-39.png
7177072--860434--upload_2021-5-26_10-34-39.png1258×727 46.9 KB

1 Like
11

oooooh, that is good to know for future reference.

Thanks @chap-unity

12

Yep, we’ll try to include those bit of information in the documentation actually.
It can be useful to some since material edition at runtime is quite common !