Comments 10
Из-за особенностей тайловой архитектуры мобильных gpu, ну не взлетит там SDF. Тайловые мобильные gpu отлично справляются с не полупрозрачными треугольниками и плохо со всем остальным) К тому-же SDF не дружит с хардварным сжатием, которое критически необходимо. В общем треугольнички и юбочки для мобилок — наше всё)
>> Тайловые мобильные gpu отлично справляются с не полупрозрачными треугольниками и плохо со всем остальным
Причём тут тайловость? Это проблема конкретно TBDR с акцентом на букву D.
Тайл это просто буфер на чипе.
Причём тут тайловость? Это проблема конкретно TBDR с акцентом на букву D.
Тайл это просто буфер на чипе.
На практике испытывал два метода рисования шрифта на ходу: SDF и прямую триангуляцию.
Задача была в рисовании на произвольном мобильном устройстве новостной страницы (фактически, стена текста), OpenGL ES 2.0, Набор символов произвольный в рамках UCS-2.
Ключевое архитектурное решение — текстурный атлас, в который динамически дописываются отрендеренные символы. Рисование стены текста с атласа при грамотном упаковывании в буферы даёт 60fps на любомбомжфоне телефоне низкой ценовой категории. Отсюда узкое место — обновление атласа, которое непосредственно зависит от скорости рендера символов.
В заданных условиях SDF даёт производительность ниже триангуляции, но даёт преимущества при необходимости анимировать размер шрифта либо делать шрифтовые эффекты (тень, обводку). Кроме того, SDF увеличивает расход памяти на атласы в 1.3-1.6 раза. В идеальном мире стоит использовать оба подхода, SDF применять только для анимируемых символов. Но универсальность API для разработчиков часто требует, чтобы любой текст можно было анимировать, ибо два разных класса текстовых полей — перебор.
Экстраполируя вывод, можно сказать: если не нужно (часто) анимировать по размеру — используйте триангуляцию.
P.S. Кстати, картинки с ошибками аппроксимации есть, а про методы их решения — ни слова. Ну да ладно, материал большой. Лично мне нравится метод из AGG — кроме расчёта ошибки по расстоянию до прямой, мы рассчитываем ошибку ещё и по разнице в углах нормалей в точках аппроксимации, что позволяет уточнить кривую там, где угол кривизны слишком большой. Что позволяет точнее отрисовывать более «кривые» сегменты.
Задача была в рисовании на произвольном мобильном устройстве новостной страницы (фактически, стена текста), OpenGL ES 2.0, Набор символов произвольный в рамках UCS-2.
Ключевое архитектурное решение — текстурный атлас, в который динамически дописываются отрендеренные символы. Рисование стены текста с атласа при грамотном упаковывании в буферы даёт 60fps на любом
В заданных условиях SDF даёт производительность ниже триангуляции, но даёт преимущества при необходимости анимировать размер шрифта либо делать шрифтовые эффекты (тень, обводку). Кроме того, SDF увеличивает расход памяти на атласы в 1.3-1.6 раза. В идеальном мире стоит использовать оба подхода, SDF применять только для анимируемых символов. Но универсальность API для разработчиков часто требует, чтобы любой текст можно было анимировать, ибо два разных класса текстовых полей — перебор.
Экстраполируя вывод, можно сказать: если не нужно (часто) анимировать по размеру — используйте триангуляцию.
P.S. Кстати, картинки с ошибками аппроксимации есть, а про методы их решения — ни слова. Ну да ладно, материал большой. Лично мне нравится метод из AGG — кроме расчёта ошибки по расстоянию до прямой, мы рассчитываем ошибку ещё и по разнице в углах нормалей в точках аппроксимации, что позволяет уточнить кривую там, где угол кривизны слишком большой. Что позволяет точнее отрисовывать более «кривые» сегменты.
Вот такой есть плагин для Unity
Да точно, пропустил. Так а в чем с ним проблема?
SVG не весь правильно парсит (там упор на Adobe Illustrator). Проблемы были и с Inkscape и со Sketch, приходилось руками парсить и править SVG тэги у файлов чтобы импортер нормально их понимал (SVG это такой же «адский» формат как и Collada — у всех какие-то свои тонкости реализации, порядка и способа закрытия тэгов). Ну и собственно минусы, описанные в статье про память на вершины и прочие вещи. Это отнюдь не значит что SVG Importer не нужно использовать. И принцип решения и само решение в этом пакете хороши «как есть» для своего типа задач.
Получается есть проблемы совместимости SVG Importer с некоторыми SVG редакторами, но не более, а в остальном это рабочее решение. Просто резюме вашей статьи «Полноценного решения из коробки пока предложить не могу» что получается не верно
Sign up to leave a comment.
Отрисовка векторной графики — триангуляция, растеризация, сглаживание и новые варианты развития событий