I can’t seem to get/grok how to create a custom TMP Shader and its associated Material/Inspector to work in the way that it’s rather simple to do with a ‘normal’ shader.
This is Builtin, 2019.LTS with the latest verified version of Text Mesh Pro that I’m talking about.
Here’s the fuller question, in the Text Mesh Pro forum space:
It seems there’s something uniquely odd/different about the integration of the UI and/or Shader aspects of a TMP Material and its shaders.
TMP shaders are quite complex due to the number of options they allow for, and TMP materials uses a custom material inspector (specified by the shader) to help group those together in a more manageable way. Unity’s Standard shader also uses a custom inspector to hide away much of that shader’s complexity.
To answer your question, technically no. There’s nothing “unique” about TMP in terms of it having a lot of settings or a custom inspector. But also yes, it is unique in that no two custom material inspectors need to be remotely similar as it can look however the author of the code wants it to. And being a custom material inspector it may be written with an explicit list of material properties or other shader features it assumes are always available. So if you take an existing shader and add or remove material properties the custom editor may not show new features or may cause the custom inspector to cease working entirely. The Standard shader’s custom material inspector certainly will break if you remove even a single property from the shader.
Personally, when I modify the TMP shaders, I always start with the “mobile” version of the shader, which has far fewer options to start with as I don’t have any interest or need to support the additional fancy ones like embossed normal mapping, etc. If you need to add or remove features, you will need to write a new custom inspector or modify the existing one to handle the added or removed properties more gracefully.
Cheers!
You da man!
Even doing nothing to a Shader, other than copying and renaming, and nothing to the TMP_SDFShaderGUI other than copying and renaming it, and then editing the new Shader’s final line to point to the new GUI file… the formatting of the Material Inspector is lost, and everything right justifies, all the groupings of features are lost, and some of them aren’t presented (the ones in the parent class TMP_BaseShaderGUI).
it’s as if the connection is lost, to the parent class, just by renaming. Is there any chance the TMP_BaseShaderGUI is somehow commandeered to filter what it permits to inherit from it?
I can’t really answer any of these questions apart from saying it’s possible. I’ve certainly written some custom editors that check the name of the shader to do custom stuff. Could be something like that in their editor.
I’ve found a sort of workaround, following advice of @Stephan_B to make a new folder for TMP, which isolates it from Package Manager’s handling of the whole plugin. It works, but is noticeably MUCH slower for each recompile when making changes.
So there is something odd going on with Packages, perhaps ensuring the ‘right’ files and relying on pre-compiled stuffs as a result.
THANK YOU for you help!