Long save times with material instances

[hollow zealot]

Ok, one more try...
I´m still struggling with long saving times for my material instances.
I recently updated to UE 5.4 AND started reworking our Mastermaterial, so it works with nanite tesselation.
So I´m not sure which caused it or wether its unrelated, but material instances derived from that master material have become excrutiatingly slow to save.
Like, from sever seconds to half a minute and more.
It could also be related to source control, recently moved from an online perforce server to a locally hosted version at my homeoffice.

Mentioning this because when I deactivated source control, it looked like it was saving a lot faster, but then that wasn´t consistent.

It also SEEMS like it gets progressively worse.

Deleting the DDC was mentioned before, but I haven´t found a good answer as to where and which DDC to delete so I didn´t dare to do that just yet.

We import+ the master material from a master unreal project containing all template stuff into all our separate unreal projects, in case that matters...

[brave lily]

umm you refer to a singular master material, does that means you have one master material with all the usage flags set?

also source control does slow down some stuff in the editor, but its not going to slow down the saving process and caching of mics per-se

you can turn off the source control integration in the editor

thats what I like to do

prefering instead to just deal with that in windows

deleting the ddc is not going to help you unless you need to free up hard drive space

"We import+ the master material from a master unreal project containing all template stuff into all our separate unreal projects,"

can you be more specific about what your using/referring to? I'm not sure what you mean by "master unreal project"

[hollow zealot]

Sorry, was bit too busy with deadlines...
So.
I dont think it's source control either.
I think I did test it without at some point and it was inconclusive.
I also think it's gotten a lot better since I fixed some compile errors, I still have 2-3 yellow "wrong texture sampler type" style warnings and I still suspect those to slow things down as well.

Our workflow is a but specific to our linear content production pipeline
We don't work on ONE game, instead we have one unreal project per tv show and then one project for each separate animation/job.
Which can amount to dozens of project per year.
We reuse a lot of stuff like master materials, map templates and blueprints and we have all that in the "Master Template" project.
And in order to be able to constantly update it, we set up perforce to import+ those template assets into every new project.

I don't think that's relevant for the saving problem in general.
But I'm pretty sure it started happening when we updated that Master template to 5.4
Although that's also when I started working on the new Master material to include displacement.
A few too many moving parts as always...

[brave lily]

"And in order to be able to constantly update it, we set up perforce to import+ those template assets into every new project.

I don't think that's relevant for the saving problem in general."

I'm not familiar with perforce, is it's 'Import' similar to what svn calls an external?

cause the way we set it up is to have a content plugin for our material library on its own svn, and have that as an external on multiple project svns. this does as you describe and copies it into the working copy, with the added benefit that we can modify and commit to it and it then applies to all projects using it.

Based on what you describe the main thing that comes to mind is if all your projects are using the same shared DDC and when some of them go on different versions or you modify the base mats on some of them, the question is if the shared DDC delineates between those permutations of the assets, if not then I imagine it would replace the previous derived data with the latest, which then creates the potential of when you open a different project that has those 'same' assets in a different state (due to version or mod of base mats) that it checks the cache and sees their derived data is not what is expected and then regenerates it. those every time you open a different project it does this. (this is just an hypothesis and it would need to be tested, you can try turning on the logging to see more info on it): -logcmds="LogDerivedDataCache Verbose"

So I think if the perforce import is just a copy and it doesn't pull in latest from your template project then it could cause this disparity. Cause if it was a content plugin then when you update the projects they all get the same version of the base mats ensuring that the same mic assets will be able to share their derived data.

oh another thing you can try is disabling the target platforms that you don't need, I think this reduces the amount of derived data generated

like for development you can disable all of them except windows, and then have a config on build machine or something that has the additional targets enabled needed when cooking

[hollow zealot]

Yeah, I remember hearing about the content plug-in type setup when I tried to figure out how we should handle that.
Sounds pretty much like what we have though with import plus: for every new project we pull from the master template, so in theory it should always be up to date, plus we can modify it from any new project directly.
Also: The ddc theory would make sense if it mostly happened with existing material instances, but it actually is most prominent with new material instances.
I'll have to check the log ideas and the targets, although I think I already disabled all of them.