Comments 25
Лютое словоблудие. Вперемешку рассматриваются языки разметки (в том числе векторной), программные расторизаторы и даются намёки на реализацию в GPU. Где упоминание уже отжившего OpenVG, где типичная функциональность развитых 2D GPU Blitter — ов для пояснения того, что в графическом процессоре именуется 2D графикой? Наконец, отсутствует рассмотрение единственных в настоящий момент способов рендеринга векторной графики на GPU…
В сухом остатке в статью все, что должно касаться рендеринга векторной графики на GPU, не попало.
В сухом остатке в статью все, что должно касаться рендеринга векторной графики на GPU, не попало.
> Почему векторная графика 2D намного сложнее, чем 3D
Так почему же? В 2Д художники давно и успешно пользуются кривыми самых разных семейств, а процессоры из 1980х успешно справляются с их растеризацией на стороне пользователя. В 3Д же человечество только начало делать первые робкие шаги к рейтрейсингу в реальном времени, который есть та же растеризация неявных поверхностей. Использование полигонов (грубой линейной аппроксимации) как раз говорит о том, что мы недоросли до использования в 3Д тех же вещей, которыми с лёгкостью оперируем в 2Д.
Если бы 2Д было таким же сложным как 3Д, мы бы читали текст на шрифтах из отрезков прямой и плоских треугольников. Да, с мультисемплингом по краям.
Как пример, движущиеся 3Д-картинки от упомянутого iquilez жрут 100% GPU на последних видеокартах, показывая 30 фпс. И это с учётом их прекрасной распараллеливаемости на фрагментном шейдере.
P.S. За перевод всё равно спасибо.
Так почему же? В 2Д художники давно и успешно пользуются кривыми самых разных семейств, а процессоры из 1980х успешно справляются с их растеризацией на стороне пользователя. В 3Д же человечество только начало делать первые робкие шаги к рейтрейсингу в реальном времени, который есть та же растеризация неявных поверхностей. Использование полигонов (грубой линейной аппроксимации) как раз говорит о том, что мы недоросли до использования в 3Д тех же вещей, которыми с лёгкостью оперируем в 2Д.
Если бы 2Д было таким же сложным как 3Д, мы бы читали текст на шрифтах из отрезков прямой и плоских треугольников. Да, с мультисемплингом по краям.
Как пример, движущиеся 3Д-картинки от упомянутого iquilez жрут 100% GPU на последних видеокартах, показывая 30 фпс. И это с учётом их прекрасной распараллеливаемости на фрагментном шейдере.
P.S. За перевод всё равно спасибо.
Автор имеет в виду сложнее математически/алгоритмически, а не нагрузкой на процессор. И ваш комментарий только подтверждает это.
Так чем сложнее то? Вся математика давно спрятана за библиотеками.
И что, что спрятана? Но она ведь есть.
Примитивный рейтрейсер пишется просто. А попробуйте написать растеризатор AI/SVG — пусть даже не всей спецификации, а только самых основных элементов — очумеете.
Примитивный рейтрейсер пишется просто. А попробуйте написать растеризатор AI/SVG — пусть даже не всей спецификации, а только самых основных элементов — очумеете.
Но ведь и примитивный растеризатор 2Д-сплайна пишется просто, а трёхмерного аналога SVG не существует в принципе. Подозреваю, что сравнимый по выразительности формат для трёхмерных сцен был бы куда сложнее своего двумерного собрата.
Попробуйте реализовать функции заливки и обводки одного-единственного элемента path. Учитывая самопересечения и «заломы» контура (это когда радиус скругления меньше толщины обводки), а также обработку параметра miter limit. Этого хватит, чтобы заработать бессонницу :)
А Вы тем временем реализуйте заливку в пространстве, я так понял, это ведь намного проще?
Очевидно, что 3D во многих случаях значительно труднее 2D, а в остальных — ничуть не легче. Это ведь как 2D, только еще одно измерение. Просто на текущий момент для многих задач попросту нет смысла требовать решения, так как на любой возможный алгоритм не хватит мощностей.
Очевидно, что 3D во многих случаях значительно труднее 2D, а в остальных — ничуть не легче. Это ведь как 2D, только еще одно измерение. Просто на текущий момент для многих задач попросту нет смысла требовать решения, так как на любой возможный алгоритм не хватит мощностей.
Зачем мне реализовывать какие-то абстрактные вещи, которые не только никто нигде не использует, но даже вряд ли сможет сказать, зачем это может понадобиться. Заливка в 3д-сплайне? Нафига, для чего, куда и каким боком её прикрутить? Нет ответа.
Есть реальность и исторически сложившийся технологический ландшафт. О нём и речь.
Есть реальность и исторически сложившийся технологический ландшафт. О нём и речь.
А Вы не думали, что технологический ландшафт сложился как раз на основе имеющихся вычислительных возможностей? Я не прочь использовать все эти якобы сложные поверхности в 3D, вот только реалтайм мне дороже. И это не означает, что этих задач в 3D нет, это означает, что при их решении нужно еще больше изворачиваться, так как фактор производительности стоит намного острее, чем в 2D-графике.
Что вы пытаетесь мне доказать? Что 3d-графика потенциально могла бы быть сложнее, чем 2d? Скорее всего. Но по факту наоборот. А причины такого положения дел можно обсуждать бесконечно.
А автор, думается мне, решил написать эту статью именно потому, что о 3d обычно говорят с придыханием, восхищаются новыми играми и фильмами, облизываются на очередной GPU и прочее-прочее… А «скромный» 2d-мир не замечают, воспринимая его как нечто само собой разумеющееся. Я в браузере гугл открыл и на страничке шрифты отрендерились — ну подумаешь, кого этим можно удивить? Любой дурак может написать html-код, и он работает «сам собой». Хотя на самом деле под капотом там адский ад.
А автор, думается мне, решил написать эту статью именно потому, что о 3d обычно говорят с придыханием, восхищаются новыми играми и фильмами, облизываются на очередной GPU и прочее-прочее… А «скромный» 2d-мир не замечают, воспринимая его как нечто само собой разумеющееся. Я в браузере гугл открыл и на страничке шрифты отрендерились — ну подумаешь, кого этим можно удивить? Любой дурак может написать html-код, и он работает «сам собой». Хотя на самом деле под капотом там адский ад.
Адский ад — это SDF что ли? В том же Unreal'е он вроде как прикручен для сглаживания теней. И никто не распинался, как сложно — сделали и забыли. Потому что по сравнению, например, с PBR — это детский сад.
Восхищаются потому, что это ново — ну нет еще реалистичной графики в реалтайме. Красивые шрифты были в новинку лет тридцать назад, и тогда, насколько я знаю, ими тоже все восхищались. Но серьезно, компетентный в современной 3D графике человек никогда не скажет, что это шрифты сложнее чем 3D.
Восхищаются потому, что это ново — ну нет еще реалистичной графики в реалтайме. Красивые шрифты были в новинку лет тридцать назад, и тогда, насколько я знаю, ими тоже все восхищались. Но серьезно, компетентный в современной 3D графике человек никогда не скажет, что это шрифты сложнее чем 3D.
Не совсем то. Да, она может хранить сплайны, полигоны и много чего ещё. Но что-то я не видел ни одной игры, где модели поставляются пользователю в виде сплайнов и метаболлов в колладе, а потом полигонизируются движком при старте.
А зачем полигонализировать при старте движка, если можно это сделать при экспорте модели?
Так все и делают. Но речь то шла про колладу как трёхмерный аналог SVG. А если мы поставляем только полигоны, то и смысла нет в колладе со всеми её возможностями.
Я в ЗD дилетант, но мне видется что это вполне востребовано, например, в играх типа Space Engineers или просто при прорисовке "плавной" воксельной графики (не майнкрафтстайл, а именно сглаживание с учётом "заполненности" (веса) каждого вокселя). Или задача красивой и реалистичной (с сохранением объёма и/или пощади) незапрограммированной деформации модели (в гонках, например)
а трёхмерного аналога SVG не существует в принципе. Подозреваю, что сравнимый по выразительности формат для трёхмерных сцен был бы куда сложнее своего двумерного собрата.
Даже SVG используется в вебе весьма редко. Насчет выразительнсти можно поспорить, все же xml-подобный формат не добавляет читаемости.
Для 2Д точно так же хватает библиотек.
То что спрятано в 3Д-библиотеках действительно проще описанного в статье. Но простота эта не от того что предметная область проще (как утверждает статья), а от того, что никто даже не думал использовать «настоящую» математику в массовом повседневном 3Д.
То что спрятано в 3Д-библиотеках действительно проще описанного в статье. Но простота эта не от того что предметная область проще (как утверждает статья), а от того, что никто даже не думал использовать «настоящую» математику в массовом повседневном 3Д.
Типо 3d это только mesh'ы, про всякие САПР автор «не знает».
кривые Безье просто частный случай NURBS
Sign up to leave a comment.
Почему векторная графика 2D намного сложнее, чем 3D