Author Topic: Performance and Optimization Guidelines  (Read 33669 times)

Hello,

We have updated the performance and optimization guidelines for creating substance files. Please check these guidelines for general optimizations, mobile and usage of embedded bitmaps.

https://support.allegorithmic.com/documentation/display/SD5/Performance+Optimization+Guidelines
Last Edit: August 03, 2018, 05:07:48 pm
Head of Substance Demo Art Team
the3dninja@adobe.com
Twitter: The3DNinja

What about performance inside the editor?
I am suffering massive slowdowns when working with substances inside Unity...
I have 36 materials inside Substance archive and it takes 20-30 seconds to add/delete another material to container
In the future I will need more than 36 per archive
Anything I can do to speed up the workflow?

Also I don't understand why it regenerates all materials after I've remove/add 1 from the archive
Last Edit: January 06, 2017, 05:37:31 am

I recorded video of how my routine looks like to make a copy of material inside archive, rename it and change output resolution.

It takes 2:30 minutes per material just to duplicate and change name. I am not talking about tweaks and changes. Every time I select object other than current substance material it will start updating it and I have to stare at beachball for half a minute.

Our base of substance materials is only going to grow and I can't imagine how much time it will take to maintain in the future...

I recorded video of how my routine looks like to make a copy of material inside archive, rename it and change output resolution.

It takes 2:30 minutes per material just to duplicate and change name. I am not talking about tweaks and changes. Every time I select object other than current substance material it will start updating it and I have to stare at beachball for half a minute.

Our base of substance materials is only going to grow and I can't imagine how much time it will take to maintain in the future...

Hi,

Thanks for posting this information and video. I have sent this to the engineers. We are discussing this internally. At this time, I would suggest that you do not create a single sbsar file with many materials. This may not be practical for your workflow but optimization wise it's better to have a single graph per sbsar until we can get this worked out.

Cheers,
wes
Head of Substance Demo Art Team
the3dninja@adobe.com
Twitter: The3DNinja

Thank you Wes,
I'd love to split archives into smaller ones. However I am not too sure what would be the impact on memory when built to device.
For both build size and memory usage during substances generation at runtime.

Do you happen to know if 20 sbsar archives with 1 material in each would equal to 1 sbsar archive with 20 materials inside?
I think this kind of information would be very useful in your optimisation guide if there is any difference in performance outside the editor

We are not using embedded textures. Only link them in Unity like on screenshot
Thank you

Thank you Wes,
I'd love to split archives into smaller ones. However I am not too sure what would be the impact on memory when built to device.
For both build size and memory usage during substances generation at runtime.

Do you happen to know if 20 sbsar archives with 1 material in each would equal to 1 sbsar archive with 20 materials inside?
I think this kind of information would be very useful in your optimisation guide if there is any difference in performance outside the editor

We are not using embedded textures. Only link them in Unity like on screenshot
Thank you

Hi,

Talking with the devs, there shouldn't be any impact by having 20 sbsars vs 1 sbar with 20 materials. The loading and unloading of the textures will be much faster in the editor with a single sbsar for each material. This is something we will be looking into for an sbsar file with multiple materials. I always use single sbsar files. This allows me to more easily work with updates to the sbsar file as well.

Cheers,
wes
Head of Substance Demo Art Team
the3dninja@adobe.com
Twitter: The3DNinja

Thank you,
this is very good to know.

Another finding we've got related to this issue.
Substance archives with "too" many materials inside (in our case 54) made Unity hang while making build on OSX and crashed on Windows.
We are quite sure that substances caused that as after removing substance archives builds were successful.
We suspect that it's not issue with a single big archive but rather several archives like that.

When we build 2 archives (32 materials inside each) + 2 archives (54 materials inside each) then Unity crashes
When we build 2 archives (32 materials inside each) + 1 archive (54 materials, either of the two) then build succeeds

Obviously I'll go and split archives into smaller ones now, just wanted to let you know.
We are on Unity 5.5.0p3 on both Mac and Windows

Thank you!

Thank you,
this is very good to know.

Another finding we've got related to this issue.
Substance archives with "too" many materials inside (in our case 54) made Unity hang while making build on OSX and crashed on Windows.
We are quite sure that substances caused that as after removing substance archives builds were successful.
We suspect that it's not issue with a single big archive but rather several archives like that.

When we build 2 archives (32 materials inside each) + 2 archives (54 materials inside each) then Unity crashes
When we build 2 archives (32 materials inside each) + 1 archive (54 materials, either of the two) then build succeeds

Obviously I'll go and split archives into smaller ones now, just wanted to let you know.
We are on Unity 5.5.0p3 on both Mac and Windows

Thank you!

Thanks for the detailed information. This is very helpful for us. We have a ticket to look into this issue with the plugin.

Cheers,
wes
Head of Substance Demo Art Team
the3dninja@adobe.com
Twitter: The3DNinja

We are having similar slow down problems when having many sbsars with multiple instances inside. I can see that with unity 2017.3 the materials inside the substance are saved in the .meta file of the sbsar which explains why they all reload when a new one is added or an old one is tweaked and this will probably be very difficult if not impossible to workaround as long as these are kept inside the meta file.
Newest unity version support asset dependencies so it should be possible for materials to be saved as individual separate assets which depend on the sbsar asset - this should make authoring the materials much faster and it wouldn't matter how many of them there are per sbsar. Unity's support for asset dependencies means that if the sbsar changes, the materials will automatically get reimported as well.
In the new 2018.1 plugin importer is materials still written in the sbsar.meta file or are they standalone assets?

We are having similar slow down problems when having many sbsars with multiple instances inside. I can see that with unity 2017.3 the materials inside the substance are saved in the .meta file of the sbsar which explains why they all reload when a new one is added or an old one is tweaked and this will probably be very difficult if not impossible to workaround as long as these are kept inside the meta file.
Newest unity version support asset dependencies so it should be possible for materials to be saved as individual separate assets which depend on the sbsar asset - this should make authoring the materials much faster and it wouldn't matter how many of them there are per sbsar. Unity's support for asset dependencies means that if the sbsar changes, the materials will automatically get reimported as well.
In the new 2018.1 plugin importer is materials still written in the sbsar.meta file or are they standalone assets?

HI,

I'm very sorry for this late response. I wasn't able to answer this until now as we need to progress on the 2018.1 plugin. The new plugin uses scriptableObjects, so they won't be saved in the .meta file. With this, we do not expect the slow down you have experienced to occur anymore.

Cheers,
Wes
Head of Substance Demo Art Team
the3dninja@adobe.com
Twitter: The3DNinja

That's great news. Looking forward to trying it out.

This is not necessarily a bug, but rather a workflow and documentation suggestion. Here's what I've found:
1. I made materials in Substance Designer, and exported .sbsar files to Unity.
2. Using the latest plugin from the Unity Asset Store, I imported the .sbsars into a Lightweight project.
3. I linked the generated textures from the .sbsars to Lightweight Standard materials, using the Metallic/Smoothness workflow.
4. I found that the normals in the .sbsars were inverted.

Here's the fix:
1. In Substance Designer, set Normal nodes to use OpenGL format.
2. Add a Normal Invert before the Normal Output, inverting the green channel.
3. Re-import if needed.

I'd suggest that until the Unity plugin supports the Scriptable Rendering Pipeline fully, that this be added to the docs' section on LWRP/HDRP for clarity.


This is not necessarily a bug, but rather a workflow and documentation suggestion. Here's what I've found:
1. I made materials in Substance Designer, and exported .sbsar files to Unity.
2. Using the latest plugin from the Unity Asset Store, I imported the .sbsars into a Lightweight project.
3. I linked the generated textures from the .sbsars to Lightweight Standard materials, using the Metallic/Smoothness workflow.
4. I found that the normals in the .sbsars were inverted.

Here's the fix:
1. In Substance Designer, set Normal nodes to use OpenGL format.
2. Add a Normal Invert before the Normal Output, inverting the green channel.
3. Re-import if needed.

I'd suggest that until the Unity plugin supports the Scriptable Rendering Pipeline fully, that this be added to the docs' section on LWRP/HDRP for clarity.


Hi,

Thanks for reporting this issue. I can't seem to repro this using the LW pipeline. In Designer we default to DX and the plugin does invert the normal internally. It seems to be working for both HDRP and LWRP in my tests. I did notice that I needed to set the packing on the metallic channel when using LWRP using the drop down menu and selecting smoothness.

Are you on Mac or PC?

Cheers,
Wes
Head of Substance Demo Art Team
the3dninja@adobe.com
Twitter: The3DNinja

Sorry for the delay in replying. I work on both Mac and PC, but I first noticed this issue on my PC. I'll repro and upload video.
-Adam

Hi,

Thanks for reporting this issue. I can't seem to repro this using the LW pipeline. In Designer we default to DX and the plugin does invert the normal internally. It seems to be working for both HDRP and LWRP in my tests. I did notice that I needed to set the packing on the metallic channel when using LWRP using the drop down menu and selecting smoothness.

Are you on Mac or PC?

Cheers,
Wes

I think I also have troubles with my normals in Unity (using HDRP).
When publishing the .sbsar-file (leaving the normals at default - DirectX) the normals are not shown correctly (at least in my opinion). No automatic conversion.
https://imgur.com/a/b5R6C37

Here's the fix:
1. In Substance Designer, set Normal nodes to use OpenGL format.
2. Add a Normal Invert before the Normal Output, inverting the green channel.
3. Re-import if needed.

This work around didn't work for me either with the same result as above.

What worked was to expose the parameter to switch from DirectX to OpenGL directly in Unity. Then the normals looked right for me (please correct me if I'm wrong).
https://imgur.com/a/EyQmvKB

I just want to make sure to follow a correct workflow  :)
Last Edit: July 09, 2019, 03:03:49 pm