I'm new, but this still doesn't look right...

[JPHarford]

I’m using v228.2, from Github.

I noticed some significant slowdowns using the editor, even after the initial compilation of all the shaders, etc on first launch. Then I saw mention in a tutorial that slowdowns like this are normal. Problem is, they’re so frequent and so bad that it made me curious about what’s going on. So, I kept my eye on the Task Manager while working with Process Monitor. All I had tried to do was copy a sublevel to override spawns in a map extension, as described in the post about v228.2.

Here’s where my worries were confirmed: https://i.imgur.com/Q40449M.png

My machine should take less than a second to copy a small file. There’s no reason for this machine to slow down for nearly an hour for that. What seems to be happening here is that shaders are compiling when they shouldn’t be. I saw something similar happen the first time I tried to open the blueprint for land spawn volume.

Process Monitor shows that not only are the shaders compiling when they shouldn’t; they’re repeatedly compiling when they shouldn’t. Temp files with the same name, size, and path were being created so many times that I couldn’t even scroll past all of them made in a single second in the SysInternals tool. So, it’s as if the various Shader Compiler threads have a race condition on the hard disk (as opposed to some shared RAM resource). I could be way off; that’s just what it looks like to me.

Is there a way to correct for this? Maybe have shaders simply not compile until the mod is baked?

edit: I should post my specs, so it doesn’t look like I’m just running a slowpoke.

Core i7-3770K @ 3.5 GHz (8 CPUs)
8192 MB RAM
Windows 10, 64-bit
GeForce GTX 660Ti 6056 MB x2 (not currently in SLI)

edit2: Time to make coffee. I called a sublevel a blueprint. It looks like this is a well-known issue, but the solution couldn’t be more vague if it said “check the thing”.

edit3 (last one): Found a workaround! Really simple. Just load the sublevel before copying it. I’m sure there’s something wrong here, but whatever it is, this seems to prevent it.

[JPHarford]

I may have found the cause for this. When splines have a material applied that isn’t marked as being used in a spline, shaders recompile for that object every time anything is done with it. So, copying a level or sublevel with a spline that has this defect, as well as placing actors, working with blueprints, etc etc can trigger a lengthy shader compilation.

https://answers.unrealengine.com/questions/54169/shaders-shaders-compiling-every-time-i-open-a-map.html

Can anybody help out with advice about how to find all the splines in the content browser and blueprints? If I can get a heads up about how to find these without going through all assets one by one, and which files would be needed for the repaired materials, I’ll do the hand work of going through the splines and fixing the materials. I’m just having difficulty finding any kind of convenient way to filter assets for splines. Google isn’t helping here.

This would make modding Ark significantly more approachable. It’s hard to get anything done when shaders recompile with every inhale and exhale.

I’m not even sure if it would be possible to fix this, since “edit splines” seems to be removed from manage mode in the landscape editor. Is there another way to at least get at the materials without having to go through every single asset one-by-one? Heck, I’m not even sure if it’s possible that way. Splines are always procedural, right? But modding Ark is impractical while this problem persists.