Improved font rendering system.

[superpws]

Did you see any other patch for TT support apart from that? I'm curious to know because Nadro's games (simple fun games!) uses Freetype along with Irrlicht, so how would he able to implement Freetype in irrlicht? By using such workarounds? Or did he use lets say CopperCube?

[Nadro]

Hi,

I use this project for TT support in Irrlicht:
http://irrlicht.sourceforge.net/forum/v ... t=truetype

Cheers,

[CuteAlien]

Ah yes - Nalin reworked it some more so it no longer creates 1 Texture per character but puts more on a single texture. I should switch to that as well I suppose. Or maybe he even wrote it from scratch in which case we might even be able to use it (I'l ask him - he hangs around the chat sometimes).

[superpws]

Very well. The class looks clean and the interface is very similar to irrlicht, but it needs some changes in trunk to make it work (e.g, core::ustring etc). Maybe it will take it's place in 1.9

[CuteAlien]

Yeah, Nalin just wrote me that it's written from scratch and put under zlib license. So we can use it. Will try it out within next weeks in one of my projects to check it out.

[superpws]

Glad to hear. You should also include compilation flag for Freetype support in IrrCompileConfig.h as Freetype is licensed under BSD-style license and not everyone use TT fonts so they won't have to comply with license.

[Destructavator]

Hi, I don't know how much this helps, but for my own project (that I've been getting back to) I have a shader-based system for rendering fonts in 3D space, actually creating meshbuffers as needed (planes) in arrays on-the-fly, able to be scaled, rotated on any 3D axis, etc. They use a choice of two or three image textures, one for the foreground, one for a glow / highlight color, and an optional 3rd one for blending with the second with moving coordinates that allow a shimmer / animated glow look. The custom scene node it is all encapsulated in currently uses OpenGL shaders with a few attribute variables passed to the shaders that can color both the foreground letter color as well as the highlight color (including transparency) and part of the beauty of how it works is that it gets the "attributes" not from regular OpenGL functions, but the mesh buffers use the "tangents" version of S3DVertex, with the coloring data added in as the "binormal" and "tangent" variables, the shader code (very simple, I'm sure DirectX versions would be very easy to implement), simply use the extra data for such coloring, so the mesh buffers don't actually use any real tangents, etc. This also allows custom coloring per-letter in a displayed string of text, and doesn't require an end-user of the engine to manually include any GL extension headers or worry about how to check for or use such extensions for vertex attributes. I realize this is non-standard use of the vertex data in the shaders, but it means that re-compiling the engine or going into the source code for it wouldn't be needed.

Actually, for my own project I use a heavily-modified version of Irrlicht based upon the trunk branch, but this font implementation could probably be done with a standard, official build. Again, the special color "attributes" are really just the tangent and binormal data being used in the shader for something they weren't originally intended for.

I have two pics here, one of parts of the font image maps, side by side (the right half shows characters from the glow / shimmer / highlight layer), although for the actual application I use .png files with alpha backgrounds instead of black, and a picture of the font node class in action, with the foreground colors as plain white (255, 255, 255, 255), and the background glow color as black with alpha around ~0.75f (the glow layer is actually white, with the texels simply multiplied by zero for RGB and 0.75f for alpha).

This system allows for custom graphic fonts as well, which don't require a special font editor - a developer with model-making or graphic editing skills could take graphic pictures or even photos and arrange them into letters in Blender or Gimp or Photoshop, InkScape, etc.

The code I wrote for this scans the font map images and automatically sets texture coordinates for each letter, aligns them, applies padding for the second highlight/glow layer, etc...

My own game project is GPL v3, but if anyone wants some of these additions I've been working on to the engine, or my own modifications I've made for the game, I would be willing to release those parts (not specific to my game) under zlib license, same as the official Irrlicht engine.

NOTE: For those who look up this game on SourceForge, the code in the last download is very much out-of-date, since then I've made lots of changes, including getting a working multi-threaded rendering system working with the modified Irrlicht engine I'm using (It really works in my tests, and wasn't as hard as I thought it would be!) and other stuff...

Here's the two pics, and as I said I would imagine a directx version would be easy to also put together:



...and...



...Anyone interested?

[christianclavet]

If you could extract the font rendering system so we could use it with a "vanilla" Irrlicht it would be really nice. Since you create meshbuffers it could work in a new scene node.

[Destructavator]

If you could extract the font rendering system so we could use it with a "vanilla" Irrlicht it would be really nice. Since you create meshbuffers it could work in a new scene node.

OK, sure, I can certainly do that.

I'd also like to mention, although it isn't shown in the example pics, that what I came up with also allows for rotating the text to be angled away from the camera (like the opening intro text from nearly any "Star Wars" film).

I'll put together a version for an unmodified Irrlicht, and also clean up my code just a little at the same time.

I'll also fix one small issue in my code, the fact that as it is coded right now in my own project, it reads the image texture files, sets up the texture coordinates by scanning the images, etc. one time for each class instance. I think it should really be just once per-font instead, so that if a developer uses the new class and has multiple instances of the font being displayed, that the engine doesn't process duplicate jobs all over again in setting up the font (if the texture images used are the same).
I already have a good idea of how to code this as such, I just have to get to work and do it.

One question: I can easily make all this happen for people that use the shader-pipeline branch, do you think those who use the trunk branch in the SVN should have a version too? I think it *might* be possible to do it in the trunk without shaders, although I'd have to do more research on the blending options for textures. Or, I could just code it to use built-in hard-coded shaders (using text in strings, in C/C++ headers, so no external shader data files would be needed). If I use a built-in shader approach I'd have to then include checks to make sure the driver supports it of course, something I do know how to do and wouldn't be hard. Most graphics cards that I know of for quite some time support at least basic, early version shaders, there might be a few users with rather old machines that might get a warning or error message from the logger at runtime about how their gfx card doesn't support any shaders at all for their driver. (I'm familiar with coding shaders that use older versions of OpenGL, I wouldn't require anything fancy like the latest 4.x stuff for example, and there's still plenty of guides for DirectX versions I'm sure I could figure it out.)

[Nadro]

Shaders in trunk works the same as in shader-pipeline, shader-pipeline has support for flexible vertex format and D3D11, but no other advantages over trunk yet. In trunk you can handle blending even easier than in shader-pipeline - just set SMaterial::BlendOperation to something other than EBO_NONE and apply blending factor to SMaterial::BlendFactor (those changes will be merged with shader-pipeline in future). You don't need special material types for a blending.

[kklouzal]

Hey Nadro great work! Any progress on FreeType implementation? I have a request, that it be implemented not as a part of the IGUIEnvironment (since some people compile Irrlicht without GUI but still require 2D/3D text rendering) but possibly as a part of the video driver? While we're on the subject what's the status of Irrlicht 1.9 anyways? were a bit over the '6 months per release' timeframe, makes me excited to see all the new improvements! ;)

[Nadro]

Currently I'm busy with tasks related to my game (I need ~2 weeks), so I don't have a time for Irrlicht tasks. 6 months release cycle is a nice idea, but v1.9 has many new features + core devs daily tasks related to private projects/job cause that we need more time for release v1.9. I think that you should ask CuteAlien about FreeType implementation details and progress, but as I know he's busy with other tasks now.

[CuteAlien]

My current solution is posted here: https://code.google.com/p/irr-playgroun ... ce/browse/ (the CGUITTFont files + gui_font.cpp). Just copy those files into your project. It's not ready yet for Irrlicht and I won't get to working on it more anytime soon I fear (I had to take on a non-Irrlicht project for living and won't be around the next 2 months).

[FloatyBoaty]

My contribution: scalable bitmap font

CGUIFontBitmapScalable.h: http://ideone.com/iXGHGQ

---------------------------------------------
CGUIFontBitmapScalable.cpp: http://ideone.com/arAeu6

------------------------------------------
example use:

Code: Select all

 
    irr::gui::CGUIFontBitmapScalable* BaseApplication::loadFont(irr::io::path relative)
    {
        #ifdef _IRR_COMPILE_WITH_GUI_
        // check if already loaded
        irr::gui::CGUIFontBitmapScalable* font = NULL;
        irr::core::map<irr::io::path, irr::gui::CGUIFontBitmapScalable*>::Node* node = scalableFonts.find(relative);
        if(node) font = node->getValue();
        else font = new irr::gui::CGUIFontBitmapScalable(iGui, relative, iLogger); // not already loaded
 
        if(font->load(getBaseAssetDir() + relative)) return getCheckedFont(relative, font);
        else
        {
            irr::io::path xml = getBaseAssetDir() + relative;
            irr::u32 di = xml.findLast('/') + 1;
            irr::io::path imageDir = xml.subString(0, di);
            irr::io::IXMLReader* xRead = iFileSystem->createXMLReader(xml);
            if(xRead && font->load(xRead, imageDir))
            {
                xRead->drop();
                return getCheckedFont(relative, font);
            }
        }
 
        irr::core::string<irr::c8> err = "Font not loaded: ";
        err.append(getBaseAssetDir() + relative);
        iLogger->log(err.c_str(), irr::ELL_ERROR);
        delete font;
        #endif // _IRR_COMPILE_WITH_GUI_
        return NULL;
    }
 
    #ifdef _IRR_COMPILE_WITH_GUI_
    irr::gui::CGUIFontBitmapScalable* BaseApplication::getCheckedFont(irr::io::path relative, irr::gui::CGUIFontBitmapScalable* font)
    {
        irr::gui::IGUIFont* testFont = iGui->addFont(relative, font);
        irr::gui::CGUIFontBitmapScalable* fontResizable = dynamic_cast<irr::gui::CGUIFontBitmapScalable*>(testFont);
        if(!fontResizable)
        {
            iGui->removeFont(testFont);
            fontResizable = (irr::gui::CGUIFontBitmapScalable*)iGui->addFont(relative, font);
        }
        scalableFonts.insert(relative, fontResizable);
        return fontResizable;
    }
    #endif // _IRR_COMPILE_WITH_GUI_
 
    irr::io::path BaseApplication::getBaseAssetDir()
    {
        #ifdef _IRR_ANDROID_PLATFORM_
        return "";
        #else
        return "assets/";
        #endif // _IRR_ANDROID_PLATFORM_
    }
 

[CuteAlien]

@FloatyBoaty: For some reason (which we haven't found so far) the forum only shows empty posts when too much code is posted in code tags. So I've moved parts of your code to ideone, so people can see it. I hope you are fine with that.