Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 39
Просто и со вкусом, напомнило псевдо-3д планеты из Космических Рейнджеров. Укажите пожалуйста источник музыки из ролика и шрифт!
Шрифт моего авторства Quad regular. Музыка — один из треков к нашей игре blastoff авторства Егора Федотова www.egorfedotov.ru
У многих тут же возникнет мысль «ну нифига себе очевидно! Очевидно — это делать 3D для 3D планеты, разве нет?». Нет. Потому что игра у нас исключительно двумерная.
Что значит «исключительно двумерная»? Вы не используете ни OpenGL, ни Direct3D для рисования?
Значит что всё, что у нас рисуется использует только 2д вывод графики. Direct3D, но в случае с этой планетой можете считать что это всего лишь 2 треугольника.
У нас нет 3D моделей. Нет и не будет.
У нас нет 3D моделей. Нет и не будет.
А почему не взять тогда что-нибудь вроде SDL?
Опс, с SDL отбой, это, оказывается, надстройка над OpenGL/Direct3D.
Но вопрос остаётся, почему не взять библиотеку для двухмерной графики?
Но вопрос остаётся, почему не взять библиотеку для двухмерной графики?
Сейчас все библиотеки для двухмерной графики — это надстройка над OpenGL и/или Direct3D. Потому что это основные API, с которыми работает железо.
Давайте уточним. Что есть библиотека для двумерной графики? OpenGL это библиотка для двумерной графики?
В моем понимании я использую свою библиотеку для двумерной графики. Надстройку на Direct3D 9c quad-engine.com/
В моем понимании я использую свою библиотеку для двумерной графики. Надстройку на Direct3D 9c quad-engine.com/
Минимально потому что его под Delphi нет и потому что это ничего абсолютно не даст. Какая разница чья надстройка над графическим API?
От того, что вы свои треугольники не хотите называть 3D-моделями, они ими быть не перестают.
В любом случае, как мне кажется, можно обойтись без карты смещения и считать координаты налету, заодно и точность повысится. Карту-то вы поди не руками рисовали?
В любом случае, как мне кажется, можно обойтись без карты смещения и считать координаты налету, заодно и точность повысится. Карту-то вы поди не руками рисовали?
Для сферы и правда вынести аналитически dU, dV можно, но если захочется рисовать нечто сложнее, чем сферу, с каким-нибудь искажением, то аналитический вывод уже малоприменим.
Карта универсальное решение, которое позволит с формой или искажениями играться, к тому же шустро работает, как я и сказал в статье. Карта рисуется в граф редакторе легко и быстро свой градиентов и сферизацией результата.
Хе-хе, знакомые беседы. Я уже публиковал реализацию аналогичного спецэффекта, правда там я таки решил проблему с недостатком градаций, используя 16-битные координаты. ;)
Да, ваша статья мне тогда очень понравилась. Все по порядку и кодом не пожадничали, в отличие от автора данной статьи.
Напишите какого кода Вам не хватает, исправим.
Да код есть, не сразу увидела, прошу прощения!
Если нужен код самого бинарника, то я могу выложить. Проблема в том, что хабрасторейдж не дает класть архивы, а файлообменник привлекать не хочется. Так что если нужно, пришлите в личку почту, я скину исходники проекта.
Спасибо код уже у меня есть, правда только для IOS. Сделан на основе 2-х треугольников по аналогией с примером выше. В любом случае, интересно кто, что и как делает.
А насколько накладно рассчитывать карту смещения на-лету, в шейдере, чтобы избавится от ошибки округления?
PS: забавлялся подобным эффектом на первых курсах института, используя MMX команды процессора.
PS: забавлялся подобным эффектом на первых курсах института, используя MMX команды процессора.
А смысл её делать на лету? Если Вы знаете как надо исказить всё, то и искажать тогда уж сразу проще, зачем тогда в принципе карта. Но тут дело в другом. А если на поверхности планеты появится кратер? Или это будет звезда смерти? :) Искажения как считать будете? С картами всё можно адаптировать, с формулами уже все становится невероятно сложно.
Изобретать велосипед весело и интересно, но всегда надо знать где стоит остановится, наверное. Иначе пойдет велосипед ради велосипеда, а у меня эффект не ради эффекта, а для игры делался.
В моем случае затраты по времени очень хорошо сопоставимы с результатом. Да есть ошибки округления, но когда на экране крутится что-то движащееся и не во весь экран, Вы их практически не видите, а значит ими можно пренебречь.
Изобретать велосипед весело и интересно, но всегда надо знать где стоит остановится, наверное. Иначе пойдет велосипед ради велосипеда, а у меня эффект не ради эффекта, а для игры делался.
В моем случае затраты по времени очень хорошо сопоставимы с результатом. Да есть ошибки округления, но когда на экране крутится что-то движащееся и не во весь экран, Вы их практически не видите, а значит ими можно пренебречь.
А если на поверхности планеты появится кратер? Или это будет звезда смерти?
В этом случае ваш подход тоже работать перестанет, иначе вам придётся для каждой фазы вращения делать свою карту смещения.
И вообще, я просто поинтересовался, какая разница в производительности при расчёте сферической карты на лету и загрузке из текстуры (если вы их сравнивали, конечно). Например, для мобильных приложений каждый килобайт видеопамяти может быть на счету, тогда может быть на-лету считать будет выгоднее.
Согласен, тогда надо будет делать карту смещений так как сейчас делается сама планета.
На РС нет проблемы дефицита видеопамяти. На новых картах уже по четыре или даже шесть гигабайт памяти. Поэтому особо о расходе памяти и не думается, пока расход измеряется десятками мегабайт.
А вот завывания видеокарты при усиленных вычислениях — ощутимы бывают.
А сколько видеопамяти на современных мобильных устройствах?
На РС нет проблемы дефицита видеопамяти. На новых картах уже по четыре или даже шесть гигабайт памяти. Поэтому особо о расходе памяти и не думается, пока расход измеряется десятками мегабайт.
А вот завывания видеокарты при усиленных вычислениях — ощутимы бывают.
А сколько видеопамяти на современных мобильных устройствах?
Спасибо за статью!
Подскажите, а насколько подход 1-2-несколько шейдеров для ОДНОГО ТИПА объектов оправдан, по вашему мнению?
Да это дает нам возможность делать крутые визуальные штуки только за счет написания кода, без художников (ура!). Но ведь в дополнение мы получаем необходимость поддерживать\оптимизировать прорву шейдерного кода, который с одной стороны индивидуален для каждого типа объектов (для планет — один набор шейдеров, для кораблей другой, для космических мух — третий), с другой стороны многие куски кода будут повторяться (к прим. расчет освещенности от звезд). Также, переключение между шейдерами при отрисовке не очень дешевая операция, поэтому есть риски и по производительности.
Подскажите, а насколько подход 1-2-несколько шейдеров для ОДНОГО ТИПА объектов оправдан, по вашему мнению?
Да это дает нам возможность делать крутые визуальные штуки только за счет написания кода, без художников (ура!). Но ведь в дополнение мы получаем необходимость поддерживать\оптимизировать прорву шейдерного кода, который с одной стороны индивидуален для каждого типа объектов (для планет — один набор шейдеров, для кораблей другой, для космических мух — третий), с другой стороны многие куски кода будут повторяться (к прим. расчет освещенности от звезд). Также, переключение между шейдерами при отрисовке не очень дешевая операция, поэтому есть риски и по производительности.
Всегда пожалуйста! *улыбнулся*
Не совсем понял вопроса, но попробую ответить. Надеюсь верно интерпретировал.
Я не делаю четкой типизации мол вот ты будешь с этим шейдером, а ты вот тут рядом стоишь такой похожий весь, но чуток другой — ты будешь с другим шейдером. В этом случае все разруливается параметрами, которые мы передаем в шейдер и обрабатываем уже там, в шейдере.
Если речь идет о разных эффектах, то да, там без разных шейдеров не обойтись.
Тонн кода нет, есть десяток-два шейдеров, этого достаточно чтобы покрыть почти всё, что нужно в 2д игре, как показывает практика. Программного кода гораздо больше, чем шейдерного.
Не совсем понял вопроса, но попробую ответить. Надеюсь верно интерпретировал.
Я не делаю четкой типизации мол вот ты будешь с этим шейдером, а ты вот тут рядом стоишь такой похожий весь, но чуток другой — ты будешь с другим шейдером. В этом случае все разруливается параметрами, которые мы передаем в шейдер и обрабатываем уже там, в шейдере.
Если речь идет о разных эффектах, то да, там без разных шейдеров не обойтись.
Тонн кода нет, есть десяток-два шейдеров, этого достаточно чтобы покрыть почти всё, что нужно в 2д игре, как показывает практика. Программного кода гораздо больше, чем шейдерного.
да, вы правильно поняли. Проблема в том что мы либо пишем один универсальный «шейдер для всего», но тогда в нашем случае текстура dUdV не будет делать ничего в 90% случаев (для объектов отличных от планет), либо пишем отдельный «шейдер для планет», который рисуем только планеты
Как раз обратная ситуация. dUdV шейдер мы можем использовать еще много где. Например горячий воздух, линзы, и кто знает что еще. А вот если мы закодируем трансформацию в сферу внутри шейдера, то его мы только для создания шариков и будем использовать. dUdV является тут компромиссом. И достаточно универсально и достаточно качественно для данной задачи. В нашем случае планеты врядли будут по 512 пикселей размером вертеться в кадре.
Шейдер это хорошо, но технически это довольно просто повторить и просто 2D графикой, как и было в КР.
habrahabr.ru/post/180353/#comment_6261603
Конечно, годы идут, руки у людей все прямее и мой старый пример уже не смотрится без облаков, свечения и пр., но все же задумайтесь, вы пишете микропрограмму для 3D ускорителя, чтобы в 2D имитировать 3D!
habrahabr.ru/post/180353/#comment_6261603
Конечно, годы идут, руки у людей все прямее и мой старый пример уже не смотрится без облаков, свечения и пр., но все же задумайтесь, вы пишете микропрограмму для 3D ускорителя, чтобы в 2D имитировать 3D!
А в чем проблема, если эта микропрограмма выполняется в GPU быстрее чем в CPU? Разгрузили CPU, получили больше возможностей для AI и прочих полезностей.
Именно проблем в нестандартных подходах я не вижу вообще, да и сам этим грешу. Но в этом конкретном случае подозреваю, что «чесное» 3D было для планет как минимум быстрее и читабельнее.
Ни разу :)
Для честного 3D надо будет доделывать движок, чтобы он поддерживал это самое честное 3д. Затенение по фонгу делать, и кучу всего прочего. А для 2д и шейдеров уже все есть. Так что все просто и ооочень читаемо в коде.
Для честного 3D надо будет доделывать движок, чтобы он поддерживал это самое честное 3д. Затенение по фонгу делать, и кучу всего прочего. А для 2д и шейдеров уже все есть. Так что все просто и ооочень читаемо в коде.
А что с игрой? Она в процессе или уже опубликована?
Зацепило. Пойду Космических Рейнджеров скачаю. Nostalgie…
Выглядит классно. Тоже напомнило Космических Рейнджеров.
Очень хочу научится работать с шейдерами, но к сожалению имею опыт только с#/java и код из статьи мне не совсем понятен, может кто подскажет уроки по данной теме?
Очень хочу научится работать с шейдерами, но к сожалению имею опыт только с#/java и код из статьи мне не совсем понятен, может кто подскажет уроки по данной теме?
Всех кого зацепило и кто не знает о ресурсе shadertoy.com — советую заценить, там целые raytracer'ы, pathtracer'ы и ray-marcher'ы пишут в фрагментном (пиксельном) шейдере и выставляют на всеобщий показ.
P.S. Осторожно, нужен включенный WebGL, может тормозить.
P.S. Осторожно, нужен включенный WebGL, может тормозить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Объемные планеты в 2D через шейдер