We have had an issue for quite some time in the editor, maybe since the very start of 5.0, hard to tell, where if we have many actors loaded, a material instance will stall for a long time when opening, and then have another (smaller) stall when touching the first parameter (but only the first!). This seem to scale exponentially with the amount of actors in the scene, which means in larger scenes it can sometimes take several minutes to open a material instance. Enough time that artists resort to only editing materials in empty levels. I attached an insights capture from the editor of a decent case with a small amount loaded on a rather beefy machine.
[Attachment Removed]
Hi Tor, if you are making edits to specific material parameters, such as static switches, you will cause a recompilation of the entire material. There is some overhead involved in that, but it should not require you to re-allocate a large number of textures, as I am seeing in the trace. Can you please provide some stats about the material you are editing? A screenshot of the material graph and the editor stats window would be really helpful. Also, what parameters are you editing at the time of the hitch?
[Attachment Removed]
Hi,
here is a superluminal capture of opening, changing a float variable, and then closing the material in a smaller level. The switches make sense that they take time and recompile, changing the first float in a material does not.
[Attachment Removed]
Hi Tor,
Thanks for sending over the capture. I will review it as soon as I can. I will be out of town for the next week, so you may not hear back from me until the beginning of December. I hope that is okay for you, but please let me know if you need an answer sooner.
[Attachment Removed]
Hi Tor,
I just had a chance to review your capture. I forgot to mention that the capture needs to be taken in a development build of the editor, so that Superluminal can capture debug symbols. Otherwise, the capture doesn’t seem to have enough information to make any reasonable inferences about what is causing your hitches. Could I possibly ask you to take another capture, but this time with a development build of the editor? I’m sorry for the delay in this matter.
[Attachment Removed]
Hopefully this capture will work!
[Attachment Removed]
Hi Tor,
Unfortunately, the debug symbols still did not appear in the new capture; however, some information is still available in it to get an idea of what is happening. I have attached a few screenshots below, which I have also marked up, to help explain things a bit (hopefully it’s all visible :)).
[Image Removed]
In Sections A and C, the Game thread is put to sleep and intermittently woken up, likely because the editor is running in the background and we only need to draw the UI occasionally. I think we can disregard these two sections for our analysis.
[Image Removed]The screenshot above in Section B is definitely more interesting. Here we can see that once you close the material instance editor, it takes about 9 seconds to compile the shaders for the debug view modes. Do you recall if the material instance you were editing here was overly complex? Could you perhaps send a screenshot of what the material instance graph and its parent material? In the past few months, we have made significant efforts to simplify the complexity of generated material shaders, as we have also observed lengthy shader compilation times from other licensees. I am wondering if this will also be beneficial to you. Are you planning to upgrade your project to 5.8 once it’s released?
[Attachment Removed]
Hi Tim,
Here is a new superluminal capture.
4s-11s - Loading the material.
15s-18s - Change material param.
25s-31s - Close the material no save.
I can see symbols after loading the attached .slp file on a another machine with newly installed Superluminal, empty symbol cache and without any symbolservers.
Thanks!
[Attachment Removed]
Hi Jesper,
Thanks for the extra upload. I am still trying to follow up with some internal developers to determine what can be done about the long wait times. I will let you know as soon as I have some updates for you. I’m sorry for the delay.
[Attachment Removed]
Hello again,
So the dev team has confirmed that the material instance editor stalls are coming from the shader compiler running as the editor is being closed. The stalls are happening because we run a set of light debug shaders to determine crucial settings for the texture streaming system. They are still discussing options to mitigate this stalling, either by doing this work asynchronously or by finding an alternate method to determine these settings. I’ll keep an eye on the discussion and let you know once I have some more updates.
[Attachment Removed]
So the work of opening and closing the material instance editor can be roughly split into two categories: Game Thread synchronization with the GPU to create the preview scene of the material editor (that small window with the sphere when you open it), and secondly, the drawing of the Slate UI. You can see that roughly in the first screenshot.
When you change a parameter in the editor, we need to update the render state to draw the editor’s thumbnail (see the second screenshot). Since the state change occurs along the path of creating and drawing the UI, you notice that the UI is not responding. There is also a chunk of time spent syncing with the GPU, likely so we can grab the rendered thumbnail from it (third screenshot).
I can check with the Slate and Rendering teams if we have made any performance improvements in these areas recently. Still, since you are locking in on version 5.6, you might not be able to benefit from these changes unless you backport those fixes (if they even exist). I hope that helps you gain some insights into what is slowing down your UI when editing your material instances.
[Image Removed]
[Attachment Removed]
Ok, that should work for a temporary workaround. I was under the impression you had locked into 5.6 already, but if you are potentially going up to 5.8, we might have some fixes for this in place by then. Please let me know if turning off the thumbnail does not reduce your wait times, and we can look into further alternatives for you.
[Attachment Removed]
The material was not overly complex, but since instruction count preview is broken in later versions I am not sure what the stats were. However, the core of the issue is that these things scale with scene complexity, not material complexity (which seems very counterintuitive). We are currently not intending to update to 5.8, no.
[Attachment Removed]
That’s interesting. How about the opening of the material, and editing of the parameter? Any insight on those?
[Attachment Removed]
Thank you for this info, I’ll try and disable the thumbnail updates to get rid of some of these freezes since the thumbnail not updating properly is something we can live without.
We are not locking to 5.6 but are in fact on 5.7.2 right now and it seems likely we will go to 5.8 also, we’ll see when we get closer to it.
[Attachment Removed]