Кто-то может спросить: а почему вокруг 2D так много шума? Это ведь не может быть намного сложнее, чем 3D, верно? 3D — совершенно другое измерение! Тут у нас на носу трассировка лучей в режиме реального времени с точным освещением, а вы не можете осилить невзрачную 2D-графику со сплошными цветами?
Для тех, кто не очень хорошо разбирается в деталях современного GPU, это вправду очень удивительно! Но в 2D-графике множество уникальных ограничений, которые чрезвычайно её усложняют. К тому же она не поддаётся параллелизации. Давайте прогуляемся по исторической дорожке, которая нас сюда привела.
Взлёт PostScript
В начале был плоттер. Первое графическое устройство, способное взаимодействовать с компьютером, называлось «плоттер» (графопостроитель): одно или несколько перьев, способных передвигаться по бумаге. Всё работает по команде «перо-вниз», затем чертёжная головка перемещается неким уникальным способом, возможно, по кривой, и поступает команда «перо-вверх». HP, производитель некоторых из самых ранних плоттеров, на управляющем компьютере использовал вариант BASIC под названием AGL, который затем отправлял команды плоттеру на другом языке, типа HP-GL. В 1970-е годы всё дешевле и популярнее становились графические терминалы, начиная с Tektronix 4010. Он показывал изображение с помощью ЭЛТ, но не обманывайтесь: это не пиксельный дисплей. Tektronix пришёл из индустрии аналоговых осциллографов, и эти машины работают, управляя электронным пучком по определённому пути. Таким образом, у Tektronix 4010 не было пиксельного вывода. Вместо этого вы посылали ему команды в простом графическом режиме, который мог рисовать линии, но, опять же, в режиме «перо вниз», «перо вверх».
Как и во многих других областях, всё изменило изобретение Xerox PARC. Исследователи начали разрабатывать новый тип принтера, более вычислительно выразительный, чем плоттер. Этот новый принтер работал на маленьком стековом тьюринг-полном языке программирования, похожем на Forth, и назвали его… Interpress! Очевидно, Xerox не смогла найти ему достойное применение, поэтому изобретатели покинули корабль и основали маленький стартап под названием Adobe. Они взяли с собой Interpress, а по мере исправления и улучшений тот изменился до неузнаваемости, так что ему дали другое название: PostScript. Помимо милого, тьюринг-полного стекового языка, в четвёртой главе оригинального справочного руководства PostScript Language Reference описана Imaging Model, которая почти идентична современным программным интерфейсам. Пример 4.1 из руководства содержит пример кода, который можно почти построчно перевести на HTML5 <canvas>.
/box { function box() {
newpath ctx.beginPath();
0 0 moveto ctx.moveTo(0, 0);
0 1 lineto ctx.lineTo(0, 1);
1 1 lineto ctx.lineTo(1, 1);
1 0 lineto ctx.lineTo(1, 0);
closepath ctx.closePath();
} def }
gsave ctx.save();
72 72 scale ctx.scale(72, 72);
box fill box(); ctx.fill();
2 2 translate ctx.translate(2, 2);
box fill box(); ctx.fill();
grestore ctx.restore();
Это не совпадение.
Стив Джобс из Apple познакомился с инженерами Interpress во время своего визита в PARC. Джобс думал, что полиграфический бизнес будет прибыльным, и пытался купить Adobe ещё при рождении. Но Adobe выдвинула встречное предложение и в конечном итоге продала Apple пятилетнюю лицензию на PostScript. Третьим столпом в плане Джобса было финансирование небольшого стартапа Aldus, который делал WYSIWYG-приложение для создания PostScript-документов. Оно называлось PageMaker. В начале 1985 года Apple выпустила первый принтер, совместимый с PostScript — Apple LaserWriter. Сочетание Macintosh, PageMaker и LaserWriter мгновенно перевернуло полиграфическую индустрию с ног на голову, а новый хит «настольные издательские системы» укрепил за PostScript его место в истории. Основной конкурент Hewlett-Packard в итоге тоже купил лицензию на PostScript для серии конкурирующих принтеров LaserJet. Это случилось в 1991 году после давления со стороны потребителей.
PostScript медленно перешёл из языка управления принтером в формат файла. Умные программисты изучили, в каком виде команды PostScript отправляются на принтер — и начали создавать документы PostScript вручную, добавив в свои документы диаграммы, графики и рисунки, при этом PostScript использовался для вывода графики на дисплей. Возник спрос на графику вне принтера! Adobe это заметила и быстро выпустила формат Encapsulated PostScript, который представлял собой не более чем несколько специально отформатированных комментариев PostScript с метаданными о размере изображения и ограничениями на использование принтерных команд, таких как “page feed”. В том же 1985 году Adobe начала разработку Illustrator — приложения, где художники работали в формате Encapsulated PostScript в удобном UI. Затем эти файлы можно было перенести в текстовый процессор, который создавал… документы PostScript для отправки на принтеры PostScript. Весь мир перешёл на PostScript, и Adobe не могла быть ещё счастливее. Когда Microsoft работала над Windows 1.0 и хотела создать собственный графический API для разработчиков, основной целью было сделать его совместимым с существующими принтерами, чтобы графика отправлялась на принтеры так же легко, как экран. Этот API в конечном итоге выпустили как GDI — основной компонент, используемый каждым инженером во время стремительного роста популярности Windows в 90-е годы. Поколения программистов на платформе Windows начали неосознанно отождествлять векторную графику 2D с моделью изображений PostScript, закрепив за ней этот статус де-факто.
Единственной серьёзной проблемой PostScript была тьюринг-полнота: просмотр 86-й страницы документа означает сначала запуск скрипта для страниц 1-85. И это может быть медленно. Adobe узнала об этой жалобе пользователей и решила создать новый формат документов, у которого не было таких ограничений, его назвали “Portable Document Format” или для краткости “PDF”. Из него выбросили язык программирования, но графическая технология осталась прежней. Цитата из спецификаций PDF, глава 2.1, «Модель изображения»:
В основе PDF лежит его способность описывать внешний вид сложной графики и типографики. Эта возможность достигается за счёт использования модели изображений Adobe, того же высокоуровневого, независимого от устройства представления, которое используется в языке описания страниц PostScript.
Когда консорциум W3C рассматривал претендентов на язык разметки 2D-графики в интернете, Adobe отстаивала PGML на основе XML, в основе которого лежала графическая модель PostScript:
PGML должен включать в себя модель изображений PDF/PostScript, чтобы гарантировать возможность масштабируемой 2D-графики, которая удовлетворяет потребностям как обычных пользователей, так и профессионалов графики.
Конкурирующий формат VML от Microsoft был основан на GDI, который, как мы знаем, основан на PostScript. Два конкурирующих предложения, которые по-прежнему представляли собой по сути PostScript, объединили вместе, так что W3C принял стандарт «масштабируемой векторной графики» (SVG), который мы знаем и любим сегодня.
Даже если он стар, давайте не будем притворяться, что инновации PostScript, принесённые в этот мир — что-то меньшее, чем технологическое чудо. У PostScript-принтера LaserWriter от Apple процессор был вдвое мощнее, чем у Macintosh, который его контролировал, просто для интерпретации PostScript и растеризации векторных путей до точек на бумаге. Это может показаться чрезмерным, но если вы уже покупали модный принтер с лазером внутри, то не нужно удивляться дорогому процессору. В своём первом воплощении PostScript изобрёл довольно сложную модель визуализации со всеми функциями, которые мы сегодня считаем само собой разумеющимися. Какая самая мощная, потрясающая особенность? Шрифты. В то время шрифты рисовались от руки линейкой и транспортиром и отливались на плёнку для фотохимической печати. В 1977 году Дональд Кнут показал миру, на что способна его система METAFONT, которую он представил вместе с текстовым редактором TeX, но она не прижилась. Она требовала от пользователя математического описания шрифтов, используя кисти и кривые. Большинство разработчиков шрифтов не хотели это изучать. А причудливые изгибы при малых размерах превращались в месиво: у принтеров того времени не было достаточного разрешения, поэтому буквы расплывались и сливались друг с другом. PostScript предложил новое решение: алгоритм «привязки» очертаний к более грубым сеткам, которыми оперировали принтеры. Это известно как «подгонка сетки» (grid-fitting). Чтобы предотвратить слишком большое искажение геометрии, они позволили шрифтам устанавливать «подсказки», какие части геометрии являются наиболее важными и что следует сохранить.
Оригинальная бизнес-модель Adobe заключалась в том, чтобы продавать разработчикам принтеров эту технологию шрифтов и продавать издателям специальные воссозданные шрифты с добавленными подсказками, поэтому Adobe по сей день продаёт свои версии Times и Futura. Кстати, это возможно, потому что шрифты, или, более формально, «гарнитуры», являются одной из пяти вещей, явно исключённых из закона США об авторском праве, поскольку их изначально обозначили как «слишком простые или утилитарные, чтобы быть творческими работами». Вместо этого защищается авторским правом цифровая программа, которая воспроизводит шрифт на экране. Таким образом, чтобы люди не могли копировать шрифты Adobe и добавлять свои собственные, формат Type 1 Font изначально был собственностью Adobe и содержал код «шифрования шрифтов». Только PostScript от Adobe мог интерпретировать шрифты Type 1, и только в них была реализована фирменная технология хинтов, которая обеспечивает чёткость на малых размерах.
Подгонка сетки, кстати, стала настолько популярной, что когда Microsoft и Apple устали платить лицензионные сборы Adobe, то изобрели альтернативный метод для своего альтернативного формата шрифтов TrueType. Вместо того, чтобы указывать декларативные «подсказки», TrueType даёт автору шрифта полноценный тьюринг-полный стековый язык, чтобы автор мог контролировать все аспекты подгонки сетки (избегая патентов Adobe на декларативные хинты). Много лет бушевала война между форматами Adobe Type 1 и TrueType, а разработчики шрифтов застряли посередине, предоставляя пользователям оба формата. В конце концов, индустрия достигла компромисса: OpenType. Но вместо того, чтобы реально определить победителя, они просто плюхнули обе спецификации в один формат файла. Adobe теперь зарабатывала не на продаже шрифтов Type 1, а на программах Photoshop и Illustrator, так что удалила шифровальную часть, доработала формат и представила шрифты CFF / Type 2, которые целиком вошли в OpenType как таблица cff. С другой стороны, TrueType вставили в качестве glyf и других таблиц. Хотя и несколько уродливый, но OpenType вроде бы выполнял работу для пользователей, в основном, брал их измором: просто требуйте, чтобы всё программное обеспечение поддерживало оба типа шрифтов, потому что OpenType требует, чтобы вы поддерживали оба типа шрифтов.
Конечно, мы вынуждены спросить: если не PostScript, то что вместо него? Стоит рассмотреть и другие варианты. Ранее упомянутый METAFONT не использовал строго определённые очертания литер (filled paths). Вместо этого Кнут, в типичной своей манере, в статье «Математическая типографика» предложил для типографики математическую концепцию, которая «наиболее приятна». Вы указываете несколько точек, и какой-то алгоритм находит через них правильную «наиболее приятную» кривую. Можете накладывать эти очертания поверх друг на друга: определить какое-то из них как «перо», а затем «перетащить перо» через какую-то другую линию. Кнут, в глубине души учёный-компьютерщик, ввёл даже рекурсию. Его студент Джон Хобби разработал и реализовал алгоритмы вычисления «самой приятной кривой», наложения вложенных путей и растеризации таких кривых. Для дополнительной информации о METAFONT, кривых и истории типографики в целом настоятельно рекомендую книгу «Шрифты и кодировки», а также статьи Джона Хобби.
К счастью, возобновившийся интерес к исследованиям 2D-графики означал, что сплайны Кнута и Хобби не полностью забыли. Хотя они определённо заумные и нетрадиционные, но они недавно пробрались в Apple iWork Suite, и являются там типом сплайна по умолчанию.
Взлёт треугольников
Не слишком вдаваясь в математические дебри, на высоком уровне мы называем такие подходы, как кривые Безье и сплайны Хобби, неявными кривыми, потому что они указаны как математическая функция, которая генерирует кривую. Они хорошо смотрятся на любом разрешении, что отлично подходит для 2D-изображений, предназначенных для масштабирования.
2D-графика поддержала импульс вокруг этих неявных кривых, которые почти обязательны при моделировании глифов. Аппаратное и программное обеспечение для вычисления этих путей в режиме реального времени было дорогим, но из полиграфической промышленности пришёл большой толчок для векторной графики, а большая часть остального существующего промышленного оборудования уже была намного дороже, чем лазерный принтер с причудливым процессором.
Однако 3D-графика пошла совсем по другому маршруту. С самого начала почти универсальным подходом было использование многоугольников (полигонов), которые часто вручную размечались и вручную вводились в компьютер. Впрочем, такой подход не был универсальным. 3D-эквивалент неявной кривой — это неявная поверхность, состоящая из основных геометрических примитивов, таких как сферы, цилиндры и кубы. Идеальная сфера с бесконечным разрешением может быть представлена простым уравнением, поэтому на заре развития 3D для геометрии она была явно предпочтительнее полигонов. Одна из немногих компаний, которые разрабатывали графику с неявными поверхностями, была MAGI. В сочетании с умным художественным использованием процедурных текстур они выиграли контракт с Disney на дизайн «светового мотоцикла» для фильма «Трон» 1982 года. К сожалению, этот подход быстро сошёл на нет. Благодаря ускорению CPU и исследованию таких проблем, как «удаление скрытой поверхности», стремительно росло количество треугольников, которые вы могли бы отобразить в сцене, а для сложных фигур художникам было намного проще думать о полигонах и вершинах, которые можно щёлкнуть и перетащить, а не использовать комбинации кубов и цилиндров.
Это не означает, что неявные поверхности не использовались в процессе моделирования. Техники вроде алгоритма Кэтмелла — Кларка к началу 80-х годов стали общепринятым отраслевым стандартом, позволяя художникам создавать гладкие, органичные простые геометрические формы. Хотя до начала 2000-х годов алгоритм Кэтмелла — Кларка даже не определялся как «неявная поверхность», которую можно вычислить с помощью уравнения. Тогда это рассматривалось как итерационный алгоритм: способ разделения полигонов на ещё большее количество полигонов.
Треугольники захватили мир, и за ними последовали инструменты для создания 3D-контента. Новые разработчики и дизайнеры видеоигр и спецэффектов в фильмах обучались исключительно на программах моделирования с полигональными сетками, таких как Maya, 3DS Max и Softimage. Когда в конце 80-х годов на сцене появились «ускорители 3D-графики» (GPU), их разработали специально для ускорения существующего контента: треугольников. Хотя в ранних проектах GPU, таких как NVIDIA NV1, имелась ограниченная аппаратная поддержка кривых, но она глючила, и её быстро убрали из линейки продуктов.
Эта культура в основном распространяется на то, что мы видим сегодня. Доминирующая модель 2D-изображений PostScript началась с продукта, который мог отображать кривые в «реальном времени». В то же время 3D-индустрия игнорировала кривые, с которыми трудно работать, а вместо этого полагалась на автономные решения для предварительного преобразования кривых в треугольники.
Неявные поверхности возвращаются
Но почему неявные кривые 2D можно было просчитывать в режиме реального времени на принтере в 80-е годы, и те же самые неявные кривые 3D по-прежнему сильно глючат в начале 2000-х? Ну, алгоритм Кэтмелла — Кларка намного сложнее, чем кривая Безье. Кривые Безье в 3D известны как B-сплайны, и они хорошо вычислимы, но есть недостаток, что они ограничивают способы соединения сетки. Поверхности вроде Кэтмелла — Кларка и NURBS допускают произвольно связанные сетки для расширения возможностей художников, но это может привести к полиномам больше четвёртой степени, которые, как правило, не имеют аналитического решения. Вместо этого вы получаете аппроксимации, основанные на разделении полигонов, как это делается в OpenSubdiv от Pixar. Если кто-то когда-либо найдет аналитическое решение для поиска корней Кэтмелла — Кларка или NURBS, компания Autodesk много ему заплатит. По сравнению с ними треугольники кажутся намного приятнее: просто вычислите три линейных уравнения на плоскости, и у вас есть лёгкий ответ.
… Но что, если нам не нужно точное решение? Именно таким вопросом задался графический разработчик Иньиго Кильес, когда проводил исследования неявных поверхностей. Решение? Поля расстояний со знаком (signed distance fields, SDF). Вместо выдачи точной точки пересечения с поверхностью они говорят, как далеко вы находитесь от неё. Аналогично разнице между аналитически вычисленным интегралом и интегралом Эйлера, если у вас есть расстояние до ближайшего объекта, вы можете «маршировать» по сцене, в любой заданной точке спрашивая, как далеко вы находитесь, и проходя это расстояние. Такие поверхности вдохнули совершенно новую жизнь в индустрию через демосцену и сообщества вроде Shadertoy. Хак старой техники моделирования MAGI приносит нам невероятные находки, такие как Surfer Boy от Кильеса, рассчитанный с бесконечной точностью как неявная поверхность. Вам не нужно искать алгебраические корни Surfer Boy, вы просто чувствуете, как проходит сцена.
Конечно, проблема в том, что сотворить Surfer Boy способен только гений вроде Кильеса. Ещё нет инструментов для геометрии SDF, весь код пишется вручную. Тем не менее, учитывая захватывающее возрождение неявных поверхностей и естественные формы кривых, теперь к этой технике много интереса. Игра MediaMolecule Dreams на PS4 — это набор для создания контента, основанный на комбинировании неявных поверхностей. В процессе разрушается и создаётся заново большая часть традиционной графики. Это многообещающий подход, а инструменты интуитивно понятны и интересны. Oculus Medium и unbound.io тоже провели хорошие исследования по этой проблеме. Это определённо многообещающий взгляд на то, как может выглядеть будущее 3D-графики и инструментов следующего поколения.
Но некоторые из этих подходов меньше подходят для 2D, чем вы могли бы подумать. В общих игровых 3D-сценах, как правило, продвинутые материалы и текстуры, но мало расчётов геометрии, на что сразу указывают многие критики и продавцы сомнительных продуктов. Это означает, что нам меньше требуется сглаживание, поскольку силуэты не так важны. Подходы вроде 4x MSAA могут подойти для многих игр, но для маленьких шрифтов со сплошными цветами вы вместо 16 фиксированных выборочных местоположений скорее вычислите точную площадь под кривой для каждого пикселя, что даст вам столько разрешения, сколько хотите.
Вращение экрана в 3D-игре вызывает эффекты, похожие на саккадическое подавление, поскольку мозг перенастраивается на новый вид. Во многих играх это помогает скрыть артефакты в эффектах постобработки, таких как временное сглаживание, на которые сильно полагаются Dreams и unbound.io, чтобы получить хорошую производительность сцены. И наоборот, в типичной 2D-сцене у нас нет этой роскоши перспективы, поэтому попытка использовать её заставит глифы и формы кипеть и дрожать с этими артефактами по полной программе. На 2D смотрят иначе, и ожидания выше. При масштабировании, панорамировании и прокрутке важна стабильность.
Ни один из этих эффектов невозможно реализовать на GPU, но они показывают радикальный отход от “3D” контента, с другими приоритетами. В конечном счёте, рендеринг 2D-графики сложен, потому что речь идёт о формах — точных буквах и символах, а не о материалах и освещении, у которых в основном сплошной цвет. Графические ускорители в результате эволюции решили не обсчитывать неявную геометрию реального времени, такую как кривые, а вместо этого сконцентрировались на всём, что происходит внутри этих кривых. Возможно, если бы PostScript не победил, у нас была бы 2D-модель изображения без кривых Безье в качестве основного требования для реального времени. Возможно, в таком мире вместо треугольников бы использовались лучшие геометрические представления, инструменты создания контента сосредоточились на 3D-сплайнах, а GPU поддерживали кривые реального времени на аппаратном уровне. В конце концов, всегда забавно помечтать.
Комментарии (25)
SergeySib
12.05.2019 14:42> Почему векторная графика 2D намного сложнее, чем 3D
Так почему же? В 2Д художники давно и успешно пользуются кривыми самых разных семейств, а процессоры из 1980х успешно справляются с их растеризацией на стороне пользователя. В 3Д же человечество только начало делать первые робкие шаги к рейтрейсингу в реальном времени, который есть та же растеризация неявных поверхностей. Использование полигонов (грубой линейной аппроксимации) как раз говорит о том, что мы недоросли до использования в 3Д тех же вещей, которыми с лёгкостью оперируем в 2Д.
Если бы 2Д было таким же сложным как 3Д, мы бы читали текст на шрифтах из отрезков прямой и плоских треугольников. Да, с мультисемплингом по краям.
Как пример, движущиеся 3Д-картинки от упомянутого iquilez жрут 100% GPU на последних видеокартах, показывая 30 фпс. И это с учётом их прекрасной распараллеливаемости на фрагментном шейдере.
P.S. За перевод всё равно спасибо.dom1n1k
12.05.2019 15:18Автор имеет в виду сложнее математически/алгоритмически, а не нагрузкой на процессор. И ваш комментарий только подтверждает это.
TheShock
12.05.2019 15:52Так чем сложнее то? Вся математика давно спрятана за библиотеками.
dom1n1k
12.05.2019 16:32+1И что, что спрятана? Но она ведь есть.
Примитивный рейтрейсер пишется просто. А попробуйте написать растеризатор AI/SVG — пусть даже не всей спецификации, а только самых основных элементов — очумеете.SergeySib
12.05.2019 16:41Но ведь и примитивный растеризатор 2Д-сплайна пишется просто, а трёхмерного аналога SVG не существует в принципе. Подозреваю, что сравнимый по выразительности формат для трёхмерных сцен был бы куда сложнее своего двумерного собрата.
dom1n1k
12.05.2019 17:16Попробуйте реализовать функции заливки и обводки одного-единственного элемента path. Учитывая самопересечения и «заломы» контура (это когда радиус скругления меньше толщины обводки), а также обработку параметра miter limit. Этого хватит, чтобы заработать бессонницу :)
picul
12.05.2019 17:31А Вы тем временем реализуйте заливку в пространстве, я так понял, это ведь намного проще?
Очевидно, что 3D во многих случаях значительно труднее 2D, а в остальных — ничуть не легче. Это ведь как 2D, только еще одно измерение. Просто на текущий момент для многих задач попросту нет смысла требовать решения, так как на любой возможный алгоритм не хватит мощностей.dom1n1k
12.05.2019 17:43Зачем мне реализовывать какие-то абстрактные вещи, которые не только никто нигде не использует, но даже вряд ли сможет сказать, зачем это может понадобиться. Заливка в 3д-сплайне? Нафига, для чего, куда и каким боком её прикрутить? Нет ответа.
Есть реальность и исторически сложившийся технологический ландшафт. О нём и речь.picul
12.05.2019 19:23А Вы не думали, что технологический ландшафт сложился как раз на основе имеющихся вычислительных возможностей? Я не прочь использовать все эти якобы сложные поверхности в 3D, вот только реалтайм мне дороже. И это не означает, что этих задач в 3D нет, это означает, что при их решении нужно еще больше изворачиваться, так как фактор производительности стоит намного острее, чем в 2D-графике.
dom1n1k
12.05.2019 20:47Что вы пытаетесь мне доказать? Что 3d-графика потенциально могла бы быть сложнее, чем 2d? Скорее всего. Но по факту наоборот. А причины такого положения дел можно обсуждать бесконечно.
А автор, думается мне, решил написать эту статью именно потому, что о 3d обычно говорят с придыханием, восхищаются новыми играми и фильмами, облизываются на очередной GPU и прочее-прочее… А «скромный» 2d-мир не замечают, воспринимая его как нечто само собой разумеющееся. Я в браузере гугл открыл и на страничке шрифты отрендерились — ну подумаешь, кого этим можно удивить? Любой дурак может написать html-код, и он работает «сам собой». Хотя на самом деле под капотом там адский ад.picul
12.05.2019 21:28+2Адский ад — это SDF что ли? В том же Unreal'е он вроде как прикручен для сглаживания теней. И никто не распинался, как сложно — сделали и забыли. Потому что по сравнению, например, с PBR — это детский сад.
Восхищаются потому, что это ново — ну нет еще реалистичной графики в реалтайме. Красивые шрифты были в новинку лет тридцать назад, и тогда, насколько я знаю, ими тоже все восхищались. Но серьезно, компетентный в современной 3D графике человек никогда не скажет, что это шрифты сложнее чем 3D.
Taraflex
12.05.2019 20:38SergeySib
12.05.2019 22:12Не совсем то. Да, она может хранить сплайны, полигоны и много чего ещё. Но что-то я не видел ни одной игры, где модели поставляются пользователю в виде сплайнов и метаболлов в колладе, а потом полигонизируются движком при старте.
picul
12.05.2019 23:59А зачем полигонализировать при старте движка, если можно это сделать при экспорте модели?
SergeySib
13.05.2019 08:57Так все и делают. Но речь то шла про колладу как трёхмерный аналог SVG. А если мы поставляем только полигоны, то и смысла нет в колладе со всеми её возможностями.
ksbes
13.05.2019 11:09Я в ЗD дилетант, но мне видется что это вполне востребовано, например, в играх типа Space Engineers или просто при прорисовке "плавной" воксельной графики (не майнкрафтстайл, а именно сглаживание с учётом "заполненности" (веса) каждого вокселя). Или задача красивой и реалистичной (с сохранением объёма и/или пощади) незапрограммированной деформации модели (в гонках, например)
KvanTTT
13.05.2019 01:41а трёхмерного аналога SVG не существует в принципе. Подозреваю, что сравнимый по выразительности формат для трёхмерных сцен был бы куда сложнее своего двумерного собрата.
Даже SVG используется в вебе весьма редко. Насчет выразительнсти можно поспорить, все же xml-подобный формат не добавляет читаемости.
SergeySib
13.05.2019 09:08Под выразительностью я понимал разнообразие способов задания модели. Чтобы можно было в разных сочетаниях комбинировать полигоны и неявные поверхности различного вида. Формат при этом может быть вообще бинарным.
SergeySib
12.05.2019 16:46Для 2Д точно так же хватает библиотек.
То что спрятано в 3Д-библиотеках действительно проще описанного в статье. Но простота эта не от того что предметная область проще (как утверждает статья), а от того, что никто даже не думал использовать «настоящую» математику в массовом повседневном 3Д.
anger32
Лютое словоблудие. Вперемешку рассматриваются языки разметки (в том числе векторной), программные расторизаторы и даются намёки на реализацию в GPU. Где упоминание уже отжившего OpenVG, где типичная функциональность развитых 2D GPU Blitter — ов для пояснения того, что в графическом процессоре именуется 2D графикой? Наконец, отсутствует рассмотрение единственных в настоящий момент способов рендеринга векторной графики на GPU…
В сухом остатке в статью все, что должно касаться рендеринга векторной графики на GPU, не попало.