Improved font rendering system.

[Nadro]

Hi,

As you know current Irrlicht font rendering system need improvements. I have plans to implement those improvements, but at first I would get some info from users which features should be available (I don't have in plans to implement TT fonts). I thought about:
- Combine font rendering to one draw call per word (current system offer one draw call per sign).
- Matrix for manipulate font rendering position, orientation (really usefull in mobile world when orientation in landscape is our target) and scale (sometimes downscale/upscale is require - scale, because in many cases dedicated bitmap file isn't require for achieve good quality).

Those improvements (+optionally improvements suggested/added by community) will be available in v1.9.

Cheers,

[Andreas]

Hi Nadro,

I have plans to implement those improvements
Those improvements (+optionally improvements suggested/added by community) will be available in v1.9.

That sounds great!

I don't know if this is technically possible, or even in the engine already, but i would like to see an API to change the font's size, color and outline without having
to create new bitmap files all the time (e.g. with one of the font-tools provided here).

Best regards,
Andreas

[Nadro]

I don't know if this is technically possible, or even in the engine already, but i would like to see an API to change the font's size, color and outline without having
to create new bitmap files all the time (e.g. with one of the font-tools provided here).

You will be able to change size by matrix - scale component, and font color by SColor value in font rendering method (anyway gradients etc, you should prepare in bitmap file).

[hendu]

TrueType fonts are needed. I don't use the bitmap fonts at all.

[Nadro]

Hmm, maybe we should add TT support in similar way like a Cg, so disabled by default - depends on FreeType library, but I'm not sure if I'll be able to prepare TT suport before v1.9 release.

[luthyr]

Combine font rendering to one draw call per word (current system offer one draw call per sign).

Is there a reason why it couldn't be combined for the entire gui element?

[Nadro]

It's related to textures. Anyway we can combine all signs which use one font texture into one draw call. Anyway some switch method should be available eg. in IGUIEnvironment, for select combine level eg:

Code: Select all

enum E_FONT_COMBINE_TYPE
{
     EFCT_NONE = 0, // cuurent Irrlicht solution,
     EFCT_STANDARD, // combine per word
     EFCT_EXTREME // combine per font file
};
 
IGUIEnvironment::setFontCombineType(E_FONT_COMBINE_TYPE type);

[CuteAlien]

I have not really much ideas right now - ttf support is probably the most requested feature (although possible with workarounds). Buffering font rendering also sometime asked for. Being able to really remove fonts would be nice (but a problem with texture reference counting). Getting sizes without needing workaround like getting dimensions for 'A' was another thing I think. And lot's of bugs and feature-requests for the current fonttool (but by now I doubt we'll ever find someone coding boring maintenance stuff like that for free, one of the problems of opensource I guess).

And funny stuff is last time we tried improving the font-system we failed on agreeing on a solution for serializing the fonts.

Small hint for naming enum's... if you take a look at your comments you will get way better names. Like EFCT_BY_WORD (or EFCT_PER_WORD) instead of a _STANDARD (that doesn't really mean anything and once we chose another default it would get plain confusing). Names should tell what they do.

[christianclavet]

Hmm, maybe we should add TT support in similar way like a Cg, so disabled by default - depends on FreeType library, but I'm not sure if I'll be able to prepare TT suport before v1.9 release.

That would be great!

Where are the font other GUI are rendered? I mean is it rendered in a plane that is covering the view? Can GUI/Font can have RTT? So they could be used as textures? Would also be nice to add shaders to GUI (ex: rectangle with a transparent blur, or text with flame fx).

[chronologicaldot]

What would be nice is just setting the orientation/matrix for drawing images. Considering that text characters are just sprite textures at the moment, if someone does want to orient their text in 3D space, they could simply change the matrix in which the images are drawn.

Plus, setting the world matrix for drawing images would be nice on its own.

Yes, TTF would be nice.
Reminds me... at some point, I still intend to implement vector graphics. Aways off, but I'm still dreaming. *sigh*

[hybrid]

Font rendering uses one call per line already now. So I doubt there will be an improvement here. TrueType and general font serialization are th epoints on the TODO list. And transformation of 2d elements would make more sense when available for whole 2d system probably. As rotating only the fonts wouldn't make up a proper GUI on rotated mobiles, still.

[Granyte]

true type font and the ability to resize the output without having to use an entirely separate file would be great


optionally redesigning the UI to allow for shader use would be awsome (since we already use the 3d pipeline anyway)

if additional help is needed to code this i have some time and anyway it's required for the project my company is working on witch use irrlicht

[Nadro]

It looks like the most important features are:
- Transformation for 2d drawing operations (it's usefull for eg. mobile devices, scale bitmap fonts).
- TT via FreeType support.

I think that we should focus our priority on upper tasks. I'll prepare patch for 2d operations. If someone is interested in prepare patch for TT (integrated with Irrlicht core) it will be good.

[superpws]

How's the progress of Freetype support in Irrlicht 1.9?

[CuteAlien]

Nothing in Irrlicht yet. So you still have to work with workarounds like: http://www.michaelzeilfelder.de/irrlicht.htm#TrueType
(or more solution can be found on the forum). Note that the solution there will _not_ get into Irrlicht - it's using a texture for each character which is really bad (and has an unknown license as the original author never responded to questions about that, so Irrlicht can't use it anyway).