Спалились

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

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



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

Multisample soft shadows

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

1x

4x

1x

4x

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

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

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

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

Transformers 3

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

Не пишется

GL_EXTENSIONS

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

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

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