Крайне прошу простить вашего покорного слугу за эдакую задержку между постами, но сейчас всё мое время съедает адаптация quad под С++, точнее переделка движка. Движок уже ожил и завелся в первом приближении. Теперь базовый функционал и фабрики все в IQuadDevice, а Render отвечает только за отрисовку. Здорово, правда? Также почти уже не осталось перегруженных методов. Оставайтесь с нами, в 0.4 будет много изменений, старый код работать без правки не будет, но будет и много новых вкусняшек. Как только чутка времени появится - тут же отпишусь!

Доброй ночи, уважаемые читатели. Соскучились? :) Оставайтесь с нами и в ближайшие минуты вы узнаете все вести с полей! Сегодняшний выпуск необычный. В нем обо всем и понемногу. Поехали!

QuadShade разрабатывается и выглядит все лучше и лучше. Сейчас строю настройки. Выглядит это как-то так на данный момент. Естественно, всё может поменяться еще.

QuadEngine стремится к версии 0.4 и обзаведется заголовочными файлами под С++. Надо отметить, что поддержка С++ выльется в некоторое кол-во рушащих существующий код изменений. В первую очередь это коснется создания объектов и перегруженных функций, от которых, увы, пришлось отказаться.

Вдохновление льется рекой, ведь вышел новый альбом Poets Of the Fall: Temple of thought. Альбом, к слову сказать, очень мне понравился, хотя, и опять отличается от предыдущих довольно сильно. 24го они в Москве, послушаем вживую, что там творится.

Наконец-то анонсировали и открыли предпродажу на долгожданную Diablo3, чему ваш покорный слуга безумно рад. Таким играм быть!

www.pascalgamedevelopment.com решил вдруг написать о Quad-engine. Ничего нового вы там не найдете, ну а мне опять таки приятно.

Идет полным ходом переработка QuadShade, так как утилита в текущем виде довольно убога. Первая версия была написана с использованием собственного редактора текста. Тут надо признаться, что начинал я его писать очень давно и амбиций тогда было очень много, не в пример знаниям и опыту. В результате чего редактор получился кастрированным даже по отношению к обычному TMemo, однако с раскраской синтаксиса. Поняв, что с этим работать тяжко, он был сменен на SynEdit, однако и он преподнес кучу сюрпризов. Начиная с того, что не работает делит, заканчивая тем, что и раскраску-то не совсем можно настроить как хочется. В итоге и он меня разочаровал.
Несколько дней назад я прошерстил интернет в поисках достойной замены, но для делфи так и не нашел подходящего компонента (что странно, согласитесь, для делфи компонент-то хватает). Результатом всех поисков и некоторого кол-ва раздумий стало решение написать свой компонент. Изобрести очередной велосипед. Чем я благополучно и занялся.
Надо отметить, что код в шейдерах, как правило, довольно маленький, поэтому такие особенности как схлопывающиеся куски кода я даже и не ставил себе в задачи. Прошло три, может четыре дня разработки, сейчас это выглядит так:

На скриншоте можно лицезреть следующие особенности:

• Нумерация строк
• Подсветка измененных строк (желтая) и сохраненных (зеленая)
• Свои полосы прокрутки (увеличиваются в толщине, когда к ним подводишь курсор)
• Изменяемый размер шрифта (на скришоте 11й)
• Подсветка переменных с одинаковыми названиями
• Подсветка текущей строки
• Отчерк на 80символах
• Автоподсказка по набираемым функциям и зарезервированным словам
• Опциональная тень под шрифтом (на скриншоте включена)

А также то, что невозможно с него увидеть:

• Корректная обработка табуляций (изменяемый размер)
• Копирование, вырезание, вставка текста
• Адекватная реакция на page up/down, home, end
• Выделение текста как мышкой, так и с клавиатуры
• Поддержка колесика мышки

Разумеется не могу не отметить, что писал его с нуля и за основу взял TCustomControl. 

Доброго дня всем!
Сегодня я, как и обещал, расскажу о такой вещи как DuDv map. Немного погуглив я понял, что информации на этот счет почти нет, хотя сами по себе эти карты используются повсеместно. В чём же проблема?
Да, собственно, ни в чем. Единственной проблемой этих карт является изготовление. И эти карты не получили такого распостранения как карты нормалей или карты высот. Однако, получить их можно из карты нормалей, которую в свою очередь можно получить из карты высот. И, разумеется, её можно нарисовать самому. Как мы и поступили в игре blast-off:

 Что это такое и с чем это едят? Карта  смещений (dudv это сокращение от deltaU deltaV, тоесть дельта текстурных координат) представляет собой правила, по которым пиксель будет смещен. Каждой точке на финальном изображении будет сопоставлено значение из карты смещений, тем самым мы будем знать откуда брать результирующий цвет для этой точки.

Например оливковый цвет (0.5 красного и 0.5 зеленого) говорит нам о том, что точка берется ровно из того же места, где она и есть (без смещений координат). 

Вообще суть и вычисления крайне похожи на карту нормалей. В зеленой составляющей лежит значение от 0 до 1.0, 0.5 при этом является отсуствием искажений, 0.0 - полное искажение в минус по Y оси, 1.0, соотвественно, полное искажение в плюс. Насколько оно большое, разумеется, Решаете вы. В красной составляющей цвета лежит абсолютно тоже самое, только для горизонтальной составляющей. 

Таким образом R искажет U, а G искажет V.

На приведенной сверху текстуре карта строилась так, чтобы все пиксели внутри видимого шарика (его видно на текстуре как разноцветное пятно) брались из окружающей шарик текстуры. Этим мы добились как бы отражений на шарике. Хотя, в большинстве случаев эти карты используются совсем для иной цели, а именно для создания карт преломлений, скажем от стекла, воды, искажений пространства от взрывов.

Счастливый день для всех нас, я наконец-то обновил версию до 0.3.0, и выложил её в свободный доступ на сайт. Теперь, собственно, могут качать и пользоваться не только избранные, а все желающие.
Гладкого кода!

 

            - С пробуждением, Энис Райт. Личный номер: 247538-62. – Приятный женский голос искусственного интеллекта корабля поприветствовал меня, а также еще четырёх членов экипажа. Камеры открылись и мы медленно, как бы лениво, вышагнули из них. Отсек, а точнее даже модуль корабля, где располагались криокамеры, был поистине огромным. Ряды камер, в каждой полулежал-полустоял человек. Через каждые пять камер находилась переборка, и свет был включён только в нашем отсеке. В остальных свет был настолько незначительным, что казалось будто камер бесконечное множество, так как дальние из них попросту терялись во мраке.

            Была наша очередь просыпаться. В криосне нельзя находиться слишком долго, с каждым днём шанс летального исхода увеличиваестся, поэтому ИИ будит по 5 человек каждые три дня, так, чтобы все 600 членов экипажа просыпались 1 раз в год. Мне предстояло еще порядка семнадцати пробуждений, тогда как шесть были уже позади. Основным, что волновало подавляющее большинство, были новости. Спин-передатчики работали на колоссальные расстояния, поэтому даже находясь между двумя галактиками приём был уверенный. Учёные из центра межгалактического полёта позаботились о том, чтобы с нами не терять связь, так что новости мы узнавали практически моментально. Единственное, что мешало узнавать их быстро – сон. Так что, некоторые узнавали их с задержкой до тридцати четырех лет реального (или одного года корабельного) времени.

(C) Void story, 2012

Motion blur, или смазывание при движении. Получается автоматом в кино из-за большой выдержки плёнки, отлично имитируется пакетами трехмерной графики и обработки видео, но так сложна и заковыриста для реализации в играх.

При разработке игры blast-off, а точнее её прототипа, возникла необходимость использовать этот эффект. Да, я сказал "необходимость". Необходимость потому, что при больших скоростях задний план начинал настолько жутко мерцать (от быстрого движения), что глаза моментально уставали и игру хотелось закрыть.

Перед тем, как прийти к финальному на тот момент варианту было испробовано несколько вариантов, как теоретически, так и практически. О них дальше:

Давайте рассмотрим всё на примерах. Назовите мне игры с честным motion blur. Ну же, смелее. Дело в том, что их нет. Ну или почти нет. В любом случае честный motion blur будет слишком труднозатратен или будет нечестным. В чём же проблемы и почему его не делают честным? Каковы принципы смазывания.

Первое, что приходит в голову, это складывать несколько кадров воедино, рендеря картинку со смещением. Первая идея, зачастую, еще проще. Брать последние 3-5 кадров и с частичной прозрачностью накладывать друг на друга. Подход даёт самый честный motion blur, однако имеет огромнейший недостаток. Скорость.
Взять предыдущие кадры мы не можем, любой кто пробовал, поймёт почему подход провален: те кадры уже были, мы получим не смазывание при движении, а шлейф, к тому же создающий ощущение заторможенности происходящего. А это идет в разрез с тем, что хотим получить мы, а именно смазывание при движении. Результат будет выглядеть как-то так:

Печальное зрелище. При 60 кадрах мы получаем шлейф в почти 1\10 секунды. При некоторой доработке метода, мы можем решить, что можно сразу отрендерить эти 3-5 кадра, с учетом движения объектов между кадрами и получить честное смазывание и отсутствие шлейфа. И это будет правда. Но результатом такой реализации на практике станет падение кадросекунд в соответствующие 3-5 раз. В Blast-off мы не могли так жертвовать скоростью, поскольку нетбуки не давали при нашем уровне графики больше 50-60кадров, а слабенькие ноутбуки более 170 кадров в секунду. Полагаться на мощность компьютеров, выдающих более 1000-1500 кадров в секунду не хотелось, так как играть в подобные игры люди любят и, украдкой, в рабочее время на работе. На рабочих лошадках при этом ничего лучше интегрированного виде от Intel не стоит.

Мы пошли по пути наименьшего сопротивления. Решив, что самым смазываемым эффектом является, фактически, только фон, было решено смазать для начала только фон. Сделать это совсем несложно постпроцессом. Выглядит код шейдера так:

  float4 Output; 
  for (int i = 1; i < NumSamples; ++i)
  {
    float4 currentColor = tex2D(DiffuseMap, texcoord);
    texcoord -= Vec;
    Output += currentColor;
  }
  Return Output / NumSamples;

Где Vec - вектор движения фона, а NumSamples это количество псевдокадров для смазывания (в нашем случае 13. Эффект получается совсем не прожорливый и выглядит так:

Проблемой такого подхода являются динамические объекты, двигающиеся отдельно от фона. Если их поместить в тот же конвеер, что и фон, они смажутся, если же рисовать поверх, то будут слишком четкими. Тут тоже можно считерить. Отрендерив всю сцену дважы в два разных буфера, в рендертаргет как есть и во второй рендертаргет только альфой, закодировав цветом смещение. В красный смещение по Х, в зеленый по У (это называется DuDv map и о ней я расскажу в дальнейших постах). Результатом (для двигающихся объектов) будет такая картинка:

Круто? а не тут-то было. При такой скорости движения шарик должен был бы смазаться так:

Шарик А с предыдущего кадра. Контур у него четкий. А вот шарик В это то, что должно было получиться. Более длинное изображение, прозрачное по краям, без четких контуров.

Выводом из всех проведенных экспериментов можно сделать следующее. Постпроцессинг не может дать качественного и правильного motion blur. В то же время честные методы не могут дать приличной скорости работы. Возможно, что комбинирование этих двух методов поможет. Тоесть 2 картинки - прошлый и текущий кадр (практически не съест скорости в меру того, что предыдущий кадр всеравно уже отрендерен), сгенерировать DuDv карту смещений для объектов и уже на основе этих трех исходных изображений генерировать более честный эффект смазывания.

Тут я осмелюсь разочаровать читателя, так как ни скриншотов, ни кода для данной реализации пока еще у меня нет, но как только я его опробую, обязательно отпишусь в блоге.