Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 22
Четырёхугольные спрайты-полигоны были реализованы в 3DO, Sega Saturn, в некоторых аркадных автоматах и в видеокарте NVidia NV1.
Mode7 никакого отношения к перспективе сам по себе не имел, по сути это всего лишь один составной спрайт (тайловая карта), который можно вращать и масштабировать. Его нельзя было наклонять или двигать отдельные углы. Это достигалось уже программно, изменением параметров вращения и масштаба на каждой строке растра таким образом, чтобы в эту строку попала нужным образом повёрнутая и растянутая строка исходного спрайта — как бы построчная растеризация полигона.
Mode7 никакого отношения к перспективе сам по себе не имел, по сути это всего лишь один составной спрайт (тайловая карта), который можно вращать и масштабировать. Его нельзя было наклонять или двигать отдельные углы. Это достигалось уже программно, изменением параметров вращения и масштаба на каждой строке растра таким образом, чтобы в эту строку попала нужным образом повёрнутая и растянутая строка исходного спрайта — как бы построчная растеризация полигона.
Да я писал его на высоком уровне по приколу. Но на сколько я узнавал исторически. На консолях это был специальный режим рисования спрайта, который аппаратно брал на себя ускорение конкретно афинных преобразований. Этого хватало только для поворота, масштаба и сдвига. Потому оси X и Y вращать было можно, — это есть в афинных. А вот Z нету, и ни как виртаульно она не добавлялась. Впрочем прямого управления ею нет в большинстве 3д игр. Перспектива же добавлялась хаком нарезания полос, но не обязательно только по строкам растра, иногда даже по несколько строк одним ректом, в зависимости от требований скорость/качество. Чем ближе была полоса, тем больше зум. А в консолях шел этот режим за номером семь. Я вспомнил его здесь как пасхалочку для знатоков.
Нашел сейчас его у себя в загашниках, но версию с классическим MODE7 для поворота/наклона/смещения положенного в перспективу пола деплоить лень (она не тема этой статьи и для интересующих это гуглиться) Зато могу задеплоить бенчмарк, который как раз не тривиально использует наклон:
codepen.io/impfromliga/full/qBNomVO
Скрол меняет угол наклона в поверхность.
Дополнительно колесо мыши меняет «скважность» полос для теста скорость/качество
Очень наглядно видно насколько большими полосами можно было относительно качественно эту перспективу хакать.
Нашел сейчас его у себя в загашниках, но версию с классическим MODE7 для поворота/наклона/смещения положенного в перспективу пола деплоить лень (она не тема этой статьи и для интересующих это гуглиться) Зато могу задеплоить бенчмарк, который как раз не тривиально использует наклон:
codepen.io/impfromliga/full/qBNomVO
Скрол меняет угол наклона в поверхность.
Дополнительно колесо мыши меняет «скважность» полос для теста скорость/качество
Очень наглядно видно насколько большими полосами можно было относительно качественно эту перспективу хакать.
А в консолях шел этот режим за номером семь.
Всё же всего на одной консоли, SNES. Схожий функционал в GBA и Sega CD имеет свои номера (2 на GBA и никакого на Sega CD). Mode 7 просто стало именем нарицательным для перспективной проекции а-ля трасса в F-Zero, это название использовалось в рекламных материалах (на коробке с игрой) и потому ушло в народ, не особо разбирающийся в технических деталях.
Да я понимаю что нарицательным, сам его так же использую, потому что keyword гуглиться. Просто лично его не застал, не достаточно олд я…
Хотя при анализе приема, для чего писался бенч, — Возможности этого режима позволят рендерить не только пол/небо, но даже что-то вроде DOOM1 like рейкастинга, теоретически. Только кастить надо будет интеллектуально, что бы получать углы стен.
— Кстати нужно заметить что HTML5 Canvas окружение без webGL является по сути тем же окружением. Встречал на этом алгоритмы развертки сферической панорамы в проекцию 3д камеры. Что бы сделать как в yandex панорамах. Как один из fallback'ов для неподдерживающих ничегошеньки устройств. Причем на CSS2 то же есть реализации, но суть не меняется — Суметь нарезать кривое на плоское
Хотя при анализе приема, для чего писался бенч, — Возможности этого режима позволят рендерить не только пол/небо, но даже что-то вроде DOOM1 like рейкастинга, теоретически. Только кастить надо будет интеллектуально, что бы получать углы стен.
— Кстати нужно заметить что HTML5 Canvas окружение без webGL является по сути тем же окружением. Встречал на этом алгоритмы развертки сферической панорамы в проекцию 3д камеры. Что бы сделать как в yandex панорамах. Как один из fallback'ов для неподдерживающих ничегошеньки устройств. Причем на CSS2 то же есть реализации, но суть не меняется — Суметь нарезать кривое на плоское
Я могу говорить только за реальный Mode 7 и SNES, т.к. знаю, как они работают и что с ними делать. За абстрактный программный Mode 7-подобный рендер сказать ничего не могу, т.к. его можно сделать каким угодно. Оригинальный же Mode 7 позволил бы рендерить стены а-ля Wolf 3D только если положить телевизор на бок, т.к. мы можем менять параметры рендера каждую строку (через HDMA), но никак не можем менять их каждый столбец.
Ахахах, сразу видно единомышленника…
— Когда я размышлял как успеть выдать рейкастинг с микроконтроллера софтверно синтезирующего VGA сигнал, при том что памяти на экранный буфер у него нет, но есть на строки, в которых паузы пока возваращается луч в развертке 20% времени… И хотя нужно гораздо больше, можно подготавливать строку отложенно, пока предыдущая подготовленная пуляет копии.
Но телевизор на бок все таки прийдется положить…
Человечество просчиталось… развертку надо было делать сначало по строкам.
Так и горизонтальное разрешение было бы выше — что полезно и для шрифта.
Хотя сейчас можно найти дисплеи с возможностью поворота изображения на бок.
— возможно по этим же причинам (ход луча) на SNES апи было горизонтально ориентированным…
— Когда я размышлял как успеть выдать рейкастинг с микроконтроллера софтверно синтезирующего VGA сигнал, при том что памяти на экранный буфер у него нет, но есть на строки, в которых паузы пока возваращается луч в развертке 20% времени… И хотя нужно гораздо больше, можно подготавливать строку отложенно, пока предыдущая подготовленная пуляет копии.
Но телевизор на бок все таки прийдется положить…
Человечество просчиталось… развертку надо было делать сначало по строкам.
Так и горизонтальное разрешение было бы выше — что полезно и для шрифта.
Хотя сейчас можно найти дисплеи с возможностью поворота изображения на бок.
— возможно по этим же причинам (ход луча) на SNES апи было горизонтально ориентированным…
фиксированная точка => fixed point, а не strict point.
Можно узнать а зачем вы хотите нарезать квады на трапеции?
Вроде же в статье обьяснил. Или вам интересно конкретно зачем я хочу их нарезать? Но это тогда не корректный вопрос — Just we can, как говориться. Но могу ответить о практическом применении.
В действительности статья с практической т.з. слегка запоздала. Лет так на 50, во времена ZX Spectrum, когда набирали популярность видео ускорители. Она больше как «развлекательная математика». Однако, если постараться то практическое применение и кроме «разминки для мозга» этому еще можно найти:
— ПЛИСы для собственных задач графической отрисовки.
— Микроконтроллеры БЕЗ графического ускорения.
В действительности статья с практической т.з. слегка запоздала. Лет так на 50, во времена ZX Spectrum, когда набирали популярность видео ускорители. Она больше как «развлекательная математика». Однако, если постараться то практическое применение и кроме «разминки для мозга» этому еще можно найти:
— ПЛИСы для собственных задач графической отрисовки.
— Микроконтроллеры БЕЗ графического ускорения.
Рассмотренные вами варианты сводятся к задаче заливки треугольника или отображения одного треугольника в другой. Но аппаратная реализация этих функций и стала тем, что впоследствии назвали «3D ускоритель».
Первые 3D-ускорители специализировались именно на маппинге текстур, т.е. отображении текстуры из одних треугольников в другие. Потом уже появились прочие плюшки, такие, как интерполяция, расчёты проективной геометрии, Z-buffer, шейдеры и т.д.
Мне в своё время пришлось прибегать к средствам 3D-графики для создания двумерных анимаций. Хорошо легли на маппинг текстур такие задачи, как повороты на произвольный угол, изменение масштаба.
Первые 3D-ускорители специализировались именно на маппинге текстур, т.е. отображении текстуры из одних треугольников в другие. Потом уже появились прочие плюшки, такие, как интерполяция, расчёты проективной геометрии, Z-buffer, шейдеры и т.д.
Мне в своё время пришлось прибегать к средствам 3D-графики для создания двумерных анимаций. Хорошо легли на маппинг текстур такие задачи, как повороты на произвольный угол, изменение масштаба.
Сейчас ясно что все сводят к треугольникам. Но я тут про 2D ускорители и алгоритмическую сложность. То что задача заливки треугольника сводиться к описанным двум трапециям я упомянул. А не наоборот! Достаточно вспомнить классический алгоритм заливки треугольника. (см. compgraphics.info/2D/triangle_rasterization.php ) Потому более гибким вариантом 2D апи будет, — иметь ускоритель трапеции. Не говоря уже о том, что она рендериться эффективнее.
А треугольник современный, это вообще другое! Он учитывает перспективу при текстурировнии. Т.е. у его вершин есть глубина! И это сразу привет 4х4 матрицы! Кстати как тут уже обсуждалось, матрицы в 2D таки приходили (см. SNES Mode7), но только Афинные 3х3 (можно и 2х3, норма на плоскости довольно бесполезна).
И подводя итог про апогей 2D функционала ускорителей:
— На мой взгляд он почему-то не наступил. Может из-за того, что поддержка более ресурсозатратных треугольников просто пришла раньше.
А треугольник современный, это вообще другое! Он учитывает перспективу при текстурировнии. Т.е. у его вершин есть глубина! И это сразу привет 4х4 матрицы! Кстати как тут уже обсуждалось, матрицы в 2D таки приходили (см. SNES Mode7), но только Афинные 3х3 (можно и 2х3, норма на плоскости довольно бесполезна).
И подводя итог про апогей 2D функционала ускорителей:
— На мой взгляд он почему-то не наступил. Может из-за того, что поддержка более ресурсозатратных треугольников просто пришла раньше.
Было бы интересно глянуть на софтверный движок, манипулирующий такими тайлами. Нынче развелось много фантазийных консолей, вроде PICO-8, TIC-80 и иже с ними, где эта тема представляет изрядный интерес.
Все же уточню свой вопрос:
1. Вся отрисовывемая карта состоит только из паралеллепипедов?
2. Поворот камеры производится в реальном времени на произвольный угол?
3. Это будет чистая изометрия или все таки перспективная проекция?
4. У паралеллепипеда можно наблюдать от одной до трех сторон (горизонтальная, фронтальная, саггитальная). Предположим что для каких то движений камеры рендеринг одной из сторон оптимизировали, что там с оставшимися сторонами? Как их выводить, 3D-полигонами?
1. Вся отрисовывемая карта состоит только из паралеллепипедов?
2. Поворот камеры производится в реальном времени на произвольный угол?
3. Это будет чистая изометрия или все таки перспективная проекция?
4. У паралеллепипеда можно наблюдать от одной до трех сторон (горизонтальная, фронтальная, саггитальная). Предположим что для каких то движений камеры рендеринг одной из сторон оптимизировали, что там с оставшимися сторонами? Как их выводить, 3D-полигонами?
1. На скрине из демки? — да. Только там оно не выводиться на процессоре.
2. Эта крутиться на 8 углов. (почти точных). Версию с произвольным углом выпилил, там проверялся другой концепт. Если посмотреть, там хитро стоит камера, что 3й этаж совпадает с регулярной сеткой первого. Это что б оно с танцами, но переносилось и на «прямоугольные» ускорители.
3. «ЭТО» уже есть. Демка весьма опосредованное отношение имеющая к сути данной статьи.
4. Зависит от того что выводить и что доступно для оптимизации. Плоскости с такими названиями у вас сохранятся только в фронтальной перспективной проекции (одноточечьной) поворот камеры у нее будет строго зафиксированным по ортогональным осям. Это как в первых 3D рогалках с поворотом строго на 90гр. Если двухточечную перспективу делать, то фиксированной останется одна ось (обычно вертикальная). А плоскости утратятся: Фронтальная потеряет свойство перпендикулярности камеры и вывести ее только скелингом уже неудастся. Однако вместе с саггитальной они сохранят свойство параллельности вертикали. Это позволяет выводить их методами на подобии mode7. Или если говорить о барметал использовать обрезанные матрицы (с читерской Y составляющей, которая всегда будет равняться 1). Но горизонтальная плоскость потеряет любую параллельность экранным ортогоналям, и выводить ее с текстурированной будет трудно. Mode7 прийдется резать вобще на кубики вместо полосок и это будет еще корявее…
Описанное мной в статье НЕ для перспективного текстурирования. А для разного рода текстурированных Изометрий привлекательно. Про полноценность 3D топить не надо. Изометрия это пространство 3х измерений. Просто с отсутствием искажений размеров по Z.
Более того она вполне законно существует в реальности — у Снайпера на дальние дистанции практически исчезает перспективный эффект. У фото съемок со спутника тоже практическая изометрия.
В принципе если вам очень нужно искажение размеров по Z используйте паралакс, на слоях рисуемой в глубину top-down проекции. Но у нее фиксированый 90гр поворот вертикальной оси. Это то как рисовалась «формулы 1». Но это единственная проекция которую можно вывести с текстурированием и перспективой. Важно указать, что «перспектива» здесь будет только относительно размеров обьектов, но не их граней относительно друг друга. Потому в такой проекции нет особого смысла рисовать грани отдельными вызовами. С трапециями можно было бы пробовать cavalier проекции. слегка в нахлест кубами класть. И скалировать слои в глубину. Если что глядите тут
2. Эта крутиться на 8 углов. (почти точных). Версию с произвольным углом выпилил, там проверялся другой концепт. Если посмотреть, там хитро стоит камера, что 3й этаж совпадает с регулярной сеткой первого. Это что б оно с танцами, но переносилось и на «прямоугольные» ускорители.
3. «ЭТО» уже есть. Демка весьма опосредованное отношение имеющая к сути данной статьи.
4. Зависит от того что выводить и что доступно для оптимизации. Плоскости с такими названиями у вас сохранятся только в фронтальной перспективной проекции (одноточечьной) поворот камеры у нее будет строго зафиксированным по ортогональным осям. Это как в первых 3D рогалках с поворотом строго на 90гр. Если двухточечную перспективу делать, то фиксированной останется одна ось (обычно вертикальная). А плоскости утратятся: Фронтальная потеряет свойство перпендикулярности камеры и вывести ее только скелингом уже неудастся. Однако вместе с саггитальной они сохранят свойство параллельности вертикали. Это позволяет выводить их методами на подобии mode7. Или если говорить о барметал использовать обрезанные матрицы (с читерской Y составляющей, которая всегда будет равняться 1). Но горизонтальная плоскость потеряет любую параллельность экранным ортогоналям, и выводить ее с текстурированной будет трудно. Mode7 прийдется резать вобще на кубики вместо полосок и это будет еще корявее…
Описанное мной в статье НЕ для перспективного текстурирования. А для разного рода текстурированных Изометрий привлекательно. Про полноценность 3D топить не надо. Изометрия это пространство 3х измерений. Просто с отсутствием искажений размеров по Z.
Более того она вполне законно существует в реальности — у Снайпера на дальние дистанции практически исчезает перспективный эффект. У фото съемок со спутника тоже практическая изометрия.
В принципе если вам очень нужно искажение размеров по Z используйте паралакс, на слоях рисуемой в глубину top-down проекции. Но у нее фиксированый 90гр поворот вертикальной оси. Это то как рисовалась «формулы 1». Но это единственная проекция которую можно вывести с текстурированием и перспективой. Важно указать, что «перспектива» здесь будет только относительно размеров обьектов, но не их граней относительно друг друга. Потому в такой проекции нет особого смысла рисовать грани отдельными вызовами. С трапециями можно было бы пробовать cavalier проекции. слегка в нахлест кубами класть. И скалировать слои в глубину. Если что глядите тут
Для 8 фиксированных углов изометрии целесообразно использовать 8 фиксированных спрайтов на каждую грань. Это увеличит расход ОЗУ в 8 раз.
Спрайт можно назвать частным случаем текстуры, когда пиксели копирются на экран один к одному. Если вы собираетесь мапировать текстуру более сложным способом, то в пределах одной строки растра может происходить происходить как масштабирование строки текселей, так и непоследовательное чтение из памяти (UV координаты). И то и другое наводит на мысли о фильтрации: NearestNeigbor, Bilinear и прочие.
Спрайт можно назвать частным случаем текстуры, когда пиксели копирются на экран один к одному. Если вы собираетесь мапировать текстуру более сложным способом, то в пределах одной строки растра может происходить происходить как масштабирование строки текселей, так и непоследовательное чтение из памяти (UV координаты). И то и другое наводит на мысли о фильтрации: NearestNeigbor, Bilinear и прочие.
— для поверхностей я на них обходился одним! — Для персонажей двумя.
поверхности задеплоены — codepen.io/impfromliga/full/pKgwjd
— рисовать на процессоре что то перспективное с текстурированием, РЕЗКО увеличивает сложность алгоритма и его ресурсозатратность, потому почти наверняка НЕ рационально.
Все это надо делать уже на нормальном GPU.
Самый распространенный алгоритм применявшийся для перспективного 3D рендеринга известный мне это т.н. scanline. На нем был Дюк. И это просто верх. Особо много на нем не вытащить даже на нынешних CPU. Есть еще отдельный вид воксельный рейкастинг, самое показательное развитие этого метода — Ace of Spades но он уже без текстур
поверхности задеплоены — codepen.io/impfromliga/full/pKgwjd
— рисовать на процессоре что то перспективное с текстурированием, РЕЗКО увеличивает сложность алгоритма и его ресурсозатратность, потому почти наверняка НЕ рационально.
Все это надо делать уже на нормальном GPU.
Самый распространенный алгоритм применявшийся для перспективного 3D рендеринга известный мне это т.н. scanline. На нем был Дюк. И это просто верх. Особо много на нем не вытащить даже на нынешних CPU. Есть еще отдельный вид воксельный рейкастинг, самое показательное развитие этого метода — Ace of Spades но он уже без текстур
Вижу несколько варианта спрайтов для стенок. Либо мапирование текстуры по разным осям UV, и в разных направлениях. Кстати, последовательное чтение из памяти на современном железе оптимизировано, происходит гораздо быстрее непоследовательного.
это все спички по сравнению даже с webGL. У CPU есть сильные стороны ввиду возможности реализовывать последовательные прогрессивные алгоритмы, сканлайны, скользяцие окна, но это все очень потно и кастомно, я уже отыгрался. Сейчас относительно 3D интересует как раз таки webGL. Он кстати тоже довольно ограниченный. Но в какой то мере становиться вездесущим графическим окружением. Вместо исчезающих ретро консолей. По части ретро консолей, интересно смотреть в сторону новых разработок. Сказать по честному сейчас на каких-нибудь STM32F7 можно ТАКОЕ сделать, в сравнении с чипами древности… Я жду что явление вируальных консолей кто нибудь разовьет в сторону аля-ардуино (но лучше не оно а STM32 / ESP32)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Если б тайлы были чуть больше тайлами. Выход за границы наивного представления