I have several geometry that requires shading in a particular order with TMP text attached on them. Since the objects have custom render queues assigned to them, I would like to do so for the text objects too. Changing the “Custom render queue” setting with the introspector in debug mode worked for my case but I can’t seem to access it through scripts.
Is it possible to override the Custom render queue in the material through scripts?
Turns out I just had to use the .fontMaterial in the TMP_Text rather than the material in the mesh renderer.
The Sorting Order and Layout on the material used by the text object can be set in the Extra Settings panel of the component.
The material can be access via .fontMaterial as you have discovered. Keep in mind that accessing .fontMaterial will result in an instance of the material being created. So if you have multiple text objects that share this material, you might want to pool them.
By contrast, the .fontSharedMaterial is the persistent material used by the object and changing its render queue will affect all other objects and the persistent asset.
Sorry about the delay in reply… didn’t notice until you added the TextMesh Pro prefix on it.
No problem at all, I am kinda new to the forums and was struggling to change the title (Categorized under thread tools for some reason 
) when I realized it was pretty badly worded. Thank you very much!
@Stephan_B I just stumbled upon this. Is there a (valid) reason why TextMeshProUGUI.material doesn’t work for this? Why does this UI component use a separate font-material while every other that is a subclass of UnityEngine.UI.Graphic uses the Graphic.material property?
In Unity, accessing the material property of renderers like the MeshRenderer returns an instance of that material whereas accessing the sharedMaterial property returns the material itself. This behavior is mirrored by TMP.
TMP_Text.fontMaterial returns an instance of the material whereas TMP_Text.fontSharedMaterial returns the shared material.
I am not talking about .material and .sharedMaterial. I do know what the difference between those two are. I am talking about .fontMaterial vs .material.
The TextMeshProUGUI object has a .material property, which does nothing, a .sharedMaterial, which does nothing, (both inherited from UnityEngine.UI.Graphic) a .fontMaterial, which does what .material should do, and a .sharedFontMaterial, which does what .sharedMaterial should do. In the very least, .material and .sharedMaterial should be an alias for .fontMaterial and .sharedFontMaterial, respectively.
TMP_Text objects do not use the .material property instead it uses .fontMaterial and .fontSharedMaterial.
This dates back to the initial introduction of TMP back in 2014 before the Canvas system was introduced. This is consistent between the component which works with the MeshRenderer and component which works with the CanvasRenderer.
TMP_Text objects did not initially expose a material property. However, when the base class TMP_Text was introduced to combine common functionality, this class had to inherit from MaskableGraphics and as such ended up with this .material property.
Besides the TMP text objects having their own properties to access their material which are .fontMaterial and .fontSharedMaterial is there a specific issue you are trying to resolve?
We use an extensive Library of wrapper classes for the Unity UI in order to create and manipulate UI objects via code (we don’t create any UI using the Editor, it is all defined in code). In an effort to streamline our library, I created a generic wrapper class (constrained to UnityEngine.UI.Graphic) that controls some of the functionality, i.e. the properties implemented by the UnityEngine.UI.Graphic class. One of those is the .material property.
I then have specific subclasses of that generic type for each UI component (Text, Image, RawImage, etc). This works with every UI object except TextMeshPro. I currently have a workaround in place to use fontMaterial instead of material, but I’d prefer if that exposed .material property did something useful.
I am currently working on a new Parser & Layout Engine for TMP called TextCore. In this process, I can revisit these properties.