Joe's CG

Books

2012-02-09T13:40:00.001+02:00

Купил пару новых книг:

Думаю, в описании они не нуждаются.

Visual Studio Vista

2012-02-05T01:42:00.000+02:00

10 и 11 студии ужасны. Точка.

The State Of Anti-Aliasing

2012-02-01T14:25:00.003+02:00

The Radeon HD 7970 Reprise: PCIe Bandwidth, Overclocking, & The State Of Anti-Aliasing

The End of USSR

2012-01-28T21:11:00.002+02:00

iMac Greyish Smudge

2012-01-27T18:12:00.000+02:00

Мой iMac 27' уже где-то полтора года в эксплуатации. А сегодня я заметил на его матрице, в правом верхнем углу, странные серые разводы. Я подумал что на фронтальном стекле скопились пыль и жир и протёр его влажной салфеткой. Но оказалось, что это повреждения IPS матрицы, а не грязь на стекле.

Я прошёл по офису и выяснил, что подобные пятна появились и на других iMac-ах, в основном в правом верхнем углу. Ну и наконец Google подсказал, что это распространённый дефект этих моноблоков: пользователи жалуются.

Думаю, через два-три года там образуется порядочное серое пятно :(

DirectGL progress

2012-01-23T23:52:00.000+02:00

Завершил работу над функциями по загрузке 2D-текстур. Решено реализовать только загрузку BMP, TGA и DDS форматов (без поддержки расширений DX10, т. к. они всё равно не применимы в DX9-рендере). Я написал простой unit test который грузит DDS текстуры разных форматов (как сжатые, так и различных форматов вида RGB8, R5G6B5 и т. д.), а фактически текстуры разделены на два лагеря - несжатые RGBA8 и сжатые DXT, всё остальное практически никогда не используется для хранения в видеопамяти. Для полноты необходимо реализовать ещё загрузку cubemap текстуры из DDS, но это если руки дойдут.

Решено также постепенно подключать к проекту различные unit test-ы, как это практикуется в Wine, чтобы тестировать враппер на соответствие реальному поведению рантайма Direct3D. Из того же Wine эти тесты и думаю заимствовать (как-никак open source).

Также заставил работать через враппер два сэмпла из DirectX 9 SDK - EmptyProject и SimpleSample. Как и другие примеры они интенсивно используют DXUT, так что это хороший тест "на прочность". Но тут обнаружился интересный баг - шрифт рисуется в бэк-буфер перевернутым по оси ординат:

Тут нужно отметить, что при портировании Direct3D кода на OpenGL есть один неприятный момент: начало системы текстурных координат Direct3D находится в левом верхнем углу, тогда как в OpenGL - в левом нижнем. Для обычных текстур это не имеет значения, т. к. похоже драйвер правильно укладывает их в память (или железо вычисляет адрес в памяти) в зависимости от используемого API. Но с render target текстурами при их семплировании в шейдере приходится инвертировать текстурные координаты по оси Y. Это решение имеет по крайней мере два недостатка:

1) Необходимо пересмотреть код всех шейдеров и в тех местах, где семплируется render target, поправить текстурные координаты.

2) Возможны случаи, когда в шейдер на один и тот же текстурный слот попеременно передаётся обычная текстура и render target. Тут приходится заводить дополнительный булевый флажок либо создавать отдельный шейдер для каждого случая. При использовании флажка, если он по какой-то причине не отражает реальное положение дел (упустили где-то, энджин-то большой), изображение нарисуется перевёрнутым.

Оба эти решения являются неприемлемыми.

Как компромисс, мною решено менять матрицу проекции так, чтобы растеризуемая геометрия рисовалась в render target с инвертированием по оси ординат. Позже, при семплировании этого render target в шейдере, произойдёт восстановление правильного изображения. Обычно в коде достаточно мало мест, где устанавливается матрица проекции для вершинного шейдера (или TnL), или мы можем знать номер регистра, по которому лежит первая строка (столбец) матрицы, поэтому внести поправки в этом случае легче, чем в остальных.

Если же использовать этот метод, то любые другие способы записи в render target (например, отображение шрифта силами GDI), не проходят преобразование матрицей, и попадают в render target с исходными координатами - соответственно при семплировании в шейдере изображение перевернётся. Впрочем, это минорный недостаток, в реальных играх вся графика полигональна.

Общий вид GDI текста с инвертированием текстурных координат:

Как видно, теперь перевернулись элементы интерфейса, нарисованные с помощью полигонов. Надеюсь, дилемма понятна.

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

I Love MS

2012-01-19T15:31:00.002+02:00

Фобос-Грунт

2012-01-16T00:46:00.003+02:00

Сабж наконец-то упал в океан.
Нанотехнологии блять!

30

2012-01-12T12:57:00.000+02:00

Вот так вот живёшь, крутишься, чего-то добиваешься...
А тут тебе, хлоп - тридцать лет стукнуло :)

Stereo Texture

2012-01-06T15:00:00.000+02:00

Пока мы все вынуждены ждать Direct3D 11.1, где появится нэйтивная поддержка стереоскопии, под DirectX 9 для всяких этих ваших ассассинов кридов приходится использовать различные хаки, чтобы улучшить поддержку стерео.

Механизм, через который работает 3D Vision на картах NVidia, довольно прост - драйвер добавляет footer в каждый вершинный шейдер таким образом, чтобы позиция вершины в clip space различалась для правого и левого кадра (см. NVIDIA 3D Vision Automatic Best Practices Guide). Таким образом стерео автоматически работает в большинстве трёхмерных игр и даже тех, которые изначально под него не разрабатывались.

Проблемы начинаются в случаях, если при рендеринге использовались какие-то нечестные техники или в случае различных deferred подходов - картинка обычно выглядит неестественно, если не сказать хуже. 3D Vision работает на уровне геометрического пайплайна, во всех остальных случаях нужно что-то делать руками самостоятельно. Вот недавно по работе мне было поручено исправить некоторые огрехи нашего движка при работе в стерео-режиме. Как выяснилось, одна из техник использовала механизм отложенного рендеринга партиклов, при котором цвет и дополнительная информация сначала рисуются в промежуточный render target, а потом изображение из него "вклеивается" в основной кадр. Понятно, что 3D Vision проплывает в этом случае по левому борту, и необходимы поправки уже в пиксельном шейдере. Но вот загвоздка - стандартными средствами Direct3D выяснить какой из кадров - правый или левый, рисуется в данный момент - в шейдере невозможно, а без возможности их различать нет и возможности что-либо изменить.

Начав искать в Сети методы решения подобных проблем, я обнаружил, что NVidia предоставляет пример StereoIssues в NVIDIA Graphics SDK 11, в котором имеется код по созданию специальной "стереотекстуры" (файл nvstereo.h). Стереотекстура позволяет семплировать в шейдере данные, которые будут различаться для левого и правого кадра, так что, например, можно вычислить смещение для каждого кадра по формуле:

pos.x += separation * (pos.w - convergence)

Это очередной хак на уровне D3D9/10 API, и для его включения необходимо разместить fourcc 'NV3D' в последней строке staging текстуры формата RGBA32F, данные из которой впоследствии необходимо скопировать в обычную текстуру посредством UpdateSurface()/CopySubresourceRegion(). При копировании драйвер разместит данные для левого кадра в целевой текстуре, а для правого (как я понимаю) создаст shadow copy и разместит в ней данные для правого кадра, взяв их по определённому адресу (см. раздел 3D Video в GDC09 3DVision The In and Out). Если всё сделать в том порядке, который предлагается в примере, то шейдер действительно будет семплировать различные данные по одним и тем же текстурным координатам. Ну а дальше уже дело техники...

Одним из подводных камней, о который я споткнулся, является то, что недостаточно просто при старте скопировать данные в стереотекстуру и в дальнейшем пользоваться ею. Всё дело в том, что 3D Vision не включается с первым же кадром: драйвер сначала собирает некоторую информацию о первых кадрах, и только потом включается стереорежим. После его включения и нужно создавать стереотекстуру, а лучше всего проверять переключение режимов функцией NvAPI_Stereo_IsActivated() из NvAPI, и обновлять её после изменения результата. А в примере StereoIssues идут ещё дальше: т. к. пользователь может динамически изменять такие параметры 3D Vision как EyeSeparation и Convergence, то необходимо отслеживать изменения этих параметров и своевременно обновлять данные в стереотекстуре.

Игры

2012-01-05T01:12:00.001+02:00

Я работаю в Ubisoft не потому, что мне нравится играть в игры, а просто потому, что мне нравится их программировать :)

Intel Celeron M

2012-01-05T01:08:00.002+02:00

Из-за того, что в моём ноуте стоит сабжевый процессор, IE 8 на нём безбожно тормозит и сёрфинг по Сети лишь раздражает. Ситуация с Opera лишь чуть лучше. По законам копроэкономики я как потреблядь должен был побежать в магазин и прикупить что-нить с намного более мощным CPU (желательно с 4-мя ядрами!). Но вот незадача, Google Chrome на текущей конфигурации летает.

Не пишите говнософт.

ТВ

2012-01-02T17:26:00.002+02:00

По случаю Нового года довелось посмотреть телевизор.

Я смотрю, его прямо оккупировали, каждый год одни и те же рожи! Все сытые и довольные, с улыбками поздравляют нас и как всегда желают быть счастливыми! Сколько, интересно, им это стоит и кому на это жаловаться?

P.S. Да ещё этот ваш карлик, карманный президент, выскочит в перерыве на экран и в двух словах расскажет, как у вас там всё пиздато, и что Россия катится полным ходом в светлое будущее.

Ennio Morricone

2011-12-26T13:59:00.001+02:00

Недавно (20 числа) в Киеве был концерт Эннио Морриконе. Сегодня открыл для себя что этот саундтрек написал именно он:

The Demise of Barbara and the Return of Joe

Под него Билл делал свои последние шаги, если кто помнит. Даже если бы и мне довелось умирать, то да - только под этот бриллиант...

Эксимер

2011-12-24T19:03:00.002+02:00

Вчера ходил в киевский "Эксимер", делал диагностику зрения.
Капали глаза, мучили несколькими аппаратами.

Зав. отделением сказал что из-за анатомии моего глаза роговица слишком тонкая для LASIK и что годится только LASEK. Период восстановления - до двух недель. К тому же у меня какие-то повреждения в глазу и надо делать укрепление сетчатки лазером перед основной операцией.

Я вычитал что в случае с LASEK после операции два дня болят глаза (из-за повреждения нервных окончаний) и предсказуемость операции ниже, чем при LASIK, так что как-то не хочется её делать. Думаю в следующем году сходить ещё в "Новий Зiр" - пишут у них есть метод Super LASIK Thin Flap, пока единственный в Украине. Думаю стоит попробовать, хотя цены наверное заоблачные. Впрочем, собственные глаза - это явно не тот орган, на котором надо экономить.

Кстати на Ютюбе есть видео с подобной процедурой.

DirectGL progress

2011-12-24T16:50:00.000+02:00

По работе вытащил уже запылившийся DirectGL, и увидел что многое надо переделать. В итоге меня занесло и я сел дописывать функционал D3DX.

Во-первых, я серьёзно взялся за загрузку текстур через D3DX API. Тут я многое позаимствовал из кодов Wine, а именно иерархию вызовов при загрузке текстуры, различные проверки, способ мэппинга файла в память и т. д. Пока что грузятся палитровые и true-color BMP файлы, TGA с RLE-компрессией и без, работает распознавание DDS файлов. Последний формат довольно сложен (поверхности, cubemap-ы, объёмные текстуры, куча форматов, расширения DX10+), так что надо выкроить время на его поддержку.

Во-вторых, я реализовал загрузку простых файлов формата .x, но быстрым путём: создаются интерфейсы Direct3D для временного окна и грузится реальный меш, потом данные копируются в OpenGL реализацию интерфейса ID3DXMesh :) Конечно этот способ непортируем, зато позволяет проверить насколько работоспособен код рисования.

Результат:

Slim LG DM92

2011-12-23T11:32:00.000+02:00

LG teases DM92, DM82, and DM52 IPS monitors

Хотет такой!

Radeon 7970

2011-12-22T17:19:00.001+02:00

AMD Radeon HD 7970 review

Надеюсь в этот раз Хуанг Энвидиевич не будет бегать по сцене и трясти Кеплером, как он это делал с макетом Ферми.

GSC закрылись

2011-12-09T17:06:00.001+02:00

Похоже, Сталкера 2 нам уже не дождаться.
Григорович решил закрыть компанию, не объясняя причин.

http://ukranews.com/ru/news/ukraine/2011/12/09/59663

Хватайте новых разработчиков, пока тёпленькие!

Relocation

2011-12-05T10:32:00.001+02:00

После двух лет жизни на Оболони я переехал в центр города. Снимаю двухкомнатную квартирку вместе с PANDA (ему одному было дорого). Теперь до офиса - 10 минут неспешным шагом. И да, наконец-то мне больше не придётся спускаться в киевское метро. Ура.

OnLive

2011-11-18T12:20:00.001+02:00

У нас в офисе появилось вот такое примечательное устройство:

Это OnLive(R) Microconsole TV Adapter. Подключается к TV через разъём HDMI, а к геймпаду- через переходник USB/mini-USB.Кабелёк коротенький, приходится держать консоль на коленях.

У этого экземпляра уже есть аккаунт на серверах OnLive, так что можно играть. Я для пробы поиграл в Splinter Cell: Conviction и Prince Of Persia: The Fogotten Sands.

Качество изображения на 40-дюймовом телевизоре вполне хорошее, артефактов сжатия я не заметил, возможно их видно только на мониторе, или же железо консольки "старается" убрать все огрехи. Чувства, что ты смотришь YouTube в 240p, не возникает. Частота кадров - по мне где-то 20-25, точнее сказать затруднительно. Есть небольшой лаг ввода, но гораздо меньше чем я ожидал, когда начинал играть. Целиться конечно неудобно, консольный геймпад+специфика доставки контента сообща работают против этого. Да и вообще игрок я никудышный :)

В общем, я думаю, что это будущее игровой индустрии. Пройдут годы, Сеть разрастётся оптоволокном, уменьшится пинг и такие вот решения станут вполне жизнеспособны. А если есть хороший интернет, в казуальные и пошаговые игры можно играть уже сейчас. По сути приход on-line моделей доставки контента неизбежен, как неизбежным стало и появление многочисленных торрентов-трекеров в середине 2000-x. Сеть породила массовое пиратство, она же его и убъёт.

Чикса на Лексусе

2011-11-17T11:39:00.001+02:00

Вчера я ехал на работу

в метель, туман и гололёд,

вдруг мимо пронеслась Тойота,

взяла опасный поворот.

Пересекая автостраду

там, где сплошная полоса,

водитель мазалась помадой

и тушью красила глаза!

Как тут от злости не беситься?

Я в гневе бритву уронил

(я дома не успел побриться

и по дороге щёки брил).

Упала бритва в кофе прямо

(между колен стоял стакан -

мне вкусный кофе варит мама -

его я пью в такой туман ).

Когда предмет тяжёлый падал,

крутой горячий кипяток

плеснул туда, куда не надо -

там третьей степени ожог.

И вот от боли я подпрыгнул,

и из моей руки другой

вдруг выпал телефон мобильный -

и снова - в кофе по прямой.

Не помню, что там дальше было...

Открыл глаза: больница? морг?

Теперь ни тачки, ни мобилы...

Зато повязка между ног.

Весь загипсован под завязку,

без гипса только голова.

А вот мораль у этой сказки -

У ВСЕХ БЫ БАБ ЗАБРАТЬ ПРАВА!

Китайская грамота

2011-11-11T20:10:00.001+02:00

Сегодня нашёл способ заставить шаблонную функцию определять размер массива.

Всё началось с того, что при программировании я использовал несколько вспомагательных шаблонных функций, вроде memzero(), которая является обёрткой над memset() и принимает один параметр вместо трёх:

template < typename T >
inline void *memzero(T *p)
{
return memset(p, 0, sizeof(T));
}

Также я завёл один вспомогательный макрос для очистки статических С-arrays:

#define zeroarray(a) memset(a, 0, sizeof(a));

Мне хотелось оформить этот макрос тоже в виде функции, но вся загвоздка в том, что определив параметр как указатель на тип, применить к нему sizeof() нельзя.Первая попытка оформить функцию в виде шаблона выглядила так:

template < typename T, size_t N >
inline void zeroarray(T a[N])
{
return memset(a, 0, sizeof(a));
}

Но в данном случае компилятор С++ не может вывести размер массива, и sizeof() выдаёт типичные 4 байта для 32-битной конфигурации.Тепение моё лопнуло и я полез в гугл: после 5 минут гугления выяснилось, что существует такое решение этой проблемы:

template < typename T, size_t N >
inline void zeroarray(T(&a)[N])
{
return memset(a, 0, sizeof(T) * N);
}

Я не эксперт в С++, и мне сложно понять, что это за китайская грамота написана в виде параметра функции.Понимаю только одно - выглядит фигово :)

Новое пальто

2011-11-09T11:07:00.002+02:00

Сшил себе сабж:

Driver Concurrent Creates

2011-11-02T11:27:00.000+02:00

Стремление ускорить загрузку программы естественно.
Чем быстрее программа загружается, тем меньше это раздражает пользователя. Применительно к игрострою можно даже помечтать об играх, которые загружаются почти мгновенно :)

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

В отличие от своих предшественников, Direct3D 11 был спроектирован для поддержки мультипоточности. Вкратце, её поддержка заключается в двух возможностях:

1) Driver Concurrent Creates
2) Driver Command Lists

Первая функциональность позволяет создавать объекты (текстуры, буферы, шейдеры) в разных потоках, а вторая - формировать command buffer в отдельном потоке с дальнейшем "вливанием" его в общий контекст рендеринга. Обе эти функциональности опциональны и зависят от видеодрайвера. Если драйвер их не поддерживает, рантайм будет их эмулировать, но без надежды получить выигрыш в производительности.

В DirectX Caps Viewer в разделе "DXGI 1.1 Devices \ Reference \ Direct3D 11" каждый может посмотреть, поддерживает ли текущий драйвер эти "фичи" (как оказалось, утилита может привирать). Сразу скажу, что Driver Command Lists на момент написания этого поста не реализованы ни у AMD, ни у NVidia. О причинах можно только догадываться. Поддержка Driver Concurrent Creates может варьироваться от системы к системе, но обычно она присутствует.

Создание шейдеров на основе скомпилированного байткода вычислительно ресурсоёмкая задача: рантайм должен распарсить и валидировать байткод, а драйвер - соптимизировать его под конкретную архитектуру и транслировать в машинный код GPU. Использование нескольких ядер CPU в целях ускорения этой задачи оправданно, и если драйвер Direct3D 11 поддерживает эту функциональность, её можно задействовать.

Я решил поиграться с мультипоточной загрузкой шейдеров и написал небольшое тестовое приложение. Исходный код расположен здесь (проект для Visual Studio 2008). Суть его проста: сравнить время загрузки одного и того же количества шейдеров используя один и несколько потоков. Для начала я скрестил Win32 и консольное приложения: нет окна и обработчика оконных сообщений, зато есть консоль с HWND. Для инициализации Direct3D достаточно просто создать устройство, во всём остальном нет надобности. Далее я взял несколько простых шейдеров из состава DirectX SDK, байткод которых заставил грузиться в цикле энное количество раз. Для простоты количество создаваемых потоков равно количеству физических ядер CPU, т. е. по одному на ядро. В конце время выполнения обоих тестов сравнивается и подсчитывается фактор ускорения (он может плавать, что естественно).

С установленными видеокартами (и драйверами) AMD для Core 2 Quad я получил ускорение приблизительно 1.8X, для Core i5 - 2X-2.5X. Что интересно, для NVidia ускорение составляет ~3X, при этом скорость создания шейдеров значительно медленнее, чем в случае с AMD. Не четырёхкратное ускорение, конечно же, но и эти показатели неплохи. Интересно было бы запустить тест на новых 8-ядерных FX-81xx от AMD. Если кому-то выпадет такая возможность - пишите. Также неплохо попробовать использовать в тесте более разнообразные и тяжёлые пиксельные и вычислительные шейдеры.

P.S. Не пытайтесь запускать программу из-под отладчика - в этом случае она ведёт себя некорректно.

Hitler gets angry about iPhone 4S

2011-10-25T17:44:00.003+03:00

Гитлер в очередной раз негодуэ

Code Quality

2011-10-22T19:16:00.002+03:00

RAGE

2011-10-12T11:44:00.001+03:00

Обосрались Вы, товарищ Кармаг, со своим RAGE.

С таким дурацким релизом на PC, когда на половине Radeon-ов игра представляет из себя не пойми какой калейдоскоп или вообще падает, это ещё одно убедительное доказательство, что OpenGL (как стандарт) и его реализация (в драйверах) - унылое говно, и его место возле параши (т. е. на мобильниках).

Конечно, AMD с NVidia наваяют очередные говнопатчи под Вашу конкретную игру, но лучше бы они сделали это заранее, чтобы остальные хомячки не видели этот ебаный стыд. Незнание - это блаженство.

Нет, серьёзно. Пошлите нах..й OpenGL (и OpenCL заодно туда же).
Желаю вам, товарищ Кармаг, разума и осознания.

Direct3D 11.1

2011-10-05T19:19:00.000+03:00

Direct3D 11.1 Features

И да, Microsoft сменила движок и дизайн MSDN. Выглядит здорово!

Быстрее света?

2011-09-26T12:13:00.000+03:00

Measurement of the neutrino velocity with the OPERA detector

Поворот не туда

2011-09-24T16:51:00.001+03:00

Страшно? И мне тоже.

Радиус

2011-08-18T21:30:00.002+03:00

Сегодня я валялся на пляже в Ялте и смотрел на линию горизонта, где море соединялось с небом. Вдруг подумалось: вот если бы я был сейчас в средних веках (как Колумб), то ведь можно же было бы определить расстояние до линии горизонта - ну например, с помощью мачты на корабле или просто лодки... Так вот, узнав расстояние до горизонта при заданной высоте наблюдения, как тогда вычислить радиус Земли? Ведь эти три величины геометрически связаны самым непосредственным образом, а значит, существует формула, из которой выводится радиус. Но как её записать, я так и не придумал.

OpenGL 4.2

2011-08-08T23:24:00.001+03:00

Я думал, он уже умер. Наверное, кому-то он всё-таки нужен :)

Дождь

2011-08-03T15:46:00.000+03:00

Я вчера в Киеве попал под настоящий ливень - промок до нитки. Кажется, никогда в жизни я так ещё не промокал.

Я вернулся в Быдлостан

2011-08-01T14:07:00.002+03:00

Спалились

2011-07-29T22:12:00.003+03:00

Intel спалились - процессор Haswell (наследник Ivy Bridge) получит поддержку DirectX 11.1. Это значит, что Microsoft готовит minor update интерфейса для ОС Windows 8:

Intel 2013 Haswell Processor to finally get DirectX 11.1

И ещё другие любопытные слухи. Говорят, следующие поколения игровых консолей Xbox/Playstation обзаведутся графикой AMD, как раз наверное тогда и DX 11.1 подоспеет. Несложно понять, почему - при равных с NVidia вычислительных возможностях GPU AMD имеют меньшее тепловыделение, что критично для компактных устройств. Я уже начинаю подумывать, а не зря ли NVidia затеяла CUDA на consumer level железе?

Shaq Retires

2011-07-26T17:16:00.000+03:00

Легендарный центровой NBA Шакил О'Нил (Shaquille O'Neal), игравший за такие команды, как LA Lakers и Miami Heat, сообщил о завершении профессиональной карьеры, длившейся 19 лет.

Шак, мы всегда будем помнить тебя как Очень Большого и хорошого парня!

Multisample soft shadows

2011-07-22T01:40:00.002+03:00

В последнее время я размышлял, каким путём следует развивать далее реализацию мягких теней. Ясно, что аппроксимация протяжённого источника света (и. с.) от одной точки неприемлема. Можно ограничиться и. с. небольшой площади: в этом случае ошибки, вызванные аппроксимацией, незначительны. Однако это одно из главных преимуществ алгоритма, и отказываться от него не хочется. Чтобы получить болеё четкое представление об ошибках рендеринга, я дополнил реализацию возможностью работы с несколькими семплами на и. с.: силуэт, теневой объём и пенумбра считаются для каждого семпла. Вот примеры изображений:

Области пенумбры (отладочный рендер)

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

Авторы оригинальных penumbra wedges не ставили себе задачей вменяемо решить проблему аппроксимации. Если уж и решать её, то точно не увеличением кол-ва семплов (слишком дорого и неуклюже), нужно менять подход. Например, алгоритм изначально опирается на построение теневого объёма из центра и. с., с последующей компенсации пенумбры по краям чёткой тени. Я думаю, что правильным будет пойти таким путём: считаем coverage в пенумбре без знака (он зависит от того, находимся мы в тени или вне её), а вместо стандартной чёткой тени для центра и. с. определяем область умбры и закрашиваем её чёрным - вклад в освещённость там полностью отсутствует. Получается две логичные части: умбра, где нет освещённости, и пенумбра, где пиксельный шейдер аналитически её высчитывает. Непонятно, как рассчитать умбру для протяжённого источника: приближения тут опасны, если произойдёт "нестыковка" между умброй и пенумброй, в изображении появятся артефакты. В принципе, если мы рассчитываем области пенумбры, то определённо можно выделить и область умбры, но сказать это, увы, проще, чем написать стабильную реализацию.

Я планирую пока вернуться к шлифовке и оптимизации пиксельных шейдеров, например, хочется наконец-то попробовать четырёхмерные таблицы с предрассчитанной освещённостью, вместо того, чтобы считать её в шейдере аналитически - это поможет уменьшить его длину и теоретически ускорить шейдинг. А также отрефакторить код рендера, отшлифовать детали и т. д. Но уже ясно, что геометрическую часть алгоритма нужно менять, как именно - покажет время.

Transformers 3

2011-07-14T02:06:00.004+03:00

Технически совершенный и бездушный.

Не пишется

2011-07-09T23:41:00.002+03:00

GL_EXTENSIONS

2011-07-04T00:57:00.001+03:00

Попытался сегодня поиграть в Quake II (не смейтесь - игра всех времён) на своём ноуте и не смог - игра падала. Режим совместимости никаких результатов не дал.

Разыскал на диске q2source-3.21, собрал отладочный билд, переназначил пути - запускаю. Падает. Начал разбираться - дошёл до инициализации ref_gl и увидел, что движок спотыкается о стандартную ошибку - buffer overflow при попытке вывести строчку GL_EXTENSIONS. Дело в том, что константа MAXPRINTMSG (функция VID_Printf) равна 4096, чего недостаточно для такой строки в наше время - слишком уж она разрослась за все эти годы. Если константу увеличить вдвое - проблема уходит. С - небезопасный язык :)

Эта проблема была решена в OpenGL 3.x, где вы получаете не весь список расширений сразу в одной строке, а имя каждого отдельного расширения по индексу. Надо было сделать так изначально при дизайне API, но никто ведь тогда не думал, что механизм расширений превратится в такой дурдом, а?

Samsung SA750

2011-06-29T01:29:00.008+03:00

Корейская компания Samsung запускает LED-мониторы нового поколения, с поддержкой 3D (т. е. стерео посредством 120 Гц). Я, например, хочу такой:

Одно важное изменение, которое не сразу бросается глаза - начиная с этого поколения, Samsung решили наконец-то избавиться от старого порта DVI в пользу HDMI 1.4 и DisplayPort, разорвав таким образом порочный круг. Правда прямо сейчас в этом есть и свой минус - надо апгрейдиться до видео с поддержкой DisplayPort (AMD), или искать переходник DVI->DP (NVidia).

:)

Update

Уже появились на российских складах:
http://itrate.ru/cgi-bin/show.pl?option=full_retail_news&id=8269
Обзор соседней линейки на xbitlabs:
Samsung SyncMaster SA950 Monitor: 3D Beauty

HK2207 Demo

2011-06-15T01:36:00.003+03:00

Ну вот, приехали!

Я в Бухаресте

2011-06-13T14:00:00.004+03:00

Начальство предложило приехать в Ubisoft Bucharest для решения местных проблем. Беготня с паспортом и визой, полтора часа полёта - и вот я здесь. Пробыть предполагается два месяца.

P.S. Здесь нет русской клавиатуры, клацаю по нужным клавишам с помощью моторной памяти :)

Rectangular light source

2011-06-03T11:24:00.000+03:00

На днях сидел по вечерам за отладкой шейдера пенумбры для прямоугольного источника света. Все мои предыдущие реализации мягких теней использовали только сферический источник света, с прямоугольным как-то не ладилось. В конце-концов я написал алгоритм шейдера на C++ и отладил несколько тестовых случаев. Оказалось, что корректное решение требует инвертирования матрицы 3x3 прямо в пиксельном шейдере, чего в оригинальной реализации алгоритма я не увидел. Программная реализация помогла обсосать все тонкости алгоритма (что с HLSL и GPU-ориентированными инструментами, я считаю, сделать невозможно или крайне затруднительно).

Из-за лоу-поли геометрии и прямоугольности источника света пенумбра выглядит угловатой. Но главная проблема носит название single point silhouette approximation, о ней я уже писал здесь. Из-за этого упрощения тени выглядят как overshadowed, потому что не все потенциальные силуэтные рёбра внесли свой вклад в пенубмру. То, как выглядят тени сейчас, меня не устраивает, поэтому так или иначе придётся реализовывать корректный поиск силуэта.

We want C++ developers

2011-05-31T20:34:00.000+03:00

Маурицио

2011-05-31T11:36:00.003+03:00

Никто не знал, где он ночует и что он ест. О нем говорили, будто он колдун, потому что он умел играть на всех инструментах и играл блестяще, а жил всегда бесприютным, нищим бродягой. Вот этот Маурицио послушал, как звучит виола да гамба моего деда, и предложил ему обмен: дед отдаст ему инструмент, а Маурицио откроет ему тайну жизни. Дед согласился - каждый человек в семнадцать лет хочет заранее узнать тайну бытия. И тогда Маурицио сказал деду, что тот должен сделать еще триста девяносто девять инструментов - на четырехсотой скрипке его ждет бессмертие.

С тех пор в деда Андреа будто вселился демон. Он работал как галерник, дни и ночи, случалось, что по трое суток он не выходил из мастерской, руки его были изъедены кислотами и растворителями, в мозолях, порезах и ссадинах, с трех пальцев были сорваны ногти, и больше они не выросли.

Он сделал около пятисот инструментов, и когда перед смертью от него ушел исповедник, я спросил деда, а было мне тогда девять лет:

- Этот противный сумасшедший колдун Маурицио обманул вас, синьор?

Дед был совсем старый, просто усохший от времени, весь
пергаментно-желтый, только глаза и руки жили еще в нем. Он засмеялся и сказал мне:

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

День рождения

2011-05-27T14:03:00.005+03:00

У блога сегодня день рождения - ему исполнилось два года :)
По этому поводу я приготовил (сидел допоздна) несколько скриншотов:

Код не отполирован, множество визуальных артефактов, ещё есть множество вещей, которые я хочу реализовать и отладить. Но впервые за всё время мягкие тени делаются с поддержкой Direct3D 11.

И ещё одно. Начиная с этого дня я решил завести англоязычную версию блога, в котором я буду публиковать переводы своих ключевых постов (и совершенствовать свой английский): joescg-en.blogspot.com.

Лебедев

2011-05-24T17:09:00.000+03:00

Герой в тельняшке! Ура, блять...

3DMark 11

2011-05-21T17:22:00.001+03:00

Прочитал я обзор и анализ уже давно вышедшего 3DMark 11, закручинился.

Печально всё обстоит в нашем королевстве, при том что GPU сильны и умны, как никогда прежде. Похоже, CG отныне будет развиваться только скачками, от старого поколения консолей к новым, с периодом этак лет в... 10.

Packed Stream Output

2011-05-18T16:37:00.007+03:00

Есть такой перекос в D3D 10/11 железе - input layout может фетчить данные из вершинного буфера в разнообразных форматах, а вот stream output может выводить только 32-битные значения (написано в са-а-амом конце раздела Getting Started with the Stream-Output Stage). Между тем, обычно float точность сильно избыточна для небольших моделей, и хотелось бы иметь возможность выводить данные типа half.

SM 5.0 предоставляет две функции для конвертирования float в half и обратно: f32tof16() и f16tof32(). Для них есть dedicated silicon в D3D11-железе и подразумевается, что они first-class citizen. Также эти функции могут применяться в SM 4.0, в этом случае они эмулируются программно - в шейдер вставляются многочисленные операции битового сдвига, целочисленного сложения и т. д. Я случайно нашёл С-аналоги этих функциий в OpenGL RedBook: Floating-Point Formats Used in OpenGL (вероятнее всего, алгоритм следует стандарту IEEE 754-2008 для half precision floating-point format). В своё время я написал подобные функции конвертирования, работающие в шейдере посредством lookup table, но в свете SM 5.0 это уже устарело :)

У меня появилась идея, что с помощью этих функций можно в геометрическом шейдере паковать два float-значения в один, ужимая каждый в half, и т. о. снизить нагрузку на stream output и на input assembler. Кроме того, можно уменьшить важный параметр maxvertexcount геометрического шейдера: например, если ранее GS выводил две вершины, то теперь достаточно одной. Общая идея такова: SO выводит по два half, запакованных во float, а IA интерпретирует вершинный буфер как R16G16B16A16_FLOAT, т. о. мы сможем легко читать каждую запакованную вершину.

Вот код упаковки двух трёхкомпонентных векторов в один четырёхкомпонентный: pck. Четвёртый компонент необходим вследствие того, что формат R16G16B16A16_FLOAT имеет четыре компоненты (6-байтные форматы с тремя компонентами не поддерживаются), но его можно игнорировать при чтении из вершинного буфера, а значит, и при упаковке.

Всё легко пакуется до тех пор, пока вы выводите чётное кол-во вершин: 2, 4 и т. д. А если нужно вывести 3 вершины (треугольник)? Можно запаковать первые две в один vec4, третью - в компоненты .xy второго vec4, компоненты .zw - оставить пустыми. Но при последующем чтении треугольника мы прочитам три half4, а пустой четвёртый будет относиться уже к следующему примитиву - ошибка! Указать же stride между примитивами в вершинном буфере невозможно - никому в голову не придёт идея оставлять в памяти ненужные "дырки".

Решение простое. Если раньше мы сжимали, скажем, четыре вершины в две, то теперь надо сжать три в одну:

struct gs_out
{
vec4 pos1_pos2 : Data0;
vec2 pos3 : Data1;
};

[maxvertexcount(1)]
void gs_main(..., inout PointStream< gs_out > stream)
{
...
}

В IA читаем данные из вершинного буфера как поледовательность half4 - и всё.

Дом

2011-05-09T15:06:00.007+03:00

Вам знакомо это ощущение - когда лучшие фильмы с торрентов уже много раз пересмотрены, и вы без особой надежды пытаетесь выловить что-нибудь новое или, что лучше, хорошо забытое старое. Вот в таком настроении я как-то случайно наткнулся на фильм "Дом из песка и тумана".

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

С тех пор я больше не пересматривал его - мне хватило одного раза. А вот сегодня случайно узнал, что прокат фильма в США даже не отбил его скромный бюджет. Это не удивительно, ведь под него не почавкаешь попкорном, а желание просто поржать быстро пропадает. И всё же мне стало немного грустно, что снимать такие фильмы - это рисковать своими положением и финансами, и я просто решил написать об этом фильме - пускай хотя бы ещё несколько человек узнает о нём.

T-junction elimination

2011-05-06T16:22:00.001+03:00

При рендеринге теней от md2 мешей появились артефакты. Как выяснилось, даже лоу-поли модели из Quake II не лишены багов (а я надеялся, что всё будет отлично). Видимо, это из-за того, что изначально они не предназначались для отбрасывания теней, хотя заметно, что при их моделировании соблюдались правила замкнутости.

В общем, конвертер пришлось дорабатывать, чтобы он мог выделять кластеры несмежных треугольников, обходить T-junction, делать поиск по совпадающим координатам и т. д. В итоге мне удалось обойти в моделях мелкие ошибки и убрать из adjacency невалидные треугольники.

В принципе, целый ряд моделей не содержит никаких ошибок. А вот например, у bitch выпало целое плечо (как оказалось, там какая-то каша из треугольников).

Плакат SC:C

2011-04-29T18:10:00.002+03:00

К нам в офис привезли замечательный плакат "по мотивам" нашего проекта:

Есть ещё парочка других, но это уже не так интересно.

Depth of Field: First Experiments

2011-04-26T13:00:00.005+03:00

Начал экспериментировать с различными реализациями depth of field. Тема эта очень сложная, поэтому для начала решил попробовать несколько brute-force методов для получения референсного изображения, отталкиваясь от которого, можно было бы подгонять real-time технику до нужного качества.

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

Используется 48 сэмплов, для каждого кадра инстансингом рисуется 1024 кубика, расстояние до фокальной плоскости учитывается при построении look-at матрицы. 48 "выборок" явно недостаточно для сглаженного изображения, очень виден бандинг. Нужно как минимум 128, и хорошо посчитанный kernel. Можно получить очень хороший depth of field, качеством напоминающий ray-tracing.

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

Немного о реализации: с помощью инстансинга рисуются всё те же 1024 кубика, в depth буфер выводится view space z. Затем рисуется w * h вершин, по одной вершине в каждом пикселе окна. Чтобы снизить нагрузку, вершинный буфер не используется, вызовы вершинного шейдера генерируются вызовом DrawInstanced(), в шейдере используется семантика SV_InstanceID для расчёта экранных координат. Вершинный шейдер сэмплирует цвет и глубину и передаёт данные в геометрический шейдер. Последний рассчитывает диаметр circle of confusion и раздувает вершину в спрайт нужного размера. Ну а дальше блендинг в PS. Техника упирается, как ни странно, не в геометрический pipeline, а в блендинг в FP-render target.

Следующий шаг - разбор уравнений, по которым рассчитывается правильный CoC (как оказалось, у всех - по-разному).

Update

Сегодня построил график изменения радиуса circle of confusion в зависимости от параметров оптической системы: диаметра линзы, фокального расстояния и фокальной плоскости. Для построения была взята формула из пейпра Dynamic Light Field Generation and Filtering:

По характеру кривой график совпал с тем, что приведён в другом пейпре по DoF: Pyramidal Image Processing. Естественно, что на кривую влияют выбранные параметры и характер масштабирования по оси Y, т. к. размеры CoC меняются далеко нелинейно. Но вот например в слайдах Advanced Real-Time Depth of Field Techniques приводится другой график:

и не совсем ясно, по какой формуле он считался. Будем думать :)

MacOS X 10.7 Preview

2011-04-19T13:41:00.002+03:00

По слухам, Apple наконец-то добавляет поддержку OpenGL 3.2 в новой версии операционной системы:

Apple releases first developer preview of MacOS X Lion

И да, наконец-то размер окна можно изменять, хватаясь мышкой за любую его рамку!

Бомбы не оказалось

2011-04-15T11:32:00.005+03:00

Я обычно возвращаюсь домой через станцию метро "Университет". Но вчера распорядок дня выбился из привычной колеи: станцию оцепили, милиция преграждала проход. Я заснял это безобразие на камеру iPod-а:

В новостях написали, что якобы была обнаружена бомба. Позже выяснилось, что никакой бомбы нет. Вместо неё был сломанный мобильник в помятом пакете из "Макдональдса".

D3D10 MRT

2011-04-07T18:10:00.002+03:00

Output-Merger Stage (Direct3D 10), почти в самом конце подраздел Multiple RenderTargets Overview:

... Furthermore, all render targets must have the same size in all dimensions (width, height, depth, array size, sample counts). Each render target may have a different data format.

Как-то до сих пор ускользало от меня. И да, в Direct3D 9 depth буфер по размерам может быть больше, чем render target.

Косим под оффисс

2011-04-05T15:26:00.002+03:00

Splinter Cell: Conviction

2011-03-28T12:37:00.005+03:00

На http://www.macgamestore.com/ появился порт Splinter Cell: Conviction (Капитан Очевидность подсказывает, что это для Mac). Игра доступна посредством цифровой дистрибуции по цене $19.99:

Tom Clancy's Splinter Cell: Conviction

(актуальные скриншоты Mac-версии)

Это проект, над портированием графической составляющей которого я и работал в Ubisoft Kiev весь последний год. Да, юбики решили портировать свои крупнейшие AAA-тайтлы на Mac, и это при том что SCC вначале вообще объявлялся как Microsoft-exclusive проект!

Изначально планировалось зарелизить проект 29 октября 2010, до старта рождественских продаж, но сроки мы благополучно зафейлили и начальству пришлось даты сдвигать. Мы всё же успешно довели проект до рабочего состояния, и через некоторое время он должен появиться и в Mac App Store (уже без DRM - требование яблочников).

Удачного плавания, Сэм!

MD2 normals

2011-03-25T18:23:00.003+02:00

Есть такой файл в составе Quake II engine - anorms.h. В нём хранятся предрассчитанные нормали (скорее всего по сфере). Если говорить про формат MD2, то key-frame анимация в нём делает хранение нормалей непосредственно в вершине неэффективным. Вместо этого, в .w компоненте хранится индекс нормали из anorms-таблицы.

Для выборки нормали я залил anorms-таблицу в буфер и подключил его как shader resource. Теперь в вершинном шейдере делается выборка нормалей по индексам и их интерполяция. Для проверки корректности я написал простой геометрический шейдер, который берёт нормаль в вершине, размножает её и выводит как линию.

Точность этого метода хранение нормалей, конечно, низковата; линейная интерполяция помогает сгладить квантование.

P.S. Теперь я узнал, почему зелёный цвет (нормалей) плохо выглядит на белом фоне: человеческий глаз наиболее чувствителен в зелёному цвету и воспринимает его как более яркий, чем красный или синий.

ПЕЧ 590

2011-03-24T17:48:00.001+02:00

NVidia представила ПЕЧ 590.

Петерсон суетится, тычет пальцами в оверлеи, меряет какой-то штукой деЦИБелы :)

Обзоры:

TechPowerUp

Bit-Tech

IsDebuggerPresent

2011-03-23T17:24:00.002+02:00

Сегодня начал играться с компиляцией проекта вкупе с DirectGL в release, чтобы убедиться в работоспособности кода во всех конфигурациях. И сразу сделал открытие: время загрузки шейдеров резко увеличилось (требовалось всего 1-2 секунды)! Я бросился инспектировать код на предмет #ifdef _DEBUG, но никаких зацепок не нашлось. Тогда я пересобрал проект в debug конфигурации, запустил по Ctrl-F5 и о чудо: GLSL шейдеры скомпилировались влёт.

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

Этот ваш DirectX тормозит

2011-03-21T17:56:00.003+02:00

AMD: DirectX тормозит развитие игр на ПК

Мог бы Crysis исполняться более эффективно, если бы Crytek не была ограничена Direct3D и могла иметь более широкий низкоуровневый доступ к GPU?

А к какому GPU?

Ускоритель Xenos в Xbox 360 имеет более чем в 10 раз меньшую производительность, чем самые мощные GPU для ПК. Так почему же игры не выглядят в 10 раз лучше?

А как это: в 10 раз лучше? :)

На самом деле, эту проблему намеревались решить в DX 11 с помощью Driver Command Lists, но эта фича до сих пор не реализована ни в драйверах AMD, ни у NVIDIA. Разработчики из DICE жалуются: уже два года ждём, и всё нету.

P.S. Ричард Хадди - осёл.

AC2 in Mac Store

2011-03-18T19:30:00.005+02:00

В Apple Mac (не App!) Store появился порт Assassin's Creed II, который разрабатывался Ubisoft Kiev. Нужно сказать, что это игра из разряда "тяжеловесов" для Mac, т. к. в основном сейчас там (не считая нескольких исключений) продаются довольно примитивные игры.

Для сёрфинга по магазину приложений нужны MacOS X и App Store клиент. Стоит игруша $37.99.

Думаю, скоро там появится порт игры, над графикой которой весь прошлый год работал и я :)

GS

2011-03-16T11:09:00.003+02:00

Не используйте массивы!!!
Ну или GlukoGL... :)

District 9 Main Theme

2011-03-11T12:27:00.000+02:00

UE3 Samaritan Demo

2011-03-10T15:11:00.001+02:00

Впечатляет:

http://www.youtube.com/watch?v=RSXyztq_0uM

Хотя мне бы больше понравилась яркое солнышко, голубое небо и зелёная травка :)

GlukoGL

2011-03-10T13:06:00.005+02:00

Волею судеб угораздило меня отлаживать OpenGL рендер на iMac-е под Windows 7. GLSL-шейдеры, которые на этой же машине под управлением MacOS X компилируются и компонуются влёт, под Windows с драйверами ATI делают это со страшными тормозами. Вот для примера вырезки из лога: http://pastie.org/1655135

Несложно подсчитать, сколько приходится ждать, пока всё это счастье запустится и программа что-то нарисует. К тому же это только небольшая часть шейдеров, они собираются "на лету", ибо ждать, пока соберутся все часто используемые пары, не хватит даже ангельского терпения. К слову, под MacOS X несколько сот пар этих же шейдеров компилируются и компонуются за 8 секунд.

Похоже, GLSL-компилятор Apple писали самостоятельно, и он невероятно быстр. Наверное, компилирует в какой-то промежуточный код, который дальше переколбашивает атишный драйвер, а может, в Apple сами написали драйверы под железо маков. А вот для Windows драйвер писали криворукие индусы, ппц.

Update

Ура, мой DirectGL заработал! Наконец-то.

Beyond Programmable Shading

2011-02-24T16:51:00.001+02:00

Немного ссылок, если у кого их до сих пор нет:

SIGGRAPH 2010 Slides
NVIDIA SIGGRAPH 2009
NVIDIA SIGGRAPH 2010
NVIDIA GDC 2011

Стиляги

2011-02-19T13:36:00.008+02:00

Сшил наконец-то себе пальто, о котором я писал раньше. Ох и пришлось же мне с ним повозиться. Но носить Совпаршив с Петровки - с меня довольно.

"Как сказал буржуазный писатель Антон Палыч Чехов, надо по капле выдавливать из себя жлоба." (C) Фрэд.

Да, задроты, чтобы носить такое пальто, нужно иметь крепкие орешки :)

My own Fraps counter

2011-02-16T16:36:00.001+02:00

От нечего делать прикрутил пока счётчик FPS к DirectGL.

Дело в том, что на Mac нет встроенных средств подсчёта кадров в секунду, и программ наподобии Fraps я тоже не видел. Поэтому было решено написать встроенный счётчик, общий для Win и Mac, а за образец была взята утилита Fraps.

Я отсканировал цифры Fraps-а принт-скрином и выстроил их в текстуре 160x26. Потом я написал утилиту, которая считывала данные из этого bmp-файла и записывала их в виде массива dword-ов для C++. Этот массив зашивается в exe-файл при билде, его легко копировать в текстуру и не нужно таскать с проектом .bmp файл. Далее я написал простой класс, который ведёт подсчёт кадров и расчёт fps, а также выводит несколько текстурированных квадов с текстурой шрифта. Т. к. stretch бэк-буфера DX9 не влияет на счётчик Fraps, мой вариант рисуется после того, как на окно натянута текстура с изображением кадра, но до вызова SwapBuffers().

Получился счётчик, который как две капли воды похож на Fraps.

Нокия

2011-02-11T12:36:00.003+02:00

Враг моего врага - мой друг.

MD2 Converter

2011-02-09T15:15:00.009+02:00

Перенёс наконец-то код загрузки MD2 на Direct3D 11.

Т. к. формат очень старый и в своём первоначальном виде плохо подходит для Direct3D 11, было решено написать конвертер, который брал бы исходные данные и перерабатывал их таким образом, чтобы можно было легко загружать их и оперировать ими на GPU. Для простоты формат я назвал U(nified)MD2.

Во-первых, вершины всех фреймов в формате ubyte собраны вместе и заливаются в один буфер вершин. Для расчёта промежуточного кадра буфер вершин подключается к input slot 0 и 1, для первого слота указывается смещение для текущего кадра, а для второго - смещение для следующего за текущим кадра. Позиция вершины рассчитывается в вершинном шейдере простой интерполяцией двух атрибутов.

Для геометрии модели считается adjacency и записывается вместо стандартных индексов треугольников. Такой единый индексный буфер можно использовать как для поиска силуэтов, так и для стандартного рисования модели (железо игнорирует смежные индексы, если геометрический шейдер не установлен или не нуждается в них).

Данные об анимациях и их длинах также были переработаны для более удобного чтения (нет необходимости в парсинге).

Сложнее всего было решить, как поступить с текстурными координатами. Из-за швов (seams) в MD2 моделях существуют вершины, которые имеют одинаковую позицию, но разные текстурные координаты, и использовать один индексный буфер в таком случае невозможно. Графические ускорители никогда не поддерживали несколько индексных буферов (по очевидным причинам - сложность pre- и post-TnL кэшей увеличивается), поэтому простых решений два: индексировать на CPU или размножать вершины с разными текстурными координатами. Т. к. модели в Quake II геометрически очень просты, формировать буфер на CPU легко, но это не интересно. Размножение вершин возможно и обычно так и поступают в стандартных моделях, но в данном случае используется key frame анимация с множеством копий одних и тех же вершин, и дублирование станет многократным - решение получается некрасивым.

Наиболее правильный подход в данном случае - размножить uv координаты так, чтобы на каждый треугольник приходилось по три uv координаты (т. к. текстурные координаты общие для всех кадров, их увеличение несущественно). Теперь в геометрическом шейдере можно использовать семантику SV_PrimitiveID для индексации буфера текстурных координат, который подключается как shader resource:

Buffer g_buffer : register(t0);
uint pid: SV_PrimitiveID;
...
float2 tex = g_buffer.Load(pid * 3 + i);

где i - номер вершины треугольника.

Внедрение простого геометрического шейдера в современных GPU не приводит к существенному падению производительности, поэтому можно смело использовать такой подход. Впрочем, в случае с MD2 это скорее просто спортивный приём :)

И последнее: в MD2 текстурные координаты хранятся в формате ushort (значения делятся на высоту и ширину скина, получается float), но конвертер преобразует их в half.

iPod

2011-02-05T12:44:00.000+02:00

Купил Apple iPod 4 Gen на 8 Гб.

Нужно сказать, что гаджет замечательный - легкий, плоский, изящный. Retina Display выше всяких похвал: текст и контролы кристально четкие, растра не видно.

Сначала не мог разобраться с iTunes на MacOS X, но затем с легкостью закачал свою любимую музыку, iBook и несколько PDF, посмотрел демонстрационные версии Angry Birds и Cut the Rope, еще пару программ.

А купил я под для изучения английского. Его задача - бухтеть мне на ухо английскую речь в течении дня, и так, думаю, где-то полгода. Параллельно планирую заниматься грамматикой и пополнять словарный запас, и думаю, что мой английский сдвинется с мертвой точки.

Для iPod доступны бесплатные подкасты для изучающих английский, а также спец. программы (увы, платные, но посмотрим). Если кто надумает увлекаться английским, на ESL Podcast можно найти множество подкастов для этого занятия: интересно, что iPod отображает текст, если он записан вместе со звуком, так что можно слушать и одновременно читать диктуемый текст, если какое-то слово было не понято.

О скрипках

2011-02-02T13:55:00.004+02:00

Пятнадцать лет... Пятнадцать лет я строил свои скрипки, искал новые конструкции, мучился... мучился с непослушными лаками. Мои инструменты стали красоты неслыханной! Я поселил в них сказочный мир звуков. Я всё это хотел подарить людям, но Вы, как в турецкий плен, уводили все мои детища. Я больше никогда, никогда не слышал их голоса... Боже, за что же такое наказание?

Елизавета

2011-02-02T10:36:00.001+02:00

Весёлая царица была Елисавет: Поёт и веселится, порядка только нет.

Видеокерпич

2011-01-24T17:08:00.000+02:00

Это Gainward GTX 580 Phantom. Страшно? И мне тоже...

Фюрер

2011-01-24T14:33:00.002+02:00

Со Стиви беда, товарищи. Похоже, рак его всё-таки доканает... Так и помрёт посреди своей империи, своих миллиардов и посреди всех этих ебучих гаджетов, на которых он эти миллиарды заработал. С Александром Македонским всё так и случилось, кстати (только его отравили). Лишний повод задуматься, насколько легко всё превращается в прах в этом мире...

MD2 loader update

2011-01-22T16:45:00.002+02:00

Осталось перенести на Direct3D 11.

С++: отделение интерфейса от реализации

2011-01-16T18:09:00.008+02:00

Концепция инкапсуляции основана на разделении того, как выглядит объект (интерфейс), и того, как он в действительности работает (реализация). Но известно, что в С++ определение класса включает в себя описание как методов, так и типов данных и переменных-членов класса. Описание членов класса в файле заголовков (.h) приводит к необходимости подключать описания и определения дополнительных типов, что увеличивает объём компилируемого кода и как следствие, компиляция замедляется. Кроме того, при каждом изменении внутренних деталей определения происходит перекомпиляция всех зависимых файлов, даже если интерфейс остался неизменным.

Эту проблему можно преодолеть, если разбить класс на интерфейс для типа данных и реализацию типа данных. Возможны два варианта такого подхода:

1) Интерфейс представляется в виде абстрактного класса, где все методы чисто виртуальные. Реализация представлена производным классом, который содержит реализацию всех виртуальных методов и необходимые переменные-члены класса. Конструктором объекта выступает фабрика, возвращающая указатель на абстрактный интерфейс.

2) Идиома Pimpl. Интерфейс хранит указатель на непрозрачный (opaque) для клиента тип данных. Реализация типа данных и методов интерфейса размещается в .cpp файле, при этом методы класса-интерфейса просто вызывают соответствующие методы класса-реализации. Возможен и другой вариант: opaque тип данных содержит только члены-переменные класса, с которыми работают методы интерфейса: вместо обращения this->field добавляется один уровень косвенности: this->pimpl->field.

Оба этих подхода имеют ряд недостатков. Использование виртуальных методов или передача вызовов классу реализации снижает эффективность программы в случае высокочастотных взаимодействий между классами, а необходимость выделять память отдельно для интерфейса и реализации замедляет создание объектов и повышает фрагментацию памяти. С другой стороны, дополнительный уровень косвенности замедляет доступ к данным, увеличивает объём кода и ухудшает его читаемость.

Оба этих подхода могут использоваться только точечно, для некоторых классов программы, но не годятся для повсеместного использования. А между тем, хотелось бы структурировать код именно таким образом: определение класса в файле заголовков содержит только описание методов интерфейса, а переменные-члены класса и внутренние типы реализации определяются в .cpp файле.

Для преодоления этой проблемы на вооружение была взята следующая идея:

Cделать различным определение класса для разных единиц трансляции: это возможно, т. к. в С и C++ единица трансляции компилируется автономно и независимо от остальных.

В данном случае роль дескриптора (opaque handle) играет некий базовый класс, от которого наследуется класс-интерфейс реализации. Представим себе некий класс CFoo, реализация которого должна быть скрыта, а клиенту предоставляется лишь интерфейс. Определим класс как производный от класса-дескриптора HFoo:

Declaration of CFoo
(для просмотра я рекомендую тему Slush and Poppies)

Напишем код клиента, который работает с интерфейсом класса CFoo:

Client

Мы определили дескриптор HFoo как пустую структуру, после чего стало возможным правильное определение CFoo: подключаем его определение и компилируем код. Всё нормально.

В файле реализации мы делаем следующий трюк: определяем HFoo так, как того требует реализация (например, нужны две целочисленные переменные), после этого подключаем определение:

Implementation of CFoo

Теперь класс CFoo имеет разные определения в файле реализации и в коде клиента, но это никак не мешает компиляции и сборке программы. Но работать программа не будет, при её запуске можно легко получить heap corruption или AV: почему? Дело в том, что для клиента CFoo имеет, как и положено, размер 1 байт, поскольку не содержит каких-либо членов класса. Поэтому CRT честно выделит 1 байт для экземпляра класса и вернёт указатель на него. Реализация же попытается обратиться как минимум к 2 * sizeof(int) байтам памяти, что вызовет ошибку. Решить проблему можно двумя способами: создать фабрику или перегрузить операторы new и delete для CFoo. Главное, чтобы память выделялась в файле реализации, где CFoo определяется как объект размером 8 байт. Мне больше нравится второй подход:

Extended definition of CFoo
Extended implementation of CFoo

Этот код компилируется и выполняется без ошибок как в MSC, так и в GCC (единственная сложность - неочевидное требование подключения cstddef для operator new(), в противном случае получаем ошибку declaration of 'operator new' as non-function).

Достоинство данного подхода: никакого оверхеда по памяти и скорости выполнения. Недостаток: хак. Завтра я также постараюсь рассмотреть проблемы, возникающие при таком подходе и возможные пути их решения.

До встречи!

Update

Неудобно каждый раз для нового класса прописывать собственный аллокатор, поэтому мы эту работу поручим препроцессору. Более того, неудобно каждый раз определять пустую структуру-дескриптор перед включением .h файла с классом. Назовём эту структуру заголовком (header), и определим её в том же .h файле, где размещается определение соотв. класса, а определение обложим гвардами препроцессора:

#ifndef FOO_DECLARED
DECLARE_HEADER(Foo)
#endif

Макрос FOO_DECLARED описывается в файле реализации после определения "настоящего" дескриптора и перед включением заголовочного файла. Таким образом мы легко контролируем, какое именно определение дескриптора будет видно в файлах проекта.

Теперь о вещах более приземлённых.

Одним из недостатков подставного определения является то, что отладчик MS Visual Studio не видит переменные-члены класса во время отладки (сразу оговорюсь, что GDB в Xсode видит нормально). Досадно, но это факт: по каким-то причинам отладчик "видит" только пустую структуру-дескриптор без полей - понятно, что отладка такой программы быстро превратится в настоящий кошмар.

Чтобы преодолеть это досадное неудобство, можно в теле метода объявить указатель на дескриптор и присвоить ему this:

const HFoo *_this = this;

Ещё одно требование - HFoo должна размещаться в безымянном пространстве имён, иначе отладчик будет видеть поля структуры с переменным успехом (это зависит, похоже, от порядка сборки, а впрочем, не уверен). Если все условия выполнены, в процессе отладки можно видеть поля класса:

Ну я для GDB в этих триках нет необходимости

Поручим и эту работу по разрастанию кода препроцессору. Соберём все вспомогательные макросы в отдельный файл заголовков:

common.h

Вот как теперь выглядят сокращённые определение и реализация CFoo:

Shortened declaration of CFoo

Shortened implementation of CFoo

Макросы BEGIN_HEADER и END_HEADER я ввёл для упрощения определения дескриптора в безымянном пространстве имён, но, возможно, у кого-то появится решение получше.

Ну вот и всё. Дискасс из велкам :)

MD2 loader

2011-01-08T21:14:00.005+02:00

Мне как программисту тяжело создавать 3D-модели, а использовать кубики и шарики уже надоело. Решил выбрать какой-нить подходящий 3D-формат, с поддержкой анимации. Т. к. с MD5 у меня всплывали проблемы с расчётом adjacency, то выбор пал на формат MD2 из игры Quake II: формат прост и можно взять замечательные модельки прямо из игры.

Недостатком формата является то, что в нём используется повершинная анимация. Все "кадры" анимации хранятся в виде набора вершин, и т. к. кадров много и вершины в каждом кадре дублируются, то размер анимации получается немаленьким: в среднем 200-300 кб (до мегабайта). Для экономии памяти вершины хранятся в формате byte, каждый кадр содержит значения scale и translate для восстановления позиций вершин в формате float.

Оригинальный Quake II и всякие тулзы обычно рисуют MD2 прямо из системной памяти, делая масштабирование и интерполяцию кадров на CPU. Это было не тяжело, т. к. модели были самые настоящие low-poly (SM 5.0 и тесселятор никто ещё не юзал!). И хотя нагрузка на процессор тут минимальна, эту задачу лучше всего перенести на GPU.

Вершины всех кадров я разместил в одном вершинном буфере в формате GL_UNSIGNED_BYTE. Этот буфер привязан к вершинным атрибутам 0 и 1, но для нулевого атрибута указывается смещение для текущего кадра, а для первого - смещение для следующего за текущим кадра. Таким образом не надо создавать отдельный вершинный буфер для каждого кадра. Далее в шейдер передаются параметры scale и translate для каждого из двух кадров и вес для интерполяции полученных вершин. На выходе получаем анимированную модель.

DirectGL prototype is over

2011-01-05T15:12:00.000+02:00

Думаю, что с DirectGL на данном этапе можно закругляться.

Желаемые цели достигнуты: сторонние демки (включая DX SDK) компилируются, линкуются и запускаются с подставными интерфейсами. Все render states Direct3D 9 максимально близко переведены на OpenGL 2, так что приложения показывают идентичный результат.

Кстати, в Windows 7 OpenGL 1.1 без драйверов эмулируется через Direct3D (майкрософт тоже написали враппер), так я смог на ноуте без OpenGL драйверов поиграть в Quake III. Тут я подумал: что, если на чистой Windows 7 запустить D3D9-демку через мой DirectGL: вызовы будут направляться OpenGL, который является обёрткой над Direct3D! Но проводить такие эксперименты я не стал, т. к. это слишком жестоко :)

Когда я только начинал наброски враппера, было интересно, получится из этого что-нибудь, или нет: фигли, портануть весь API! Но скилл, как выяснилось, позволяет, и теперь это становится даже скушным, т. к. растеризатор по своей природе примитивен, и сore API - тоже. Можно выделить несколько потенциальных проблем, которые могут возникнуть при портировании (например, экзотические атрибуты в vertex decl, HLSL-шейдеры и эффекты, инстансинг), но их придётся решать уже на конкретной задаче (а Wine решает "на месте"). Пока же можно было бы наращивать какой-нить рутинный функционал вроде загрузки DXT-текстур, работы с мешами, D3DX math (сейчас через dll-прослойку все вызовы перенаправляются в стандартный D3DX) и т. д., но это monkey job, и растить в себе кодера как-то не хочется.

Т. к. я сейчас в маленьком отпуске (вернулся из Киева домой на праздники), то думаю вернуться назад к теням и рейтрейсингу в шейдере, что-то я в последнее время забросил эту тему.

Basic HLSL

2011-01-04T16:34:00.004+02:00

После нескольких часов отключения функционала Direct3D 10 из DXUT-а и ещё нескольких часов возни по замене stub-овых методов на dummy (т. е. на такие, что ничего реального не делают, но возвращают валидный указатель на объект), мне удалось запустить сэмпл из Direct3D 9 SDK - Basic HLSL.

Один из багов, из-за которого жирдяй DXUT отказывался стартовать, был в методе IDirect3D::GetDeviceCaps. Я реализовал его только частично, но выяснилось, что DXUT проверяет поле PixelShaderVersion структуры D3DCAPS9, которое я не заполнил. После исправления бага всё пошло как по-маслу. Теперь почти весь DXUT 9 реально работает с ложными интерфейсами Direct3D. Я отключил код, который загружает D3DX Effects и рисует через них интерфейс DXUT-a, и отключил ещё несколько функций загрузки, а в остальном "всё по-честному". В результате рисуется очищенное окно и текст :)

Т. к. почти все демки из DXSDK используют эффекты при рендеринге, увидеть их картинку "из-под" OpenGL вряд ли получится, но зато возня с демками поможет вылизать остальной функционал DirectGL и подготовить его для портирования реального проекта (надеюсь, хоть там эффектов не будет).

Новый Год

2011-01-02T01:20:00.004+02:00

В лесу родилась ёлочка
В квартире - умерла :(

Ходорковский

2010-12-31T12:11:00.001+02:00

М-да... На пляже бабу мне не тра..ать :(

Сдали бету

2010-12-25T20:06:00.000+02:00

Совсем забыл написать: мы сдали бету!
Теперь надо мастер :)

DirectGL progress

2010-12-24T11:24:00.002+02:00

Ещё несколько демок прибыло:

Интересное затруднение возникло с mesh subsets, т. к. я не понимаю, каким точно образом attribute buffer управляет сабсетами меша. Чтобы добиться схожей функциональности, я выделил ограниченное кол-во индексных буферов для предполагаемых сабсетов (скажем, 8). Я просто обхожу attribute buffer и формирую индексные буферы сабсетов из главного индексного буфера. Новый индексный буфер выделяется только тогда, когда встречен соответствующий индекс в attribute буфере, поэтому расход памяти пока приемлемый. Можно и дальше развивать эту идею, но всё-таки интересно, как данный подход на самом деле реализован у Microsoft.

С демкой multiple viewports я наткнулся на интересное различие между Direct3D 9 и OpenGL: в первом операция очистки ограничена границами вьюпорта, а в последнем - нет, т. е. чистится всё. Побороть различие удалось установкой scissor теста.

DirectGL progress

2010-12-20T13:12:00.003+02:00

Порт ещё одной демки: occlusion query

Изначально я планировал портировать только ядро Direct3D 9, но желание перенести некоторые демки на OpenGL стало столь велико, что я засучил рукава и принялся писать реализацию интерфейса ID3DXMesh и обвязку для него, т. е. D3DXCreateBox(), D3DXCreateSphere() и т. д. Спортирую только самое необходимое, а Wine мне поможет. Кстати, в последнем отсутствует функция D3DXCreateTeapot(), поэтому я думаю просто сделать дамп меша Direct3D в текстовый файл и потом подключить его как .h.

Да, когда-то мы API просто изучали, а теперь мы их портируем :)

DirectGL progress

2010-12-16T17:24:00.004+02:00

Спортировал ещё несколько демок, включая одну из DX SDK:

Все демки работают идентично Direct3D 9, за исключением той, что искривляет геометрию флага в вершинном шейдере: в D3D fixed-function pixel processing дружит с vertex shader, а в OpenGL - нет, по крайней мере в современных драйверах, поэтому изображение чёрное (я вывел в wireframe). Демка с жёлтым прямоугольником внутри синего - это мой собственный unit-test методов IDirect3DTexture9::LockRect и UnlockRect c RGBA8 форматом.

На моей Луне

2010-12-15T13:31:00.000+02:00

Пальто

2010-12-12T20:15:00.001+02:00

Забыл написать, что пальто из зелёного вельвета я всё-таки сшил.

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

Счастлив тот, кто сшил себе

В Гамбурге штанишки.

Благодарен он судьбе

За свои делишки.

3DMark 11

2010-12-09T11:15:00.002+02:00

Погонял бесплатную версию бенчмарка на iMac-е с HD 5750.

Тормозит (и сильно), при том что настройки в бесплатной версии - низкие, соответственно и качество... Чувствуется, что ребята создали задел "на будущее", т. к. на однопроцессорной ПЕЧи бенчмарк нормально работать не способен. На странице результатов http://3dmark.com/search можно увидеть, что нормальный fps достижим на системе из трёх ПЕЧей 480 и разогнанном Intel Core i7.

Просмотрел сейчас настройки Performance пакета и ошалел: паршивое разрешение 1280x720 без мультисемплинга и с трилинейной фильтрацией... И это еле ползает на топовых видеокартах! Пиздец.

DirectGL: linking and loading

2010-12-05T20:15:00.005+02:00

Взял Direct3D 9 версию нашего проекта. Поменял файлы заголовков d3d на свои, подменил сдкейные lib-ы на зависимость от directgl, подпилил некоторые зависимости D3DX... И вся эта махина стартанула!!!

Начали трейситься вызовы, создался девайс Direct3D, swap chain, наперечислялись форматы и видеорежимы. Пошла загрузка уровня: создались вершинные декларации (кхм, как BLENDINDICES портировать?), 2D-текстуры, вершинные и индексные буферы, шейдеры (для них я пока сделал заглушку). В итоге упало на попытке чего-то отрисовать :)

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

Update

Заставил загружаться в память игровой уровень. Это на самом деле просто, т. к. все ресурсы, которыми оперирует растеризатор, складываются из VB/IB, DXT-текстур, рендер таргетов и шейдеров (роль последних выполняет заглушка).

Интересно, что при заполнении текстуры через LockRect() во флагах обычно указывается 0, что означает, что мы можем как читать, так и писать по указателю. Чтобы только читать, можно указать флаг D3DLOCK_READONLY, но для заполнения нужно что-то вроде WRITEONLY. Можно было бы использовать usage D3DUSAGE_WRITEONLY при создании текстуры, но насколько я понял, этот флаг применяется только к (вершинному) буферу. В общем, для первого (и обычно единственного) lock-а приходится копировать данные из текстуры в PBO, а затем мапить буфер. Я рещил, что можно избежать этого шага, если хранить флажок bDirtyMip=true для текстуры, и на первом lock-e не копировать данные, а просто делать discard пиксельного буфера. После UnlockRect() флажок выставляется в false.

Если данные в текстуре всё равно невалидные и там мусор, то какая клиенту разница, чей это мусор: текстурный или буферный?

Нецензурщина

2010-12-05T18:08:00.002+02:00

Каюсь, грешен.

Применил в коде goto, для удаления ресурсов при возникновении ошибки. Знаю, что это почти как мат, но без него придётся либо многократно дублировать код удаления, либо использовать исключения. Первое чревато, а второе не разрешено.

Корпоратив

2010-11-24T19:24:00.003+02:00

Недавно ели вкусный торт, приуроченный к годовому корпоративчику:

DX9 game port

2010-11-22T18:09:00.002+02:00

Вот и обещанный порт маленькой DX-игры:

Она использует минимум фич рендера, понадобилось реализовать только интерфейс ID3DXSprite. Его реализацию я нагло выдрал из Wine, сверяясь с описанием в DirectX SDK. Не реализован lockable back buffer, в который рисуются звёзды и выхлопы двигателя корабля, т. к. в OpenGL отсутствуют lockable buffers. Позже, думаю, для развлечения можно будет использовать pixel buffer object, но это полумеры, да и в крупных проектах не используется (разве что для редактора).

Также сделал наброски pure device, в виде наследника основного device. В pure device отсутствуют проверки на возможные ошибки в time-critical частях кода, чем сейчас изобилует основой device.

P. S. Wine штука интересная, время от времени я буду сверяться с ним в случае затруднений при портировании.

Update

Реализовал lockable back buffer. Для этого пришлось написать класс swap chain-а и усложнить логику создания render target - теперь он может быть текстурой, если lockable, и рендербуфером, если нет (а если задан мультисемплинг - только им). На ATI опять отгрёб проблемы, на этот раз с PBO - первый lock/unlock работает только первые три кадра, затем текстура не обновляется. Повторный даёт результат, поэтому я пока вставил затычку с пустым первым lock/unlock. На GeForce этой проблемы, как и ожидалось, нет.

Также заработал мультисемплинг и переход в fullscreen режим.

DirectGL progress

2010-11-18T19:46:00.003+02:00

Спортировал ещё несколько демок. С ростом codebase это становится всё проще и проще.

Следующий шаг - портирование на OpenGL небольшой DX9-игры с codesampler.com. Также я взял на вооружение исходники Wine, интересно посмотреть, как они реализовали некоторый функционал.

Затем в качестве пробы пера - компоновка с игровым проектом, над которым мы работаем сейчас. Попробуем хотя бы собраться, а дальше - попытка инициализация device, переход в fullscreen, создание ресурсов. Этого будет достаточно, чтобы признать задумку годной к использованию в следующем проекте.

DirectGL progress

2010-11-13T12:28:00.005+02:00

Спортировал ещё одну демку, которая показывает принцип фильтрации MIP-уровней видеокартой:

На codesampler.com есть OpenGL аналог этой D3D9-демки. Там mip-уровни загружаются через glTexImage2D(). Мне необходимо было спортировать функцию D3DXLoadSurfaceFromSurface(), которая, как я подозреваю, вызывает внутри ::StretchRect(). Этот API может нести на себе расширение GL_EXT_framebuffer_blit, которое я и использовал при портировании. Но что-то не заладилось у меня на ноутбуке: нулевые MIP-уровни source текстур не хотели блититься в подходящие MIP-уровни dest текстуры. Вернее, blit шёл всегда в нулевой MIP, как будто бы параметер level игнорируется. Я долго провозился с кодом, но так ничего толкового и не придумал.

Сегодня решил для пробы проверить на стационарном PC с GTX 260 - и всё заработало как надо. Это опять глючит GlukoGL, теперь на ATI :(.

Update

Нашёл причину бага на ATI: нужно включить mipmap фильтрацию для текстуры, если хотим блитить в mip-уровень больше 0. Маразм.

Atonement

2010-11-10T10:31:00.005+02:00

Вчера посмотрел этот фильм.

Удивительно, как я его пропустил и не посмотрел раньше. Это фильм о 13-летней девочке, которая из-за своей глупости и ревности не могла (или не хотела) отличить похоть от любви, а пошлость от страсти, и этим разрушила счастье двух молодых людей. Когда девочка стала 18-летней девушкой, она осознала, что натворила, но ничего исправить уже было нельзя. Она дожила до глубокой старости, неся эту боль внутри и не имея возможности избавиться от неё...