Question Stop shader graph from recompiling automatically

Hi there

Is there a way to stop Shader graph from recompiling after every change?
It's incredibly disruptive to have to wait for five seconds every time I make a change to even the simplest HDRP graph. I figured simply turning off the Main Preview might do the trick but nope, it still hangs after every new connection.

 

I don't experience of such behaviour.
I need save manually, for changes to be accepted.
Using latests and recent packages.

Maybe you got something else enabled?

 

To clarify, I also need to save manually before my changes appear in my materials. I mean the recompiling of the shader graph preview.

 

looking for same solution, simply changing a node causes "EditorApplication.Update" to pop up for several seconds. I believe it gets worse the longer Unity has been running. (v 2020.2.1f1)

 

I have the same problem with Unity 2020.2.4f1 and ShaderGraph 10.3.1.

It makes ShaderGraph almost unusable with HDRP shaders as every time I make a change it hangs for 10 seconds with the EditorApplication.Update pop up...

 

Same issue here, its unusable

 

How is this still a problem?

 

Gave up and jumped back into ASE. ASE warned me that Async Shader Compilation was enabled and would slow down shader compilation and whaddaya know; with Async Shader Compilation disabled, Shader Graph is now usable. Thanks Amplify.

 

Please Unity add this. An auto-compile toggle like in the Prefab preview for the auto-save. Even small shaders take time to recompile for me and it's *very* annoying to wait 5 seconds after assigning a single value.

 

Same here. Whenever I change something that is hooked to the Master Node, i have to wait 30 seconds total. 15 seconds waiting for EditorApplication.update (which happens twice sometimes). And when I save my changes to see them in the editor, i have to wait again. Though the time it takes seems to worsen the longer Unity is running.
It's almost impossible to work on a shader this way. Also, the waiting times seem to be the worst when working with a transparent surface type.

 

Oh and don't forget InspectorWindow.Repaint when i save the shader, that takes another 15 seconds

 

Also experiencing this problem. Coming from other node based shader editors like touch designer, this is unbearable.

 

Bump. This is extreme productivity killer.

 

I've never had the situation where it didn't compile after every damned changed, even with all previews closed etc.
Personally i've just moved practically everything to subgraphs and with the master graph having all those subgraphs since there it never compiles until you hit save.

I view the results with hitting save in the subgraph when i want to verify the results in the scene view. (This doesnt impact productivity that much since the type of shaders i build rarely show correctly in the graph preview anyways and i have to verify functionality in the scene view anyways.) But it would be faster if i didnt have to move everything into a subgraph always before starting any fast changes.

 

unity, are you listening?

 

bump

 

This is amazingly hard to understand why Unity has not added an auto compile toggle. Do they expect all shader graphs to be small !!! Come on !!!

 

I will add it as a bug on their report site

 

same here with shader graph 14.0.3

 

With a complex Ubershader I am working on my wait time for altering any routing in the graph resulted in over an hour(!) of waiting. The time was rising from 5 minutes up to 10, 20, 40 minutes and this is absolutely unusable. I forget what I was even working on before Unity becomes responsive again.

This is horrednous. I am working in Unity 2021.03

 

I have the same issue now, as my shader graph shader become more complex, the compile time goes exponentially slower

 

How tf is this still a huge issue 3 years down the line?! Over 20s to make any change. When I have 5 new Params to add to the Blackboard, it takes me nearly 30min.
Few minutes (!) to add new variables in the backboard, few minutes to change their names (!!), Few minutes to change their default values (!!!), Few minutes to set the properties to UnExposed(!!!!)...and they are not even yet in the graph. Like, what the actual F***!? Where are the Mods!?
How is this a thing? And my graph is not ridiculously complicated. Neatly grouped in subgraphs.

I don't mind the recompile time when I save the shader.

But as i'm using various custom functions, the preview is not used at all by me. I DON'T CARE bout the preview! Let me turn it off. Let me say, when to update the graph to check for errors or mistakes.

 

Bump. Inconceivable that this hasn't been addressed.

 

Does anybody now how to summon a Dev from Unity to take a look at this thread? I see they answer in various other topics, but here there was no comment from them. How can we get their attention? This is seriously important for me now. Are there any channels of communication for paying users?

Our project is fairly far down the line. I still need to iterate on the solutions I've chosen at the begging of the project...but atm it has become almost unmanagable.

We are at 2021.3. Does anybody know if the 2022.3 version still faces this issue?

 

Yes, we're on 2022.3.4 LTS and this is still very much an issue.

Shader Graph works best if you want to make small shaders with just a few nodes. However, when using it seriously, you'll bump into performance / recompile issues quite rapidly.

I find it astonishing the Unity devs did not test this properly. Or they are aware but think Shader Graph should be used making shaders with 20 nodes max.

 

Because Unity really has a habit of not believing us when we say the UX is sluggish.

You can see the mouse clicks - grey = no click, colored = button held/clicked. Fast doubleclicks may be subtle because the fastest fade speed for the color circle I can set is 100ms.

In the first "attempt", I'm actually using the keyboard; you can't see me having to hit the enter key 3 or 4 times to get the node to load. You can see the first "enter" press in the moment the cursor in the text field jumps to the beginning of the line (which is after navigating with cursor keys - would instantly expect a commit/pick action there)

You can see that after each node is placed or connected, I can move my mouse a good bit before shadergraph updates and becomes responsive again. Then, for another ~1000ms, the frame and reaction times are greatly extended, resulting in a choppy display (when moving nodes or when panning the screen). (that's the Shadergraph bug, I guess)

The memory leaks piling up are also a good indicator to spot the moments where unity actually hung. (wish we could render a small animation in UI thread to illustrate)

Usability wise, there are also a lot of "dead" areas in the searcher dropdown, I occasionally miss the selected item entirely, even though it is highlighted. The more I look at it, I suspect hovever, that the item just being unresponsive despite the highlight+hover state (makes sense in light of the enter key issue earlier). I'll try to record future vids with the actual mouse cursor, not just the highlight.

I figure the post-search sluggishness is a problem of shadergraph. I believe the search box sluggishness is a Searcher problem.

 

Bump.

 

Make sure to disable every single preview in the graph and subgraphs, it may help a lot in some cases