03.05.2014
После того, как удалось нарисовать букву “g”, следующим логичным шагом было бы нарисовать буквы русские, т.е. Юникод. Однако возникает одна небольшая проблема. Имя ей – UTF-8, а точнее – отсутствие встроенных в С++ нормальных механизмов работы с unicode (wchar_t не в счет – это не совсем Юникод). Пока для целей тестирования были взяты определенные коды символов (буквы ё и ѣ), получены их utf-8 коды (0xd1 0×91 и 0xd1 0xa3 соответственно) и уже по этим кодам рассчитаны необходимые данные.
В дальнейшем же при визуализации текста стоит решить, какого подхода придерживаться. Можно использовать UTF-8 и const char, либо wchar_t. Первый вариант дает более компактное представление, но функции strcmp, strlen и т.д. будут работать неправильно. С точки же зрения wchar_t функции будут работать правильно, но в Windows sizeof(wchar_t) = 2, что не совсем Юникод, и кроме того, например, китайские символы – это три байта даже в UTF-8. Поэтому хочется const char и UTF-8, посмотрим что получится.
А теперь что получилось, буквы взяты специально экзотические
“ё”
“ѣ” (ять, да-да тот самый ять :) )
30.04.2014
У меня таки получилось победить артефакты в рендерах, которые я приводил раньше. Однако это потребовало вычисления в шейдере факта попадания точки в контур глифа. Все это привело к ужасающему падению производительности. Т.к. все кривые глифа задавались аналитически и шейдеру приходилось все это рассчитывать в реальном времени.
В качестве оптимизации можно было бы конечно один раз глиф отрисовать в рендер-таргет, а потом просто блит, но это равносильно предрасчету глифов и просто блиту, разве что не во время разработки, а при старте.
Поэтому аналитическую информацию решено было предрасчитать и “запечь” в текстуру, а потом ей только пользоваться. С учетом фильтрации текстур еще и практически бесплатная интерполяция. С помощью библиотечки Cairo удалось просчитать нужную аналитическую информацию и быренько наваять шейдер. Вот что получилось.
Буква “g” при разных приближениях:
Как видно контуры плавные даже при огромном увеличении. Задача минимум (а изначально это вообще была задача максимум) достигнуто. Но дальше, как говориться, “Остапа понесло”.
Контур (красный), кроме того еще и плавный:
Тень (синяя), тоже плавная:
В принципе и тень и контур можно делать жесткими. Но плавными они эффектнее смотряться.
Ну и как обычно – чайник для антуража, плюс в этот раз еще и цветной куб. Так – эксперименты…
29.04.2014
Небольшая заметка. Может сэкономить кому-нибудь кучу времени. Понадобилось тут воспользоваться библиотекой Cairo, да еще чтоб png-шки с прозрачностью генерировать. Так вот, библиотека Cairo позволяет в формате ARGB32 использовать альфу, но только когда вы устанавливаете пиксель, то его нужно умножить на альфу. Иначе не получается.
Т.е. 50% красного будет выглядеть как 0×80800000 а не привычные 0x80ff0000
25.04.2014
Продолжаем работу над реализацией рендеринга шрифтов на шейдерах в движке. Удалось наладить экспорт глифов шрифта из SVG (который получается из TTF) в нужном формате. С учетом преобразования кривых Безье в дуги окружности. Сегодня наладил импорт нужного формата в движок и рендер на шейдерах. Пока правда много багов, но даже первые результаты вполне обнадеживают.
На картинках – красной каемкой обозначена область рендеринга глифа (простой прямоугольник из четырех вершин).
Звездочка, имеются артефакты, вызванные расчетом. В принципе чинятся – надо немного подтюнить математику:
Буква М (перевернута, т.к. сама область рендеринга перевернута – ура 3D преобразованиям). Артефактов практически нет:
А вот знак доллара малость подкачал. Где-то глобальная ошибка в математике. Скорее всего в преобразованиях:
Чайник на фоне – это так – для антуража =)
17.04.2014
Для реализации визуализации шрифтов на шейдерах в движке потребовалось преобразование кривой Безье (кубической, квадратичной) в набор дуг окружности. Долго штудировал математику, просмотрел даже некоторые забугорные whitepaper’s, но красивого решения не нашел.
Исходные данные, кубические кривые:
B = { ( 0, 0 ), ( 0.25, 0.25 ), ( 0.75, 0.75 ), ( 1, 0 ) }
B = { ( 0, 0 ), ( 0.25, 0.75 ), ( 0.75, 0.25 ), ( 1, 1 ) }
B = { ( 0.25, 0.25 ), ( 0.75, 0.75 ), ( 0.25, 0.5 ), ( 0.75, 0.25 ) }
Квадратичные кривые:
B = { ( 0, 0 ), ( 0.75, 0.75 ), ( 1, 0 ) }
B = { ( 0, 0 ), ( 0, 1 ), ( 1, 1 ) }
B = { ( 0.25, 0.25 ), ( 0.75, 0.75 ), ( 0.45, 1 ) }
В итоге был найден достаточно простой рекурсивный алгоритм, которые аппроксимирует кривые. В результате получены следующие картинки.
Кубические кривые (в порядке предоставления входных данных):
Квадратичные кривая (в порядке представления входных данных):
На каждую кривую получается в среднем 5-10 дуг окружностей. Вполне допустимо.
