Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - andy.dys

Pages: [1] 2
I have tried destroying the textures and the substance and they disappear visually as anticipated and yet they seem to still be in memory? Any help would be greatly appreciated. Are Asset Bundles the only way to handle this situation?

Worth noting I believe this behaviour is the same on all platforms, it's just that I noticed it first on iOS where there is a greater limit on resources. Thanks, A

I have just ported my old 2017 project to use the plugin version (2.5.4) in 2020.3 LTS.
Everything works as expected on PC, however I recently tried it out on iOS and discovered that every time I instantiate a substance and set its unique parameters it is cached. This is fine in the sense that I do occasionally need to re-use/modify the substance during the session. However what is not fine is that every time I load a new scene with a new set of parameters the old substances remain cached. Even when I reload the same scene a second time it creates completely new instances rather than using the ones from initial creation. Of course this eventually leads the system to run out of memory and crashes the App.
In lieu of there being any comprehensive instructions or documentation for the Unity Substance API, could someone let me know the best way to clear the substance cache every time I load a new scene? I did read in another thread that you can use asset bundles but this would appear to be a very ad-hoc approach. Surely there is a better way?
I hope you can help,
Thanks, Andy

Substance Integrations - Unity - Unity 2.5.2 plugin issues
 on: August 12, 2020, 07:59:22 am 
Hi there,

I'm having several issues with 2.5.2.
Unfortunately I can't tell you at what point these issues occurred only that they are in 2.5.2 while running Unity 2020.1.1 f1

The first problem is that none of my output textures get assigned to the material / shader input slots. I have 2 outputs from my substance, diffuse and normal. I can assign the correct output textures to the correct shader input slots in the editor, but the moment I click away from the material it resets to no texture assignments. This used to work when I first tried the plugin implementation in Unity 2018 a few months back.

Next issue, all procedural material instances no longer allow me to see the material properties at runtime. It just says 'No Shader Selected".

Finally 2.5.2's release notes mention the inclusion of the "IsProcessing" function. I cannot find said function anywhere in the  documentation or the visual studio autocomplete fields. So I'm not actually sure if it's really there, or if it is, where it has been moved to. Presumably it should still be a bool that return true until the substance has finished running changes?

Any help most welcome.

Ok, tell a lie. I'm still getting issues in 5.5, they just seem to be less frequent. Same crash however, app freezes during texture rebuild. I went back to 5.4 and noticed generation was a lot more responsive/ quicker and there are no crashes, even after more extreme and heavy testing. There's definitely something wrong in 5.5/5.6 on iOS.
I also noticed that when I remove some hacks in my code to fix a bug introduced in 5.4 that there are still issues in 5.5 and 5.6 that were supposed to be resolved.
The bug I'm referring to is "Substance: Fixed SubstanceImporter.ExportBitmaps generated file names."
In 5.4 I have to create the materials on a surrogate game object that ultimately gets destroyed before running a search to find my generated textures and assigning them. Where as in 5.3 I could take them directly from each individual procedural material instance, nice and clean.
In 5.5 and 5.6 I can get away without using the surrogate but still have to use the search to find them which is strange.
Anyway I'm going to have to build a repro project to get to the bottom of what's going on. It will no doubt take me some time to remove all my proprietary assets and make sure I can reproduce the bug. So it might be a few weeks / month  before I can get around to it. In the meantime in order to remain productive I shall have to return to the relative safety of 5.4. :( Part time solo indie dev sucks when there are so many issues between versions. I guess it's unavoidable when there are so many parts and platforms to manage. Just when I thought I'd resolved all the other issues / alterations in 5.5 and 5.6.  ::)  :'(

Ok, so far so good no errors or crashes in 5.5.3p3. I need to do some more tests but appears to be exclusive to 5.6 or a more limited number of the more recent 5.6 versions. I'll keep you posted.

Hi Keston,

Thanks for your response, so far I'm completely stumped. The app just freezes (locks up without hope of recovery) intermittently (i.e. not the first rebuild but anywhere between the 4th or 10th texture rebuild, so it's not 100% predictable)  I'm going to try rolling back to 5.5.3p2 to see if I get the same problem, might help pin point a change in the system that caused this bug to creep in.

Actually you might be able to help in this regard. Do you know any particular releases since 5.4 that had any major substance tweaks that would be worth me focusing on?

Thanks again for your support.


Hi there,

As the title suggests I'm getting a nasty crash exclusively on iOS since upgrading to 5.6.0p3 that's not producing any error messages in xcode.

I can only assume that it's an issue with substance integration since it crashes at the point where I'm either about to or during rebuilding of my procedural materials. I'll probably need to put together a repro project.

But in the meantime any advice on getting an error message in xcode or any news of others suffering similar issues would be greatly appreciated.

Many Thanks,


Thanks Camille, really appreciate the support. I know this stuff is difficult to estimate, but do you think a fix will make it in the next couple of weeks or are we looking at a month +.

Thanks again.

Ok, so I've tried it and it almost works. The instance does finish processing and changes now update correctly but only for my material ID 1.
Material ID 0 does not update, I haven't had time to do more research, but presumably this is because Material ID 0 is still the original procedural material? No idea why the textures are not updating? Do you have any suggestions?
Out of interest, would you be able to clarify if this is a bug that will be fixed or is the workaround likely to be a safer more permanent solution?
Currently I'm happy to continue to use 5.3.3p2 since there are no new features or bug fixes that I need in later versions. However I'm sure this will change in the non too distant future.

Thank you Camille, I'll give your code a go as soon as I get a chance and let you know how it goes.

And let me add, excellent support so far  ;D

I'll do my best to answer your questions.

1/ There are currently never more than 12 instances at one time, the co-routine only ever runs once on startup (so can run simultaneously for up to 12 instances) and then after that only if modifications are made by the player which can only ever effect one instance at a time.
2/One instance takes less than 0.2sec on a mediocre PC, but up to 1.5 sec on an iPhone 5S, or thereabouts.
3/As mentioned in the first answer, up to 12 simultaneously on start, and no more than once when players make changes after.
4/ I never use sharedMaterial as I want to keep the instances unique. Although I do use renderer.materials [] as there are more than one material ID that I'm applying to.

void ApplyLODTextures()
        Texture SpecTrans = ProceduralBody.GetGeneratedTexture("Substance1_Specular");
        Texture Diffuse = ProceduralBody.GetGeneratedTexture("Substance1_Diffuse");
        Texture Normal = ProceduralBody.GetGeneratedTexture("Substance1_Normal");

        for (int i = 0; i < 4; i++)
            if (i > 0)
                LODs.materials[0].SetTexture("_Diffuse", Diffuse);   
                LODs.materials[0].SetTexture("_Normal", Normal);
            if (i != 3)
                LODs.materials[1].SetTexture("_SpecTrans", SpecTrans);   
                LODs.materials[1].SetTexture("_Diffuse", Diffuse);

5/ My substances are set to "Build on level load and cache".

Hope that helps, thanks.

Hi Camille,

As per the title I'm using 5.3.5, but I can confirm the issue was introduced for me with the changes made in 5.3.3p3 and remains all the way through to 5.3.5p3, everything works fine in 5.3.3p2.

I can't give you repro case scene but I can give you some code snippets.

IEnumerator UpdateMaterial()
        while (true)
        if (changesMade)

                     while (ProceduralBody.isProcessing)
                          yield return null;
                     changesMade = false;

So I have quite a few procedural material instances in the scene and I need to wait for isProcessing to finish before assigning them.
The above code works on PC both in editor and in built form in 5.3.5 (in spite of isProcessing always returning true, which is strange) however it fails on iOS.
So for now I'm using 5.3.3p2 for my iOS builds.

Hope you can help.


I forgot to say my dodgy fix was to use "yield return new WaitForSeconds (0.8f);" intsead of isProcessing, alas this is of course not satisfactory as you have to set the delay to match your slowest supported device. Not to mention if you generate multiple instances at once textures invariably get assigned long before processing is finished, which makes for some very strange looking models.

I'm having some frustration with isProcessing always returning true.
I think the issue occurred after the Unity 5.3.3p3 updates.

Is anyone else experiencing similar issues?
I read a similar thread from October last year but apparently this bug was resolved?
Has there been a relapse or is my project special :).

Really appreciate any help. Currently using some dodgy code to patch the leak.

Hi Eric,

That info is music to my ears, now I know how the textures are assigned and that I have 4 automatic slots to play with I hopefully won’t need to worry about the substance resetting after run time tweaks ;D.
Lastly could you possibly reconfirm that there is no performance benefit to setting source textures to relative to parent?
 Say you want your substance to run on multiple platforms, sometimes you want the source to be 2048 and other times 256 depending on the system. If those textures are relative to parent does it reduce the step of re-sizing the textures every time a change is made? Performance feedback within substance designer would seem to indicate it yields a small advantage, although not sure how reliable this info is or if my tests are sufficiently robust. I appreciate absolute is much easier to work with, I’m just trying to speed up generation on low end devices while maintaining a singular source. Mind you having written that last sentence it would probably be even more efficient to have a separate substance for each resolution/platform such that the .sbsar file would in turn be smaller for not having to carry the full resolution resources…
Anyway your thoughts would be appreciated.
Many thanks,


Pages: [1] 2