Search Unity

Feedback Usability

Discussion in 'Shader Graph' started by Soundwolf776, Aug 13, 2019.

  1. Soundwolf776

    Soundwolf776

    Joined:
    Mar 21, 2015
    Posts:
    17
    Here are some notes taken during an attempt to upgrading my project to HDRP, using ShaderGraph 6.9.1.

    General issues:
    • Extremely unstable. Can crash Unity at pretty much any operation with no rhyme or reason: adding/deleting nodes, connections, properties, changing code for a custom node, saving.
    • Slow-ish. Custom nodes seem to introduce quite a delay to all operations with graph and even material. Before, I could change material properties on the fly, immediately seeing the changes. Now, there is ~1-1.5 second delay before the material gets updated, which scales with the number of materials adjusted at once - making iterations uncomfortably long.
    Overall, that made me put the upgrade on hold. Hopefully, ShaderGraph will become more stable soon.
    Aside from these critical issues, there is a range of comfort of use issues.

    UX issues (in no particular order):
    • Add the Ctrl+A hotkey. Use cases are rare, but they do happen - merging subgraphs, copy-pasting subgraphs in entirety for testing purposes, etc. It feels kinda unnatural to have C/X/V hotkeys, and miss the A one.
    • Add the Ctrl+S hotkey for saving the graph. Currently, Ctrl+S pressed with a Shader Graph window in focus will actually trigger a scene save, which is misleading.
    • 'Recompile now' button/hotkey? Say, a shader graph has a custom node that uses A.cginc, and A.cginc references B.cginc. Say, you encounter an error. If you change A.cginc, all is fine - shader graph detects the change and tries to recompile the graph. If you change B.cginc, shader graph won't detect the change and still displays all the errors. It takes a change in A.cginc or adding/deleting something on the graph itself to force recompilation and to see if the error goes away. I assume it can be too costly to check all the nested cginc files. The button can be a reasonable compromise.
    • On a similar note, error messages in console persist after successfully fixing an error.
    • Each graph is opened in a separate detached window. Personally, it feels very inconvenient. Can ShaderGraph open a single separate window, and then simply add tabs to it? It's possible to do manually and IMHO makes working with multiple graphs at once much easier.
    • Similarly, “Show generated code” opens an IDE instance for each call (at least in MSVS case). Can it reuse an already opened one?
    • "Options" that appear on clicking the cog icon - shouldn't they auto-hide when the user clicks on empty space or other elements?
    • 'Create node' takes a pair of seconds to bring up the window. It's not too bad, but Unity is much more fluid in almost all other similar cases of 'windows with stuff from project folder'. If it can be made faster, it'll be much appreciated.
    • Naming inputs/outputs on a custom function node - can it automatically proceed to the next line after hitting Enter to confirm the renaming of the current one? Will make renaming ports much easier without having to resort to the mouse after each port.
    • On a similiar note, is there any possibility for custom nodes to automagically create I/Os for a specified function? Having to define them by hand seems boilerplate-ish, even if it needs to be done just once before making a subgraph wrapper.
    • That said, having an ability to automagically create a subgraph wrapper for a specified function can cut the routine even further.
    • Blackboard properties - can they be collapsed by default when opening the graph? Also, as already pointed out by someone, a 'collapse all' & 'expand all' buttons on blackboard can be handy.
    • Blackboard properties - any possibility of allowing us to change their type after creation?
    • Closing graph dialogue - Yes/No options work as expected, but the X (Close Window button) equals to ‘No’ instead of expected ‘Cancel’.
    • Reference names on blackboard properties - shouldn't they be set equal to properties names with "_" prefix by default? At least during the first naming after the creation of a property? It seems like a timesaver and a generally intuitive change, though maybe I’m missing some specific scenario where it’s can be a really bad idea.
    • ‘_float’/'_half' postfixes in function names feel extremely hacky. Shouldn't 'float' precision be assumed by default? Far as I understand, lower precisions are for very specific optimizations on mobile platforms only - so shouldn't they be sort-of-overrides on default behavior?
    Hope it helps to make a more user-friendly shader graph experience.
     
    Flazone likes this.