Lot’s of little caveats worked out with mesh triangulation, now works on all the fonts/characters that the previous implementation failed on. A good point to note the shader based anti-aliasing works great on rather large text or text with thick contours, but still looks pretty aliased on small text, however traditional FXAA seems to take care of it just fine:
P.S. Since each character has more geometry than a bitmap text character, which is just a quad, when you use a getText method it returns a TrueTypeNodeMesh object which extends Node. This may have one or more geometries attached to it, each geometry containing a mesh that represents one or more glyphs. The glyphs are divided up between the geometries so as to maintain the least amount of geometries possible. Glyphs are added to each mesh until the vertex count reaches Short.MAX_VALUE at which point another geometry is added and so on…
I m just wondering, why getText return a node, This should be the actual text use to draw the geometry and not the geometry it self. Wouldn’t it be better to keep the name for easier swap from bitmaptext witch getText return the String used?
The method I’m referring to is used to deliver the text node that will be used for rendering, it is a method in the class that is returned from asset manager.load… There is a getText method on StringContainer they is used to get the string that the geometry represents.
I’ll have to give that a try. I thought I tried it once before and had trouble getting it to work with jME, but I might be remembering some other platform.
Actually, @pspeed I have an opinion question for ya and since you’ve designed a few UIs you’re probably a good guy to ask.
Right now when you do basic alignments, not using StringContainer to format the text, the origin is placed on the top with text extending down for top aligned text, for bottom alignment the origin is on the bottom with text extending up. For left aligned text the origin is on the left.
For right aligned text, currently, I have the text aligned on the right, but leave the origin on the left. Would it be better to extend the text to the left so that the origin is on the right for right aligned text? Not sure if the way I have it would be confusing or not.
If I understand the question right… the origin should be relative to the left side of the ‘text box’ with the text either left or right inside that text box.
The new UV layers now work on both true type mesh texts and true type bitmap texts, formatted with StringContainer and non-formatted.
For mesh texts texCoord3 is per character, texCoord 4 is per line and texCoord5 is per block. For bitmap texts, pictured above, that is texCoord2, texCoord3 and texCoord4.
Thanks. I figure it could be useful, obviously, if you want to do gradients, animated swipe fades, etcetera… To be clear I’m not, as of this moment, planning to provide any shaders in the library that take advantage of these UV layers, they are there for anyone that wants to write their own shaders to spice up the text. I have methods that take in a color and return text of that color, but also methods that allow you to supply a Material.
If you write your own shader I would suggest copying the supplied vertex and fragment shaders and then modifying them to suit your needs.
Lots of little improvements and such, but by and large the code has been re-organized to be more manageable. TrueTypeMesh and TrueTypeBMP both extend TrueTypeFont and generally support all the same methods, with the exception of some methods in TrueTypeBMP supporting a second color for outlined text.
The Sfntly dependency is now required if you plan on running on Android or using TrueTypeMesh. As such TrueTypeMesh and TrueTypeBMP both work on Android.
Blurring text is also supported for both mesh and bmp texts. However, currently, mesh texts do not support Style.Bold. If you want to use bold with triangulated mesh text I suggest you use the black or bold variant of the font you wish to use as many fonts now have different styles separated into different files.
The new unified library is now called jME-TTF rather than jME-TrueTypeFont. If you’re already using jME-TrueTypeFont jME-TTF will not just drop into your project, though it shouldn’t be too hard. Packages have been renamed, classes have been moved around. For instance the getBitmapText method is now just getText and TTF_AtlasListener is now just AtlasListener.
I recommend you check out the documentation included with the download and the information available at the above link, the jME-TTF pages cover all of the necessities.
P.S. TrueTypeMesh worked on all of my test fonts, however, it should be noted that true type fonts were not created with meshes in mind so I wouldn’t be surprised if there are a few scenarios out there that would cause triangulation to fail. I recommend you test out your fonts thoroughly. You’ll probably be fine with professional fonts like Cantarell, Serif, Times New Roman, etcetera, but fonts on those 1001 free font sites can be a bit of a crap shoot I’m sure.
And it’s easier to use a gradle build to generate and upload one than it is to keep a pom.xml up to date manually. At least I think so having done lots with both.
I use some plugins to get mine setup for Lemur, Zay-ES, etc… if you want, you can look at one of those projects for how to setup a gradle build to upload to bintray+jcenter.
For example:
…note: that I’ve encapsulated a lot of my common settings into a local gradle file gradle-plugins/master/simtools-release.gradle
…you will certainly want to use your own settings for those. I did that to avoid having to include those bits in every build.gradle file I have.
