Войти
ПроектыФорумУтилиты

[v 1.1] UBFG - Генератор растровых шрифтов (30 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 129 30 31 3235 Следующая »
#435
22:54, 4 апр. 2014

aczkasow
> Если у тебя не лезут квадраты, не значит, что на других видеочипсетах не
> повылезают ;) На сколько я понимаю стандарт не определяет как именно его должны
> видео карты расчитывать.
Ну да, помимо Nvidia есть ещё AMD и тостеры. Ну может быть люди добрые на утюгах позапускают шейдер и отпишутся:)

aczkasow
> Можно сэкономить на двух вызовах f(), если расписать расчёт градиента в самой
> функции main():
Компилятор GLSL не совсем дурак и у меня вроде бы не было никогда проблем с подстановками. Правда может оказаться, что какой-нибудь драйвер Intel начнёт тупить.

gammaker
> Одна в main, две в градиенте. Или то, что под производными, не вычисляется?
GLSL как и Си - там есть оптимизирующий компилятор. Производителям видеокарт выгодно показывать хорошие результаты в тестах, поэтому компилятор там полноценный оптимизирующий. Надо сказать, что там настолько хороший компилятор, что иногда уделывает собрата - OpenCL.

gammaker
> Кстати, с sdf можно сделать мелкий текст? А то у меня алиасинг появляется. А
> если отрисовывать контур, то он появляется даже, когда текст крупный.
У меня всё без проблем работает, просто нужно уменьшить контраст - остальное сделает интерполяция. Вот тут у меня SDF с маленьким шрифтом:

4 | [v 1.1] UBFG - Генератор растровых шрифтов

Не freetype конечно, но это шрифт всего лишь 7 пунктов и вполне читается.


#436
19:13, 5 апр. 2014

Сделал текст шейдером, аналогичным тому, который в посте #426. Стало очень хорошо, алиасинга теперь почти нет. Но я ещё хочу сделать контур постоянной толщины. Я уже реализовал обводку переменной толщины, используя обычное расстояние, прочитанное из текстуры вот так:
vec3 color=mix(OutlineColor, Color, smoothstep(OutlineThreshold-smoothWidth, OutlineThreshold+smoothWidth, dist)). OutlineThreshold - число около 0.5. Оно немного большее, чем нижняя граница расстояния, ниже которой фрагмент вообще не рисуется. По той ссылке автор использует кучу магических чисел и непонятно, какие использовать нужно мне. И производные я считаю тоже через dFdx, dFdy - они совпадают с теми, которые считает автор 4 выборками из текстуры?

#437
21:17, 5 апр. 2014

gammaker
> dFdx, dFdy - они совпадают с теми, которые считает автор 4 выборками из
> текстуры?
Предполагаю, что не совпадают. Там возможна координатная ошибка в 1-2 пикселя вправо-вверх. Предлага сделать сравнения и выложить картинку с разницей результатов двух методов ;)

#438
21:26, 5 апр. 2014

aczkasow
> Там возможна координатная ошибка в 1-2 пикселя вправо-вверх.
Ну понятно, что по-любому будут отличия. Просто я думал, вдруг это совсем разные вещи и надо делать как-то по-другому, и из-за этого не получается.

#439
21:31, 5 апр. 2014

aczkasow
> Предполагаю, что не совпадают. Там возможна координатная ошибка в 1-2 пикселя
> вправо-вверх. Предлага сделать сравнения и выложить картинку с разницей
> результатов двух методов ;)
Насколько я проверял, не совпадают. Вообще если вручную считать градиент - берётся реальная выборка из текстуры с поправкой на линейную фильтрацию. Но там ещё нужно знать, в каком направлении считать градиент, более того, я пробовал шаг в 1 тексель, и это приводит к странным результатам. В общем, для SDF это ещё надо дорабатывать. И таки да, это довольно разные вещи, я не очень на самом деле понимаю, как dFdx считает производные от фактически float константы.

gammaker
> По той ссылке автор использует кучу магических чисел и непонятно, какие
> использовать нужно мне.
О каких магических числах идёт речь? 0.5 - это половина яркости, нужно преобразовать SDF из диапазона от 0 до 1 в действительно "signed" - без знака градиент вообще не работает.

#440
22:12, 5 апр. 2014

RPG
> И таки да, это довольно разные вещи, я не очень на самом деле понимаю, как dFdx
> считает производные от фактически float константы.

dFdx и dFdy очень просто.
просто вычисляется сразу блок 2x2 ( или более ) экранных пикселей,  и значения берутся из соседних пикселей.
Можно сказать это скорость изменения значения на экранный пиксель.

#441
22:19, 5 апр. 2014

RPG
> О каких магических числах идёт речь?
0.19, 0.20 в smoothstep.
0.01 в вычислении производной. Для произвольной гладкой функции наверное всё равно что брать. А для текстуры непонятно: брать размер 1 пиксель или всё же меньше?
Я пробовал считать производную так:

vec2 distGrad=(dist-vec2(
    texture(samp, TexCoord+vec2(1.0/texSize.x, 0.0)).x, 
    texture(samp, TexCoord+vec2(0.0, 1.0/texSize.y)).x
    ))*texSize;
Получилась вообще непонятная размазня, буквы стали неразличимыми вообще (шейдер похож на шейдер из #426). Видимо значение получилось очень большим, что неудивительно. Но dFdx, и dFdy дают нормальные маленькие значения. То есть функции GLSL - это не совсем производные?
#442
22:31, 5 апр. 2014

http://www.khronos.org/registry/gles/extensions/OES/OES_standard_… rivatives.txt
dFdx  = (F(x+dx)-F(x))/dx
dx = 1 вроде так ка разница между соседними пикселями.
производные не по текстурным координатам, а по 'экрану'.

TexCoord+vec2(1.0/texSize.x, 0.0) - это будет работать когда текстура пиксель в пиксель будет рисоваться.  нужно заменить на текстурные координаты у соседнего пикселя.

#443
22:38, 5 апр. 2014

gammaker
> 0.19, 0.20 в smoothstep.
> 0.01 в вычислении производной.
А, так это и не мой шейдр, а этот: iquilezles.org/www/articles/distance/distance.htm
Поэтому я вряд ли могу помочь с объяснениями. Я так понял имелось ввиду, что автор Иньихо, отсылка к моему посту смутила:)

susageP
> производные не по текстурным координатам, а по 'экрану'.
Кстати, это объясняет, почему разные результаты - у меня координаты пространства текстуры в шейдере. Нужно добавить сюда экранные координаты, не помню только как переменная называется. Вот привязок к размеру текстуры не люблю - это ведёт к бардаку в шейдерах.

#444
23:52, 5 апр. 2014

RPG
> Вот привязок к размеру текстуры не люблю - это ведёт к бардаку в шейдерах.
textureSize же. Правда это появилось только OpenGL (ES) 3.0.

RPG
> Кстати, это объясняет, почему разные результаты - у меня координаты
> пространства текстуры в шейдере.
Всё равно не понимаю. Чем меньше dx, тем производная должна быть точнее по-любому, разве нет? Почему не подходит просто маленькое число, но такое, чтобы погрешности float'а не вылезали? Почему у такой производной различия на порядки?

susageP
> нужно заменить на текстурные координаты у соседнего пикселя.
И как тогда их узнать? Только через тот же dFdx?

#445
0:27, 6 апр. 2014

gammaker
> textureSize же. Правда это появилось только OpenGL (ES) 3.0.
только в OpenGL, да ещё и ES, да ещё и 3.0. Может я уже отстал от жизни и это самый распространённый формат...

gammaker
> Чем меньше dx, тем производная должна быть точнее по-любому, разве нет?
Это фантазии математиков:) Из той же серии, что периметр береговой линии бесконечен. А в суровой реальности есть предел точности текстуры (в нашем случае всего 256 значений яркости), есть пределы для плавающей точки, после чего красивое масштабирование накрывается медным тазом. Погрешность float будет небольшой, если вычислять очень малые значения (миллиардные доли), но одинакового порядка.

#446
1:25, 6 апр. 2014

gammaker
> И как тогда их узнать? Только через тот же dFdx?
dFdx можно сказать появился при появление лодов, на основе изменения текстурной координаты вычислялся лод.

во как с бордюрчиком выглядит.

+ Показать


если  [ (abs(0.5 - tex)<0.1)? 1:0 ]  дает обводку в N пикселя  в масштабе 1к1.
то  [ (abs(0.5 - tex)*texSize/dFdx(texCord)<0.1)? 1:0 ]  дает обводку в N пикселя  при масштабирование.

#447
12:14, 6 апр. 2014

RPG
> только в OpenGL, да ещё и ES, да ещё и 3.0. Может я уже отстал от жизни и это
> самый распространённый формат...
OpenGL 3.0 уже есть практически везде. У меня на нетбуке, купленном 2 года назад, вообще 4.3. А вот на мобильных устройствах OpenGL ES 3.0 только в том году стал появляться и есть ещё не у всех. Хотя уже 3.1 недавно вышел.
То что я указал в скобочках (ES), я имел в виду, что textureSize есть как в обычном OpenGL 3.0, так и в OpenGL ES 3.0.

RPG
> А в суровой реальности есть предел точности текстуры (в нашем случае всего 256
> значений яркости), есть пределы для плавающей точки, после чего красивое
> масштабирование накрывается медным тазом.
Я пробовал для генерации текстур дифференцировать float-текстуры с шагом в 1 тексель. После дифференцирования их яркость тоже повышалась в сотни раз, причём она зависела от разрешения исходника. Здесь уже проблема точности точно не стоит, ведь отнормированные результаты выглядят одинаково при любом разрешении текстуры. Правда у исходных текстур могли быть резкие переходы, которых нет в distance field.

susageP
> abs(0.5 - tex)*texSize/dFdx(texCord)<0.1)? 1:0
Это коэффициент смешивания двух цветов? В этом коде я не вижу никакого сглаживания, а на картинке оно есть. И где здесь число N?

#448
19:45, 6 апр. 2014

Я всё же склоняюсь к простейшему алгоритму, где просто вытягивается контрастность. Заплывы возникают только в том случае, если карта SDF недостаточно качественная (или слишком низкое разрешение), поэтому думаю для борьбы с заплывами лучше подтюнить алгоритм генерации SDF (улучшение алгоритма DownScale в Qt практически устраняет негативные эффекты). Что касается угловатости букв, то это тоже можно компенсировать SDF-картой, добавив немного гауссового размывания. Кроме того, скрипт для ImageMagick, который я опубликовал на хабре, даёт очень хороший результат даже при использовании простейшего шейдера. После того как я поправил скрипт для IM, заплывы исчезли. Единственная проблема, которую я ещё не решил в IM - однопиксельный gap, возникают ошибки, если контур примыкает к границе изображения.

susageP
> то [ (abs(0.5 - tex)*texSize/dFdx(texCord)<0.1)? 1:0 ] дает обводку в N
> пикселя при масштабирование.
Не одобряю ветвления в шейдере. outline эффект делается проще, посмотрите статью. В общем, он повторяет алгоритм Valve, но смысл в том, что никаких медленных операций в шейдере нет.

В итоге алгоритм растеризации шрифтов, которые сейчас используется в движке Cheetah, даёт лучшие результаты и является наиболее быстрым, что немаловажно. http://www.gamedev.ru/projects/forum/?id=179043

#449
9:25, 13 мая 2014

Как дела? Смотрю, последний месяц коммитов так и не было. До сих пор нет моего кода сохранения в бинарный BMFont.
Кстати, я придумал вот ещё что. Можно записывать шрифты прямо в файл изображения.
Например формат ktx поддерживает пары ключ/значение, в который можно запихнуть например тот самый бинарный BMFont. Ktx предназначен специально для OpenGL, поэтому загружается в него очень легко.
Ещё можно сжать текстуру шрифта в DXT1 или в RGTC. Тогда он будет занимать полбайта на тексель. Не знаю, как будет выглядеть distance field, но обычные шрифты сожмутся вообще без потерь.

Страницы: 129 30 31 3235 Следующая »
ПроектыФорумУтилиты