суббота, 30 октября 2010 г.

DirectGL

Первый для меня проект по портированию Direct3D-тайтла на платформу MacOS X близится к концу, а тем временем моя голова уже полна мыслей, как оптимизировать этот процесс для будущих проектов.

Наш render team набил достаточно шишек, пытаясь запустить D3D-flow через трубопровод GlukoGL, но, как известно, на ошибках учатся! Вообще всё очень зависит от специфики проекта (скажем, гоночки с динамическим стримингом мира vs статическая загрузка, ARB-шейдеры vs GLSL), но тем не менее, можно выделить несколько задач, реализация которых облегчит портирование Direct3D игр на Маc:

1) Исходный код рендера неприкосновенен настолько, насколько это возможно. По сути, я подумываю написать статическую библиотеку, которая будет внешне мимикрировать Direct3D, а внутри транслировать все вызовы в команды GlukoGL. Нам необходимы по сути лишь несколько основых классов: Vertex/IndexBuffer, Query, VertexDeclaration и Device, чтобы получить картинку в wireframe, а дальше уже отлаживать шейдинг и остальные прибамбасы. По сути весь Device в нынешнем проекте писал и оптимизировал я, так что его Direct3D-like реализация уже имеется. Идея состоит в том, чтобы не просто сделать like-реализацию, а написать полную Direct3D-оболочку, внутри которой либо портировать функционал, либо делать stub-овые методы, в зависимости от условий проекта. Тогда код рендера практически не придётся трогать.

2) Жёсткий контроль за render states. Необходимо написать render state dumper, который будет опрашивать API на предмет всех мыслимых стэйтов и выводить их в файл/консоль. Тогда можно будет легко контролировать весь поток рендеринга, делая дампы стэйтов:

void SomePass::Render()
{
DumpRenderStates("begin.txt");

// a lot of render code here...

DumpRenderStates("end.txt");
}

Cравнивая дампы в Direct3D и GlukoGL рендерах, можно легко отлавливать закравшиеся баги. Если какой-то стэйт потерян - останавливаемся и ищем ошибку. Полное соответствие всех стэйтов на всём протяжении отрисовки кадра здорово уменьшит нашу головную боль с отладкой.

3) Viewport Y-Axis Inversion.

Решать единообразно. Скажем, домножать .y компоненту вершины на -1 в вершинном шейдере после преобразования MVP матрицей. Тогда проблема инверсии оси Y нивелируется и при сэмплировании получившейся текстуры можно не возиться с текстурными координатами. Или, как вариант, подправить саму матрицу, чтобы не тратить команду шейдера.

6 комментариев:

  1. А что за проект, если не секрет? Если секрет то не забудь хоть похвастаться когда зарелизитесь:)

    ОтветитьУдалить
  2. Говорить об этом до релиза - нежелательно :)

    ОтветитьУдалить
  3. Почему OGL, Вы называете GlukoGL'ом?
    Просьба ответить, мнение специалиста для меня
    будет очень важным. =)

    ОтветитьУдалить
  4. А можно поподробнее, хотя бы несколько пунктов. =)

    ОтветитьУдалить
  5. Конкретно сейчас я вожусь с багом OpenGL, который приводит к зависанию Mac OS X на некоторых конфигурациях. Также есть проблемы с падением внутри драйвера и т. д. Ещё куча проблем с bindable uniforms, больших vertex/index buffers и т. д.

    ОтветитьУдалить