TextMesh Pro Texts are not sharp (ingame with screen space camera)

In order for Signed Distance Field to render correctly, scaling information needs to be passed to the shaders. This scaling information is passed via UV2 channel. When TMP text objects are used, the shader channels are set by TMP so ignore the warning on the Canvas as it is misleading.

Disable Pixel Perfect as it has no affect in SDF rendering. Using Pixel Perfect can actually affect performance when moving objects, etc.

When using a Canvas in Screen Space or World Space mode, make sure the appropriate camera is assign to the Canvas. This is very important in order for the correct SDF scale to be computed.

When using a Canvas Scaler, the scene view can become blurry but the GameView should be sharp (once we figure out why you are having an issue). The reason the scene view can be blurry is because when using a Canvas Scaler we end up with the Scene View and GameView using different scale so therefore priority is given to the Game View. Scale differences have to be pretty big for the difference to be visible between both.

In terms of troubleshooting, review the information above. Make sure the right camera is assign. Make sure the Additional Shader Channel is not modified by something else as TMP does need the following channels to be set.



To eliminate / reduce the # of things to check, you can disable the Canvas Scaler which should result in the text rendering correctly which should enable you to figure out if the camera assignment is the issue or channels, etc.

Also testing using a new simple scene to see if everything behaves correctly as it might help you rule out what is causing the issue in your case.

Lastly, the latest release of TMP includes a new set of Shaders that using Screen Space Derivative or (SSD). These are not as efficient as the normal Mobile Distance Field that require passing scale but for Desktop use or on new mobile devices the performance differences are not really measurable. So if all the above fails, switch to using the Mobile Distance Field - SSD shader. The latest releases are version 1.5.0-preview.8 for Unity 2018.4, version 2.1.0-preview.8 for Unity 2019.x and 3.0.0-preview.8 for Unity 2020.x.

 

I'll take a look tomorrow to figure out what the issue might be with Screen Space Camera.

Please try out the Mobile Distance Field SSD shader as it should render correctly.

 

(1) Create a new TMP UGUI text object. This new object should be using the default LiberationSans SDF font asset.

(2) Use the Context Menu by right clicking on the head of the Material Inspector to create a new Material Preset. We do that so we don't change your default material on the default LiberationSans SDF font asset.



(3) Change the shader assigned to this newly created material preset to use the TextMesh Pro - Mobile - Distance Field (SSD).



This shader is in the latest version of the TMP Essential Resources so make sure you imported / updated to the latest one by going to Window - TextMeshPro - Import TMP Essential Resources.

Once you are using this shader, the text should render correctly.

 

Sorry to hear that you are having those issues. The above is likely an import issue which should be resolved by re-importing the TMP Essential Resources. I have seen this before as well when the "TextMesh Pro" folder is moved inside the project.

In terms of the SSD shader, you should be using the mobile version instead of the full Distance Field SSD as per the image I had posted. Both shaders should work and you should not be getting this error but the mobile SSD is more efficient (if you don't need its features like Glow, etc.) otherwise the mobile one is fine.

In terms of TextMesh Pro, it is used by 100's of thousands / over a million Unity developers and by all major studios. That doesn't mean we don't run into issues from time to time but that is sort of why I am here to make sure we resolve all those issues so that you can get the results you seek and expect.

Again sorry about the above issue. Screen Space or WorldSpace canvas should work as is with the normal shaders but for some reason in your project they did not render correctly. If I had access to the project via a bug report, I could tell you exactly why / the source of that issue but without it, I can only guess. It could be some settings on the camera or something else. The SSD shaders should work so there perhaps we have an import issue. At any rate, should you decided to revisit this at some point, I will still be here to help.

 

The updated shaders should be working correctly in XR. This was tested by several users and the XR team at Unity.

It is possible that having the shaders outside of a Resources folder (which is where they were before) may have caused an issue when those shaders are not referenced in a scene or by some other asset included in the scene. This would result in those shaders not being included in the build. This behavior however would not be any different for any other type of asset.

The above is challenging in the sense that if all the shaders are included in a Resources folder, then all the shaders will always be included in a build regardless of whether they are used or not. To help improve efficiency, I moved these shaders outside the resources folder to make sure only those referenced are included. However, if these are indirectly referenced, it might cause an issue.

I need more information on the above as the shaders being outside should still be fine (provided they are referenced in the scene). Maybe there is something about the XR includes that is cause the issue where maybe some other parts are not being included when the shaders are outside the resources folder.

 

As a result of having the shaders included in a Resources folder for the longest time (to sort of avoid these issues in the past), it resulted in some users not being aware of these limitations / requirements related to resources needing to be references somewhere (in this case the shaders).

So for new users, having the shaders in a resources folder shields them from those issues but also deprives them from learning these things. On the other end, it results in all the shaders being included whether they are used or not which is inefficient.

Many experienced Unity users / TMP users manually move the shaders they know are not used in their project to reduce build size.

Thoughts?

 

Thank you for referencing the above. I guess this is something the SRP team needs to resolve.

 

Although there are threads / posts about this already but given this thread now specifically references shaders and SRP ...

I just wanted to re-iterate that I am working (among other things) on a set of HDRP Shader Graph compatible shaders for TMP.

Besides supporting HDRP, this will enable additional functionality such as the ability to support multiple outlines, shadow, etc. and allow users to more easily create custom graphs to add cool new functionality.