All localized objects have a pink material.

Hello,

We are using this script to localize our materials:
LocalizeMaterialEvent

[AddComponentMenu("Localization/Asset/Localize Material Event")]
public class LocalizeMaterialEvent : LocalizedAssetEvent<Material, LocalizedMaterial, UnityEventMaterial>
{
    [SerializeField] private MeshRenderer _renderer;
    [SerializeField] private int _materialIndex;

    private void Awake()
    {
        if (_renderer != null)
        {
            OnUpdateAsset.AddListener(SetMaterial);
        }
    }

    private void SetMaterial(Material material)
    {
        if (_renderer.materials.Length <= _materialIndex) return;
        
        var materials = _renderer.materials;
        materials[_materialIndex] = material;
        _renderer.materials = materials;
    }
    
    public void SetLocalizedMaterial(LocalizedMaterialAsset localizedMaterialAsset)
    {
        AssetReference = localizedMaterialAsset.LocalizedMaterial;
    }
}

After updating the localization package from 0.11.1-preview to 1.0.3 (Unity 2019.4.26f1), we are receiving the following AssertException messages:

These all come from the game objects that have the localization script.

And also, for certain game objects, the materials are missing (if the same material is assigned manually during play mode, it looks okay):

It happens only if using existing build in Play Mode Script.
Using the analyze tool to fix things didn’t help.
Downgrading back to 0.11.1-preview helped me get rid of the errors. The pink materials are still there though.

Thats strange. I have seen some issues with upgrading but not been able to get hold of a project that shows it yet. Are you able to file a bug report?

Yes but unfortunately I cannot share the project.

Another thing to note is that this error seems to happen only in the Windows editor. The materials are fine in a Mac one.
And yeah, the materials are set correctly on the mesh renderer, the textures are set correctly but the instanced material look pink in the editor. Manually assigning a new one from the project folder, makes it look correct.

The answer of this post fixed the issue for us about the pink materials but this is definitely not optimal and still seems like a bug. It seems like the old issue described in that post is still lurking around.

In the Android build the materials are fine even without the workaround.

Thanks. I cant see any actual bug reports in that linked thread so have nothing to chase up. Are you able to file a bug?

Done. Case 1372477

1 Like

I’m somehow back to the issue where in some scenes I get the AssertionException. No pink materials because I am using the shader fix code referenced above. The materials simply do not change. I figured out that this is not scene related but rather table related.

The failure happens in DetailedLocalizationTable.SharedEntry.get where the Assert.IsNotNull(Table) is done.
For some tables this works and for some it doesn’t. For those tables where it doesn’t work, it doesn’t work for any entry and for those where it does work it works for all entries.

I attached the debugger and this is what I can see:

On the left we have an example of an entry being loaded and it fails. On the right it succeeds. Both states are taken at the same Assert.IsNotNull() call.

All of the table files exist, the id-s and file references in the .asset files seem to be correct as well. Note that for the failure case, the AsyncOperation is not null but the progress is at 100% and it was even able to load the material.

Any ideas?

Unity 2021.2.0f1, Localization 1.0.5, Addressables 1.19.11.

Thats strange. Can you check if the SharedTable data is marked Addressable? Also worth running the analyzers as they also check this.

The Shared Table Data asset is marked as addressable. According to the analyzer there are no fixable errors, only unfixable ones:
7658095--955534--upload_2021-11-15_15-14-55.png

That looks fine. Im not sure why this would happen, my best guess is the SharedTableData asset is not being loaded but I dont know why that would be. It’s a separate asset that is stored in a different Addressable group by default. Are you able to file a bug report? It looks like it will need debugging to figure out whats going wrong.

But why would it be an issue only for some localization tables and not for others? Funny thing, I also made a completely new asset table with the exact same keys and I got the same errors. I will try to change the keys and see if it gives different results.

The issue with filing a bug report is that the project is >10GB and we don’t really feel like sharing it. Is there a way for you to debug in my computer remotely?

Also, what do you suggest for me to debug if I were to try it myself? Where should I start my search? What should I look for? Perhaps I can find the reason, as it is quite important for us to get this working very soon.

I’m not sure why it would be only certain ones, I would guess it’s not loading the shared table data but I don’t know why.
Do you get the errors in a new project?

It could be in addressables in which case I can’t really say where to start. When the error happens can you check to see if the table has a shared table data? Maybe it’s getting loaded after the table has been loaded.

I will test a new project.

Here’s an image of a faulty table having shared table data. Note that the key does exist in the shared table data but is not in the table’s own results.
7658248--955603--upload_2021-11-15_16-15-5.png

Edit: It works fine in a new project. : /
Edit2: I just discovered that when I create a new empty scene in my main project and try to get the material localization working on a cube, it works. The scenes where the materials are used are loaded additively, perhaps that’s where the issue lies.

Thats strange. So is it that the Entry Table property is null?
The Entry should be created in StringTable.cs CreateTableEntry:

public override StringTableEntry CreateTableEntry()
{
    return new StringTableEntry() { Table = this, Data = new TableEntryData() };
}

You can see the table instance gets assigned with a this.
So for it to go null is strange. Can you put a Debug.Log inside of CreateTableEntry to check for null?

Are you doing any script calls to the table directly? Like AddEntry or RemoveEntry?
The only places that set the value are when we create it in CreateTableEntry and when we remove it in RemoveEntry.

I was able to reproduce the issue in a new project!

I know how it happens but I don’t know yet why. The issue happens when the tables we are manually preloading in our code, have also the Preload enabled in the table settings (Localization Tables view). Disabling the preloading setting in these tables makes the systems work correctly.

I filed a bug report and attached the project. Case 1381274.

1 Like

Thanks a lot. I have asked QA to escalate the issue.

1 Like