TextMesh Pro - Advanced Text Rendering for Unity - Beta now available in Asset Store

** Please post TextMesh Pro related questions in the Unity UI & TextMesh Pro section of the user forum. Be sure to add the TextMeshPro prefix to these posts.

UPDATE The first public beta of TextMesh Pro is now available on the Asset Store

Here is a link to the new Asset Store Forum Thread.

Should you have any questions about the functionality / features of TMPro, please feel free to ask in this thread. For assistance, please visit the TMPro User Forum where you can request help as well as find instructional videos which should help you get started familiarized with TextMesh Pro.


IMPORTANT NOTE: The latest beta releases of TextMesh Pro with support for Unity 4.6 and the new UI as well as beta releases for Unity 5.0 are available to all registered users of the product on the TextMesh Pro User Forum. Once your registration to the forum has been approved, you will find the latest beta releases in the "TMPro - Alpha & Beta Releases" section of the forum.


Hello Everyone!


Today I am pleased to make my first WIP post and to finally get to show fellow Unity users what I have been working on over the past few months. So without further ado, I now introduce you to:


Image from actual text as seen in the Unity Editor.[SUP]1[/SUP]


Introduction
TextMesh Pro! is essentially an advanced version of Unity's built-in TextMesh Component. It was designed to provide users with a more powerful and flexible solution while remaining easy to use and with improved performance.


Improved Text Formatting
Starting with a larger text input box to a more comprehensive list of Rich Text <tags> which include underline, superscript, subscript or size to dynamic character spacing or word wrapping as well as support for kerning, TextMesh Pro! has you covered.


Example showing superscript, subscript and center justification.[SUP]1[/SUP]


Advanced Real-Time Font Rendering
Just like all other text rendering tools, TextMesh Pro works with standard bitmap font atlases. However, a lot of the power and flexibility of TextMesh Pro comes from the use of Signed Distance Field "SDF" font atlases. The combination of SDF based font rendering and a set of advanced custom shaders delivers substantial visual quality improvements over normal bitmap fonts while giving users amazing flexibility when it comes to font styling texturing.


"S" Letters shows some of the dynamic changes that can be applied to a single SDF font asset. With the exception of the first bitmap "S", all visible text including the captions is an example of SDF based font rendering.[SUP]1[/SUP]


An unlimited number of visual styles treatments are virtually possible from a single SDF Font Atlas and they look great at any size.



Close up - These two letters are using the same SDF Font Atlas. They are simply using two different materials.[SUP]1[/SUP]


Font Asset Creator
Want to use some new TrueType or OpenType font but need to create a font atlas for it? Not a problem with TextMesh Pro!. Just import your font in Unity. Open the built-in Font Asset Creator and within 30 seconds your new font asset is ready.


Built-in Font Asset Creator. No need for any external tools. Can create normal bitmap font assets or SDF font assets.[SUP]1[/SUP]


Intuitive User Interface
TextMesh Pro! features several custom inspectors editor panels. They were created to give users access to what they need while keeping things simple.


Shown TextMesh Pro!'s custom editor material inspector.[SUP]1[/SUP]


Scripting Interface
Need to create or modify text objects via scripts? All of Unity's components offer a scripting interface and so does TextMesh Pro! All of the relevant properties of TextMesh Pro! can be accessed via script.


Example of TextMesh Pro! object creation via script.

[HR][/HR]

Here is a list of some of TextMesh Pro's features.

TextMesh Pro! Main Features

• Easy to use with simple UI featuring custom inspectors and editor panels.
• Supports both Bitmap Signed Distance Field font atlases.
• Built-in Bitmap SDF font atlas creation tool.
• TrueType OpenType font support.
• 2D Text objects can be created in the Editor or dynamically via scripts.
• Better performance than Unity's built-in TextMesh and No Alloc.

Formatting Styling Options

• Dynamic font sizing. SDF font atlas renders sharp and great looking text at any sizes.
• Rich Text support. Per character tags include color, bold, italic, underline, superscript, subscript, size, tab and position.
• Text Anchoring - The usual 9 positions.
• Text Alignment - Left, Center, Right and Justified.
• Line character spacing.
• Automatic word-wrapping.
• Kerning.
• Multiple Texturing Mapping options.

Built-in Custom Shaders

• Basic Bitmap text shader
  - Face vertex color
  - Face Texturing with multiple mapping options
• Basic SDF text shader
  - Face vertex color
• Advanced SDF text shader
  - Face vertex color
  - Face texturing with multiple mapping options
  - Border texturing
  - Border thickness softness control
  - Beveling + Glow control
• Advanced Surface SDF text shader
  - Real-time lighting shadow casting
  - Plus same features as Advanced SDF text shader

[HR][/HR]

Final Note
Well! That is it for my first post. Obviously, I would love to get your feedback impressions of TextMesh Pro! thus far as well as answering any questions you may have.

I do plan on following up with additional example images videos to provide better insight on some of the features and operation of TextMesh Pro!


Thanks everyone



[HR][/HR]
*1 Images are of actual unedited screenshots taken from within Unity's Editor.

 

Wow, this is awesome! Can't wait to get my hands on this ... and I'll be sure to support it in ScoreFlash as renderer

 

Thank you! I look forward to seeing TextMesh Pro! working with ScoreFlash.

 

Looks really cool, definitely something Unity could use! How much do you expect to charge for it? Also, how efficient is this and have you tested if this will run well on mobile?

 

Thanks

I have not yet decided on a price.

TextMesh Pro! currently outperforms Unity's TextMesh in the performance tests done thus far on desktop(s) and android devices. I am looking forward to testing it on iOS devices and am hopeful that we will perform nicely there as well.

Here is a video of a performance test I did a few months ago. This is using the Advanced SDF shader which is more complex than our Basic SDF shader. Be sure to watch in HD.

Unity's TextMesh vs. TextMesh Pro. This is a crazy amount of objects.

On the memory side, there is no allocation made per frame but I'll give you a more detailed answer later today.

 

Here is a video I made last night going over the basics of the tool in the Unity Editor.

 

wow very good

 

Here are a few examples of the results I got from playing around with this font I downloaded.


After creating the SDF font asset for this font, I created a new game object to which I added a TextMesh Pro component. This image shows how this font looks without any treatments applied to it.




After making a few tweaks (adding a border + texture + bevel + glow) ... this same plain font was transforms into this.




In order to get this new look, 3 new material we created from this original plain one. This final image is comprised of 3 TextMesh Pro objects, the Bevel + Red Glow, the Shadow and lastly the Blue Glow.

Here is an image of the Blue Glow material applied to this font.




Edited the text and made some tweaks to the bevel and glow.




If anyone is interested, here is a video showing the some of this process.

Lastly, here are a few more variations. Again keep in mind that all these different text objects / images are using a single 512 X 512 SDF font atlas that is only 256K in size and contains the full ASCII character set. The only difference between these objects are the dynamic material shader properties being different.

 

Nice!
Could you say anything about the time frame?
Days, weeks, months?

 

I would love to release TextMesh Pro! within the next 30 days but it all depends on getting enough feedback. I really want to make sure it includes the majority of the features that potential users would want.

So far, the feedback is slow to come. I really don't know if that is typical or if the title of the post needs to be changed or maybe few care about a more powerful alternative to Unity's built-in TextMesh component.

 

Some things I'd be interested in seeing (forgive me if you already have these solved):

1. an interface for numbers and text without allocations:

Funcname("Some text ", anInt, " some more text."); << a common thing in games is to mix text with numbers. Now as the data is supplied separately, your function is able to generate the required text without any string manipulation, that is you should only have to read the string. Currently, this is still left to the programmer to take care of, and it would be nice if middleware took care of it.

People typically go: Funcname("sometext "+someInt.ToString()); or such - which obviously means a new string is built and garbage is allocated. By having a method which accepts numbers as something you can parse, we can probably avoid the allocations.

2. Distance field font rendering support in your atlas code plus perhaps a shader for it - this means the font does not require huge amounts of ram to look good, and generally looks good at any size. (example: http://forum.unity3d.com/threads/61243-Unity-Signed-DIstance-Field-Textures)

3. Various functions for getting the sizes of things in world and pixel space. I think these would be useful to people for game related purposes.

4. For very large font atlases (asian for example) you might consider packing the font into R, G, B, A separately and using a shader to split them to save atlas space - a useful thing not only for large char sets, but for mobiles seeking to save ram with larger font sizes.


Bear in mind I might not necessarily be a prospective customer, I'm just pointing out what I'd expect from a standalone middleware solution.

 

I wouldn't worry too much about that ... personally, all I need is that the text looks awesome and that I can easily check width / height and control width / height if I need to (that's stuff I need for the ScoreFlash integration). Personally, I like it when things are simply. Too many features often just make things feel bloated ;-)

 

There's a solution built-in to the .NET framework which Unity uses (well, technically it uses Mono - but that really is .NET):

string.Format("Some text {0} and some more {1}", someIntIfYouWish, anyOtherObjectYouLike);

 

Doesn't that allocate a new string though? ...googling now...

edit: yeah it generates garbage. My most was about manually parsing the strings and ints in code to output uv coordinates for the quads. By only growing as needed and not shrinking, the garbage should drop to zero. I do this myself for scores that change often but was thinking middleware could too. Scores are ints so it's easy to knock off bits then compare.

 

Text can be provided as either a string or char[]. The string is parsed and converted into a char[] since internally the process works on char[]. Currently when updating a text object each frame, GC Alloc is zero. However, whatever small script is feeding that .text (string) is inviting that GC monster. So in terms of providing a function to enable users to easily take their data to turn it into a char[] and avoid string manipulation, I'll give it some thought.

I certainly agree that Signed Distance Field font rendering is awesome. On the other hand, I am not sure I understand your point given that every single example in my previous posts are using SDF font atlases created with the TextMesh Pro's built-in Font Atlas Creator and using one of the included custom SDF shaders.

Signed Distance Field font rendering is pretty amazing which is why TextMesh Pro! was designed to fully leverage that power and flexibility.


Example of changing some of the SDF Shader properties via script. Text shown is using the same SDF font atlas as the RED Zone examples in previous posts. This is just a different material with different shader properties.

The mesh / text object creation process currently results in a struct that contains key information about each characters part of the mesh. Such information could be used to further manipulate the mesh / layout or enable editing of the text in the camera view, etc...

Do you have anything specific in mind?


In terms of your last point, let me get back to you on that one if I may.

 

Here is a screenshot of the Unity Editor showing the properties of TextMesh Pro's Advanced Text shader that can be changed either in the editor or via script.

In the case of this glow effect, this little script is simply changing the value of the Glow Power in a Coroutine. The script can be seen in this image as well. Note that animating most of these properties does not cause the text object / mesh to be redrawn and is therefore very efficient.

All of the techniqu named materials use / reference the same techniqu SDF font asset which contains the atlas and font data. By applying the Metal Red + Glow material to this text object, it would instantly make it look like one of the RED ZONE examples.

 

I can only speak for my self but as someone coming from a Flash background I have missed these features so much in Unity.
I remember wondering how Unity could have such unintuitive and sub par font/text features when I made the jump.

In my latest game I have already had to redo the bitmap fonts like five times since I wanted to tweak the look, change font size, missed a glyph/character...

From what you have shown I could have saved hours if not days of work.

And if your solution looks better and Performs better it's a no brainer.

 

Sorry about the SDF suggestion that you already supported - flew over my head late at night! It gave you more room to demonstrate to customers though

Onto SDF's shader - on PowerVR chipsets, alphaTest is the devil and will slow it down quite a bit. An alternative mobile shader might be developed that uses step instead - which is (for reasons I don't know) faster than clip and alpha test - just a thought if you wanted to see if was possible to avoid using alpha test for iOS / other PVR chipsets.

 

If this was released, I would pick it up in a heart beat. Would literally be what I am looking for.

To pragmatically set 3d text, especially on a gameobject. Would make things super nice.

 

I'm not sure what you mean by using 'step' instead of 'clip'. (I'm very curious actually
but let me write a little on this subject, even so I haven't done extensive testing on all architectures.

First, alpha testing is not used. So we can focus on the potential use of discard() (a.k.a texkill(), clip(), ...)

TextMesh Pro current set of surface/fragment shaders uses alpha blending with ZWrite off (executed in unity transparent pass), so the underlying HW doesn't take into account this geometry in any Z buffer based visibility operation.
This is normally the core of the problems (doing per pixel conditional depth writes), especially on PVR architectures. (as you hinted)

Now on using discard() to early out when you know your shader will produce nothing ( potentially saving computation bandwidth.)
I found that on the desktop its always a win on nvidia HW, but does come with overhead even on modern AMD GPU.
Because of this, its preferable not to use discard() when the majority of the pixel will be written. And this is the case when rendering small fonts.

With alpha blending there is another hint that the HW receives to optimize the operation since a shaders will return 0 for fully transparent pixel,
causing the raster blend operation to essentially be a NOP.
From this, the HW has the opportunity to skip the ROP altogether, potentially saving on bandwidth.

All in all, early out alpha blending is an area worth investigating further to gather definitive data.

 

Discard and Clip are a branch on PVR gpus, which pretty much do the same as Alpha Test under the hood on these devices - sorry for not being clear - in short they resolve to a branch. Step doesn't appear to, or if it does - it does so at a much reduced performance impact: http://http.developer.nvidia.com/Cg/step.html

Although I'm not sure how this could be used either but the potential is there... you can use it to test if a pixel>whatever and return 0 or 1 as a result (which is easily multiplied - emulating a discard). It's still going to be slower than Discard for desktop I suspect.

 

Most of the recommendation related to discard()/ alpha test is in relation to geometry that write to the Zbuffer and affect visibility.
Because all visibility test must be evaluated in the pixel shader, it break most architectures.

But in this case, the geometry is rendered after all opaque objects, using alpha blending , no depth buffer writes, so visibility is not a concern anymore.
This is not to say that discard() is a silver bullet and guaranty faster alpha blending operations on all HW. It does not.

With alpha blending the HW, must assume that all pixels are visible and will be written.
So what we are doing by using discard() is hinting the HW, "The destination color will be unmodified, do what is best on your architecture".
And yes, the other way to do early out making it to make the blending operation become Destination = Destination.
It give the same hint to the HW, and in the end the exact same result will be performed to the destination buffer.
But the HW can choose to perform this in different ways.
And like I mentioned in my original post, for sure AMD and nvidia have optimized their GPU differently.

For step() and if(), I have yet to see it generate different code.
You will see no benefit from those two variation:
if(step(alpha, 0)) return 0;
or
if(alpha <= 0) return 0;

But you will see difference in performance from those 3 methods:

a) no early out
b) early out using discard (implicitly instruct the HW that Destination = Destination)
c) early out returning 0 (blend operation make it so Destination = Destination)

What I cant give is actual numbers at this time... a benchmark could bring more light on this.

 

Discard *doesn't exist* on Power VR hardware. It translates this to a branch, so it's a lot slower on iOS due to the fact it cannot resolve Z until the end of the frame unlike desktop gpus. It doesn't care if you're rendering it without Z or not, it will still have the same performance impact because regardless, it turns it into a branch. And branches are horrific on iOS.

This isn't about AMD or Nvidia, but a problem with Imagination Technologies GPUs.

 

When alpha blending, all pixels must be executed in the fragment shader. The HW cant work around that.
Their is just no way for any architectures to know what will the shader compute and write in the output color on completion.

So when executing the alpha blended shader, you have a choice. Do nothing and execute the shader no matter what
Or 'early out', giving the HW a hint that the computation will result in Destination = Destination.

Each vendor will choose to optimize this or not, but ALL must follow the OpenGL spec.

So its fine for a HW vendor to completely ignore the hint and just mark this pixel as discarded, and still execute the entire shader,
and just do a NOP blend operation resulting in no gain.
Other might take the hint and if all pixel in a group got the discard flag, just early terminate.

Worse possible case by design is where the HW does no optimization whatsoever,
and execute the entire fragment and only at the end check if it was marked as discarded.
In this worse case you gain nothing, and discard() might actually add a small overhead.

But, I never heard that powervr architecture is horrific on branching, do you have details on that?

 

absolutely brilliant !! Great work, man !

 

Thank you!

 

Here is a follow up on your suggestion Hippocoder


New function TextMeshPro.SetText(string, arg0 ... arg2); arguments can be a mix of ints / floats.

Here is an example of usage.

Code (csharp):

1. m_textMeshPro.SetText("The first number is {0}, the 2nd is {1:3} and the 3rd is {2:4}.", 1479.356f, -137.5698f, 4.25f);

{0:2} means first argument and rounding to 2 decimal places. I figure 3 arguments should be good enough,


Performance Benchmark
I tested the following forms of string formatting and iterated over each of them 1 million times and timed it with system diagnostics stopwatch. I then separately tested each of them in an Update() loop to check GC Alloc.

Code (csharp):

1.  
2. // ~ 4461ms Mem Alloc 0.8KB
3. string.Format("The first number is {0}, the 2nd is {1:f3} and the 3rd is {2:f4}.", 1479.356f, -137.5698f, 4.25f); // 4461ms mem alloc 0.8 KB.
4.  
5. // ~ 3670ms Mem Alloc 310 bytes
6. _stringBuilder.AppendFormat("The first number is {0}, the 2nd is {1:f3} and the 3rd is {2:f4}.", 1479.356f, -137.5698f, 4.25f); // 3670ms mem alloc 310 bytes.
7.  
8. text = "The first number is " + 1479.356f + ", the 2nd is " + (-137.5698f).ToString("f3") + " and the 3rd is " + (4.25f).ToString("f4") + "."; // 3275ms mem alloc 472 bytes
9.  
10. // ~ 2594ms Mem Alloc 194 bytes
11. _stringBuilder.Append("The first number is ").Append(1479.356f).Append(", the 2nd is ").Append((-137.5698f).ToString("f3")).Append(" and the 3rd is ").Append((4.25f).ToString("f4")).Append("."); // 2594ms mem alloc 194 bytes
12.  
13. // ~ 620ms Mem Alloc 0
14. m_TextMeshPro.SetText("The first number is {0}, the 2nd is {1:3} and the 3rd is {2:4}.", 1479.356f, -137.5698f, 4.25f); // 620ms mem alloc 0  
15.  

Conclusion
TextMeshPro.SetText() achieved the best performance with ZERO alloc.

I was aiming for no allocations but did not expect to crush the other function by that much on performance. Obviously, I don't support the multitude of formatting options they offer but for the typical usage, TextMeshPro.SetText() should do the trick.


Thanks for the suggestion.

 

Text Rendering Comparison
Here is a comparison of text rendered at different sizes using TextMesh Pro! vs. Unity's built-in TextMesh.



Great looking text at any size
One of the many advantages of using Signed Distance Field (SDF) text rendering is that it looks great at any size. Whether your text is 16 pts, 256 pts or even something crazy like 3797 pts, it scales linearly and maintains its visual quality which is not the case for bitmap fonts.

Another huge advantage of SDF text rendering is that only (1) relatively small SDF font atlas is needed to render text at any size to which dynamic changes can be made to virtually achieve an unlimited number of visual looks. As you can see the SDF font atlas is a small 512 X 512 texture only 256 KB in size for the full ASCII set vs. a huge 4096 X 4096 texture that is 16 MB containing only the visible characters.

A big misconception about SDF Text Rendering is that large text looks great but small text looks bad. Well, that is not the case with TextMesh Pro's Advanced Signed Distance Field shaders. TextMesh Pro's SDF text looks awesome at large sizes and looks as good or better than bitmap text at small sizes.

The image above is a composition of a few screenshots. First, the text of size 32 to 256 is TextMesh Pro vs. TextMesh side by side in Game view with camera in Perspective mode. The smaller 8 to 20 pts text is from Game view with camera in Orthographic mode.

As you can observe the SDF based text on the left looks great at medium to large sizes. It still looks decent at the smallest possible sizes. By comparison, the bitmap base text on the right breaks up at the smaller sizes, looks too soft in some areas, shows clipping and artifacts in other spots and shows aliasing at larger sizes.


Conclusion
In all aspects from the size of the assets to versatility in terms of visual looks and treatments to how the text looks on screen, Signed Distance Field text rendering outperforms its bitmap counterpart.

 

In my previous post, the size of that Signed Distance Field font atlas which contained the full ASCII set for that particular font "Arial" was 512 X 512 and 256 KB which was pretty impressive given the visual quality of that text.

Just for fun, I created a new SDF font atlas for this Arial font but decided to pack it into a smaller 256 X 256 texture whose size is a tinny 64 KB. In the image below, you can see how the text turned out as well as the signed distance field font atlas.

 

Excellent. It will be because of this feature that everyone will have no choice but to use Text Mesh Pro. No choice at all.

Really impressive SDF rendering there. I like it so much I'd like to try it out in my game.

 

Another aspect of correctly rendering a distance field with 3D perspective is anisotropic correction.
This is not achieved by sampling the texture using an anisotropic filter, but actually doing distance correction.

Two versions are implemented in TMPro, one for GLSL 3.0 HW and an approximation for GLSL 2.0 (done in the vertex shader).

Something we also experimented with is bi-cubic reconstruction, but the benefits where marginal and mainly benefited super small SDF rendered at extreme upscale. So this most likely wont make it in the 1.0 release.

 

TextMesh Pro! vs TextMesh

Here is another example where TMPro provides improved rendering: sub pixel positioning.
The improvement is subtle, but you do get improved clarity without forcing pixel rounded alignment.
This also make it viable to use floating point accurate kerning with any font size.

One thing that we also experimented with is sub pixel rendering (a la ClearType), but with the vast array of display devices and no OS/API to define the target pixel structure the benefit was too limited.

 

If that new feature alone is reason enough for users to invest in TextMesh Pro then that will add a lot of weight to the case for "GC" being the greatest of evil.

For my part, I am just hoping that TextMesh Pro with the sum of all of its features lives up to users' expectations and proves to be a great asset and investment for them.

Thanks

I'll be sure to contact you when we are ready for beta testers



P.S. A quick note about this new function. TextMeshPro.SetText does result in some Alloc in Editor Mode Only simply because I am converting the Char[] into a String to populate the Text Input Box in the Editor Panel to give users feedback. This conversion is wrapped into #if UNITY_EDITOR so SetText() results in Zero allocation in a build. Let me know if that's fine?

 

Perfectly fine to pee everywhere offline (ie editor) - lots of things do it there, but watch out for customers who may complain about GC in the editor during Application.isPlaying - might want to prevent it doing it then or just alert the user, not sure.

GC with strings is one of the biggest banes in game development in general for all platforms. Strings are usually the worst offenders, and every game needs them. Even Flappy Bird.

I love what you're doing with SDF but if you can be sure to test on mobile and optimise as PVR and non PVR have different horses for courses.

 

I so wish we could have better control of the GC process. It would be so great to be able to budget / limit GC per frame.

You can rest assured that it will be tested in order to ensure it performs as expected.

One of my main concerns remains getting enough feedback and right now it is pretty slow / slim. I am not sure if this is typical or if the title of the post is bad or what to think.

 

For those who may wish to implement their own text formatting, I added a new function which allows using a char[] to set the text that will be displayed by TextMesh Pro.

There are now three convenient ways to provide the text to be displayed to TextMesh Pro.

TextMeshPro.text
string text;

Code (csharp):

1. textMeshPro.text = "The count is:" + count;

TextMeshPro.SetCharArray
void SetCharArray(char[] characters);

Code (csharp):

1. char[] chars = { 'T' }; // use whatever implementation you wish to create this char[]. Hopefully one that does not generate GC.
2. textMeshPro.SetCharArray(chars);

TextMeshPro.SetText
void SetText(string text, <T> arg1, <T> arg2, <T> arg3);

- Arguments can be integers or floats. The 2nd and 3rd arguments are optional.

Code (csharp):

1.  
2. textMeshPro.SetText("The first number is:{0}, the 2nd {1:2} and the third {2:3}.", 14, 13.446f, 3.1415f);
3. // Output:
4. // The first number is:14, the 2nd 13.45 and the third 3.142.
5.  
6. textMeshPro.SetText("The count is:{0}.", count);
7. // Output:
8. // The count is:42.
9.  
10. // Using SetText helps keep the GC monster away. Zero allocations.
11.  

 

Seems awesome!

The problem here is not enough traffic - people think they don't need really awesome text - but in fact it's one of the most crucial parts of making a game. It should be attractive, fast, effective and very configurable.

I don't think many people understand that SDF is how they get that vector quality valve like text rendering as seen in Team Fortress 2. I don't think people understand how much better their games will run with a powerful low footprint text middleware.

Those that do should spread the word, so that this asset serves as an example for anyone wanting to make a professional impression, after all, text is usually the primary way a game will communicate to the player, so it needs that level of importance placed on it.

Some other uses:

Signposts. World based text is great for a game like GTA, or an rpg, or whatever - SDF ensures that text is clear and visible regardless of how it is viewed in the game world. It's not just menus or HUD displays.

 

I'd say it's typical. If you follow the Asset Store forum - there's just a *lot* going on.

Oh wait ... this is in Works in Progress ... hm ... probably really the most appropriate forum - maybe that's why you're getting comparatively much feedback (most announcements really just disappear without any feedback at all).

But to be honest, when I personally look for Asset Store packages, I never look here ... so I'd post a message like this directly in the Asset Store forum.

 

I presume once it is ready

 

Hi.

One thing I'm kind of picky about is the editor/inspector layout. Your product seems to use some unconventional GUI elements (e.g. thick black boxes), that the built-in components don't use. Are you planning on making it feel more "Unity-like"?

But other than that it looks great!

 

Are you referring to the Text Input Box for instance or the labels on those?

 

Yep, your Text Input Box is black (should be grey). Also the box that says "Font Settings" doesn't match convention either.

 

I do plan on making sure the UI matches the selected Unity Skin (ie. the light or dark one). This dark background does look bad on top of the light skin

How about this?



In terms of the larger labels, it is just to help separate options in the UI.

 

I am very interested in this component, because basic text mesh is limited and there is no anything decent at store. Waiting for the release, hope it will be soon.

 

I can also see people using it for titles, levels intro page, or any area that would normally need an offline graphic tools like photoshop.
One benefit is that you end-up with resolution independent rendering and the text can interact/be animated in a game script.
So you dont need to go offline, render "Level", "0", "1", "2", etc.. with a fancy font treatment, at a given resolution and manage that.
Pick the TTF in Unity, setup your treatment in Unity, and you have dynamic stylized text with all aspect under script control.

Here is an example of two SDF characters from a dingbat font.


By using the TMPro beveling options and unity lighting, you can create this (and render it at any size and have it look good).


Then, here is how this visual style look when applied to Arial.


The stuff that I personally find cool is that the Glow is emissive, so when you place glowing text in a dark scene its pretty dramatic.
And if this thing is actually used by people, beside you Hippo, there is a few experiments from the research lab that could come alive.
(Hint: I haven't seen any other asset render text with real-time ambient occlusion...)

note: For the curious, I posted some other examples in this thread.
(a couple show text in a scene with point and spot light + directional light and shadow)
http://forum.unity3d.com/threads/226903-Non-Dull-Text

 

We're ready to integrate it and use it now - would probably find bugs fast

 

That's an improvement. It's just when I make editor extensions I try to make it look as native to the editor as I can. Those boxes/seperators (around Font Settings and Text Input) don't match convention; I don't see that kind of box anywhere else in the whole unity editor. Again it's just an artistic preference that I have; if the component is functional then that's what matters

 

Does it support unicode fully ie asian char sets are a must for us. Sony wants us to add support for these, so please make sure it is able to support ridiculous texture sizes with small chars with large number char ids.

 

This is an area that needs to get flushed out. Currently, you can create an SDF Atlas for any given range(s) of characters but there is only so much you can pack in a texture. Right now, dynamic atlas creation isn't supported but something considered for subsequent versions depending on how the tool does on the asset store.

Here is an example of characters from Meiryo.ttc (already had to change the code to support .ttc which I guess Unity doesn't). Here you can see an SDF of 205 Japanese characters (a subset of their character set I presume) packed in a 512 X 512 texture. So we could pack over 13,000 in a 4K atlas.



Typically, when using non dynamic atlas creation, how many characters do you end up using for an average game?

How large are those textures typically?

 

I would LOVE, LOVE, LOVE to see text on a spline.

BTW, - do you need beta testers?

Certified Unity Alpha and Beta tester right here.

Even willing to pay up front to begin playing with this!!

It is usually easier (for me anyway) to provide feedback while using a plugin in a real project environment.

Let Me Know
zipper