AndreyGL/D3D

Software Occlusion Culling

2010-01-10T08:57:00.000-08:00

Как известно, в сложных сценах могут возникнуть ситуации, когда объекты могут загораживать другу-друга. В этом случае, алгоритм Frustum Culling будет давать положительные результаты о видимости объектов, независимо от того загораживают они друг друга или нет.

Естественно, рендеринг большого числа загороженных объектов будет снижать быстродействие. Для решение данной проблемы используется алгоритм Occlusion Culling. Одна из реализаций алгоритма которая поддерживается аппаратно это Occlusion Query. Большим недостатком данного метода является то, что результат теста будет получен не сразу, а только после завершения работы видео карты, вызывая простои процессора(CPU Stall). Для решения данной проблемы используются несколько подходов, таких как иерархия запросов, получения результата через n-кадров, предсказания запросов и другие реализации. Для аппаратной реализации нужно рисовать упрощенную геометрию и ограничивающий объем объектов для тестирования. Это требует дополнительных вызовов графических API и дополнительных Render Target'ов,что в добавок ко всему усложняет реализацию. Отличная реализация алгоритма с аппаратной поддержкой описана тут: Hardware Occlusion Queries Made Useful.

Я попробовал получать результаты через n-кадров, объекты мигали, результат меня не удовлетворил, не став больше экспериментировать я попробовал использовать софтварную реализации алгоритма.

Одним из способов софтварной реализации является построения Viewing Frustum по ограничивающему боксу объекта. Все объекты, полученные после обхода Scene Graph и отсортированные по расстоянию до камеры, полностью попадающие в Frustum, без пересечений с его плоскостями, будут считаться невидимыми, и должны быть выкинуты из списка видимых.
Недавно мне порекомендовали еще более простой способ определения того что один объект полностью закрывает другой. Способ заключается в проверки спроецированных на плоскость экрана ограничивающих боксов объектов на полное попадание друг в друга. На данной реализации я и остановился.
Сначала я написал функцию проецирования точки на экран, заодно пополнив математическую библиотеку движка.
Проанализировав проекцию бокса на плоскость:

Стало видно, что точки 4 и 2 внутренние и должны быть выкинуты:

Таким образом, результатом проекции будет замкнутый шестиугольник.
Если ориентация бокса к камере под прямым углом, то дальние точки после проекции будут совпадать с передними, в этом случае результат проекции будет четырехугольник.Теперь можно
составленный список точек проекции бокса тестируемого объекта, проверять на попадание в замкнутую область проекции бокса закрываемого объекта. Тут подходит общеизвестный алгоритм нахождения точки внутри многоугольника.
Небольшая демка показывающая как это все работает.
Следует заметить, что не все объекту могут полностью закрыть другие. Сам объект должен быть непрозрачным. Обычно такой объект называют Occluder'ом, задавать такие объекты можно при разработке уровня. Геометрия объекта, который может полностью закрыть другие, должна быть сплошной, его ограничивающий бокс должен быть максимально к ней приближен, если это не так, то следует задавать так называемые Occlusion Box'ы. К примеру для дерева нужно задать Occlusion Box ствола, но наверняка это будет не эффективно. Ведь площадь проекции ствола дерева в большинстве случае мала, и мало объектов будет отброшено за стволом. Идеальным кандидатом будет к примеру дом.

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

Occlusion Culling on, отброшено 243 объекта, FPS 37.

Occlusion Culling off, FPS 30.

Occlusion Culling on, отброшен 71 объект, FPS 41.

Occlusion Culling off, FPS 35.

Как видно в некоторых случаях производительность можно поднять, особенно на сложных сценах, к примеру город, или если есть сложные объекты которые будут закрыты.

Multithreading in OpenGL API

2009-10-16T06:21:00.000-07:00

Как известно, OpenGL имеет некоторые неудобства для работы в разных потоках, по сравнению с Direct3D. Сам недавно столкнулся с этими неудобствами на платформе Windows.
Согласно документации MSDN, для каждого потока в котором будет работа с OpenGL API, должен быть свой текущий контекст рендеринга, установку текущего контекста
осуществляется с помощью функции wglMakeCurrent.
Если это не так, то при любом обращении к функциям OpenGL API будет ошибка GL_INVALID_OPERATION, ну а дальше нарушенный доступ к памяти и далее поведение
программы не определено.
Для решения этой проблемы, нужно создать для нового потока новый контекcт воспроизведения, используя функцию wglCreateContext.
В качестве контекста окна можно передать контекст окна приложения, хотя по некоторым советам, следует создать дополнительное маленькое окно размером 1x1 пиксель.
Хотя у меня работало и без дополнительного окна. Далее, нужно что-бы все изменения между потоками были известны друг другу. К примеру, создается
текстура, вершинный или индексный буфер и т.д. в одном потоке, а использоваться будет в другом. Осуществить это нужно с помощью функции wglShareLists,
причем тут дисплейные списки в описании функции я не знаю.
Лучше сделать расшаривание контекстов друг на друга, хотя все зависит от задачи, т.е. если есть к примеру есть load_context и render_context, которые используются в потоке загрузки и рендеринга соответственно, то пара вызовов:
wglShareLists(load_context, render_contex);
wglShareLists(render_contex, load_context);
обеспечат видимость изменений между этими потоками.
В случае неудачи вызова wglShareLists у меня GetLastError возвращает ошибку, строковое соответствие полученное через FormatMessage было таким:
"невозможно создать файл так как он уже существует", почему это так, для меня загадка.
При завершении каждого потока нужно не забыть освободить связанный с ним контекст.

Различные доработки.

2009-07-08T13:12:00.000-07:00

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

Написаны реализации кубических и трехмерных текстур. Так-же в случае реализации рендера в текстуру для них.

Как известно, на сложных сценах рисуется много объектов. Если не применять инстансинг, то встает проблема минимизации числа вызовов рисования геометрии, имеется ввиду вызовы соответствующей функциональности в Direct3D9, Direct3D10 и в OpenGL: IDirect3DDevice9::DrawIndexedPrimitive, ID3D10::DrawIndexed, glDrawElements, glDrawRangeElements. Инстансинг стоит в планах, а пока для каждого объекта сцены ставиться вершинный и индексный буфер. Если объектов будет тысячи, на моей тестовой сцене это число уже больше, то число переключений вершинных и индексных буферов буферов будет снижать быстродействие. Возникла идея, собрать все меши имеющее одинаковый формат вершин в единый вершинный буфер, аналогично поступить с индексными. Это будет еще более актуально, если число объектов отличающихся по геометрической форме будет большим.
Вот некоторая статистика для сцены вместе с тенями для 1377 объектов, всего разных объектов для текущей сцены около 50:
Число переключений буферов в случае общих вершинных и индексных: 59, 58
Число переключений буферов в случае отдельных вершинных и индексных: 96, 84

Улучшилась работа профайла. Сделал усреднение времени по 10 кадрам, теперь значения не "прыгают". Фильтрация показа малых значений времени.

В файле описания уровня можно задавать Render Target'ы, привязанные к объектам сцены. Параметры, такие как размеры, формат пикселей, пишутся там-же. Если Render Target служит для отражения то указывается в параметре для какой плоскости это происходит. В таком случае при обходе Scene Graph'a, будет происходить сбор как самих видимых объектов, так и заполняться список видимых объектов для каждого заданного Render Target'а. Такой подход удобен для реализации отражений для моделирования воды, зеркал или еще чего нибудь. В данный момент реализовываю отражение в воде.

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

FastArray

2009-05-02T01:54:00.000-07:00

Сейчас очень много сделано в движке. Есть некоторые недоделанные реализации чего либо.
К примеру Hierarchy Occlusion Culling, обход SceneGraph для поиска объектов являющихся RenderTarget'ами вода, зеркала и т.д. Постепенно проводиться оптимизация движка. В частности замер профайлером работу отдельных функций. На данный момент есть частое добавление объектов в динамический массив в каждом кадре. Как для от рисовки в текстуру теней так и для поиска видимых объектов. Для этого использовался ранее обычный std::vector с заранее вызванным std::vector::reserve. Почитав пост известного всем IronPeter'а Банановые шкурки, я подумал что сам метод std::vector::push_back уж очень универсален, там есть проверка на текущий размер с выделением памяти при необходимости и много других вызовов. К примеру std::vector::operator [] очень быстрый, но лишен универсальности, к примеру проверка выхода за диапазон, для этого есть std::vector::at. Иногда возникает вопрос, почему разработчик STL Александр Степанов не добавил быструю реализацию push_back, назвав ее к примеру fast_push_back?
Для некоторых частных специфических задач, требующих минимальной загрузки CPU, проверять выход за пределы не нужно вообще, к примеру как в этом случае - быстрое добавление данных с инкрементом указателя, который смещается к концу масса, причем размер массива уже известен.
Поэтому я написал свою довольно простую реализацию FastArray унаследовав с защищенным доступом от std::vector. Реализация выглядит так:


#ifndef __FASTARRAY_H__
#define __FASTARRAY_H__

#include "exceptions.h"
#include <cassert>
#include <vector>

// Fast Dynamic Array
template<typename T>
class FastArray : protected std::vector<T> {
private:
  typedef std::vector<T> BaseClass;
  T* last;
public:
  typedef T* iterator;
  typedef const T* const_iterator;
  void resize(size_t count)
  {
    BaseClass::resize(count);
    last = &*BaseClass::end();
  }
  void reserve(size_t count)
  {
    BaseClass::reserve(count);
    last = &*BaseClass::end();
  }
  const_iterator end() const
  {
    return last;
  }
  iterator end()
  {
    return last;
  }
  const_iterator begin() const
  {
    return &*BaseClass::begin();
  }
  iterator begin()
  {   
    return &*BaseClass::begin();  
  }
  T& back()
  {
    assert(last && "NULL Pointer");
    assert(!empty() && "Empty Array");
    return *(last - 1);
  }
  const T& back() const
  {
    assert(last && "NULL Pointer");
    assert(!empty() && "Empty Array");
    return *(last - 1);
  }
  T& front()
  {
    assert(!empty() && "Empty Array");
    BaseClass::front();
  }
  const T& front() const
  {
    assert(!empty() && "Empty Array");
    return BaseClass::front();
  }
  bool empty() const
  {
    return &BaseClass::front() == last;
  }
  size_t size() const
  {
    assert(last >= &*begin() && "Out of Range");
    return static_cast<size_t>(last - &*begin());
  }
  size_t capacity() const
  {
    return BaseClass::capacity();
  }
  void pop_back()
  {
    assert(last && "NULL Pointer");
    assert(last >= &*begin() && "Out of Range");
    --last;
  }
  void push_back(const T& val)
  {
    assert(last && "NULL Pointer");
    *(last++) = val;
  }
  T& operator [] (size_t index)
  {
    assert(&*begin() + index < last && "Out of Range");
    return *(begin() + index);
  }
  const T& operator [] (size_t index) const
  {
    assert(&*begin() + index < last && "Out of Range");
    return *(begin() + index);
  }
  void clear()
  {
    last = &*begin();
  }
  FastArray(size_t count, const T& val = T()) : BaseClass(count, val), 
                        last(&BaseClass::back())
  {
    
  }
  FastArray() : last(&BaseClass::back())
  {
  }
  ~FastArray()
  {
  }
};

#endif

Такая реализация обеспечивает быстрое добавление в конец и очистку массива, так-же работу с итераторами. Единственным минусом является небезопасное добавление, если число элементов превышает длину массива.

Parallel Split Shadow Map тени.

2009-03-07T10:06:00.000-08:00

Наконец Внедрил Parallel Split Shadow Map в движок. Реализация основана на демке PSSM
Разбиения рассчитаны по логарифмической схеме logarithmic split scheme.
Было несколько ошибок: Дикие растяжения теней проблема из-за неправильного построения Crop Matrix, проблемы с глубиной, исчезновение объектов и листьев ландшафта.
Crop Matrix это некая матрица трансформации с масштабированием и смещением. Как раз она корректирует текущую матрицу проекции источника света подгоняя под ограничивающую область текущего сплита, для оптимального использования разрешения текстуры теней, избегая проблем алгоритма стандартных теней Shadow Map Aliasin g. Спасибо Арсению Капулкину(Zeux) за подсказку.
Вторая проблема была связана с рисованием объектов через FFP(что я планирую исправить на шейдеры по умолчанию) в Direct3D9/OpenGL при выключении шейдера на большом расстоянии, я просто не учел матрицу проекции для текущего split.
Третья проблема тоже простая, для видимого объекта ставился флаг видимости, и если он виден в текущем разбиении н не виден в предыдущем или последующем флаг сбрасывался и объект не рисовался.
Четвертая проблема еще проще, рисовался повторно ландшафт, затирая то, что уже отрисовано создавая эффект выпадания листьев.
Приведу несколько удачных скриншотов показывающих разницу между Parallel Split Shadowm Map и Standart Shadow Map. Скриншоты сделаны в режиме Direct3D9 рендера.

SSM

PSSM

SSM

PSSM

SSM

PSSM

SSM

PSSM

В процессе внедрения PSSM использовал подход в выставлении отладочного пиксельного шейдера, который выставляется для объектов текущего разбиения подсвечивая их красным цветом игнорируя текстуры и освещение. Спасибо Сергею Милойкову(Zemedelec) за предоставленный совет. Данная функциональность удобно включалась командой с консоли "debug_split i" - где i номер разбиения.
"debug_split -1" - отключал отладку.
Выглядит это вот так:

Split 0

Split 1

Split 2

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

Тени в OpenGL рендере. Прогресс и дальнейшие планы.

2009-02-20T10:08:00.000-08:00

Сначала я сделал тени для Direct3D 9. Потом переделал для OpenGL. Тени работали, но отличались в OpenGL по сравнению Direct3D в худшую сторону. Эту задачу я отложил до лучших времен. Иногда к ней возвращался но так и не мог понять в чем дело. Реализация у меня была с использованием рендера в текстуру и с использованием расширений GL_ARB_vertex_program и GL_ARB_fragment_progra m. (Код получен как результат компиляции Cg компилятором.)На данный момент частично используется GLSL полученный как результат компиляции из Cg.Сначала я думал что проблема в проблема была в использовании или инициализации рендера в текстуру с использованием GL_EXT_frame_buffer_object в связке с текстурами с плавающей точкой через расширение GL_ARB_texture_float. Но вскоре выяснилось что я немного неправильно построил матрицу источника света и матрицу текстуры. Теперь тень пиксель в пиксель совпадает с Direct3D.

OpenGL:

Direct3D:

В общем я решил пока не удалять OpenGL рендер из движка. Не так все плохо. Но еще есть проблемы на ATI.

На данный момент добавил рендер всей сцены в глубину. Результат сохраняется в float текстуру. Используя это эту возможность расширил в связи с этим менеджер постропцессинга, который может использовать эту текстуру. К примеру к примеру на основании этого реализовал эффект постпроцессинга Dof - Depth of Filed. Спасибо за переработанный шейдер из различных SDK Глебу Гущину(innuendo), а помощь в исправлении расчета преобразования глубины Арсению Капулкину(Zeux).
На данный момент идет улучшение теней с использованием алгоритма
Parallel Split Shadow Map.

В дальнейших планах исправление ошибок. Сейчас их накопилось много. Есть серьезные, а есть просто много мелочей. Параллельно буду писать редактор. Пусть пока простой - расстановка объектов, cохранение и загрузка.

Передача констант в шейдеры.

2009-01-17T10:54:00.000-08:00

Всем известно что передавать константы лучше все сразу, а не по отдельности, либо минимизировать эти вызовы.
Достичь это можно несколькими путями и по разному для каждого API. Опишу отдельно для Direct3D9, Direct3D10, OpenGL.
Для Direct3D9 лучше Не использовать ID3DXEffect для шейдеров, не использовать ID3DXConstantTable для установки констант. Они не несомненно удобны но не очень быстрые в работе. Почему сейчас расскажу.
Возьмем любой метод ID3DXEffect/ID3DXConstantTable для установки констант. Все они имеют параметр D3DXHANDLE - это либо строка либо указатель возвращаемый
другими методами. Напрашивается вопрос как значение этого параметра внутри распознается. Внутри это может быть либо свой указатель либо строка с именем константы.
Что конкретно определяется проверкой установленного старшего бита параметра, если установлен то HANDLE, если нет то строка. Таким образом, мы имеем некие потери при установки константы. При чем внутри таких вызовов будут еще и проверки. Если это строка то будет поиск по строке, пусть даже через Hash. В случае с указателем чуть быстрее. Итого, представив много шейдера на сложной сцене, с большим числом констант, которые еще что хуже всего передаются по имени через строку.
В данных интерфейсах есть средства для засылки констант группой, за справкой отсылаю к DirectX SDK. Но нет средств что-бы заслать все константы для всего шейдера разом, что по идее должно быть идеально. Что бы слать все, лучше использовать напрямую интерфейсы IDirect3DPixelShader9/IDirect3DVeretxShader9 и использовать методы:
IDirect3DDevice9::SetPixelShaderConstant*/IDirect3DDevice9::SetVertexShaderConstant*
при таком подходе можно заслать единообразно все константы определенного типа за 1 вызов начиная со стартового регистра. Причем ID3DXConstantTable/ID3DXEffect являются wrapper'ами над этими методами.
Для Direct3D10 все намного проще. Есть константные буферы которые и предназначены для передачи группы констант. Кроме того данная функциональность есть в ID3D10Effect интерфейсе.
К сожалению в OpenGL с этим немного похуже ситуация. В расширениях GL_ARB_fragment_program/GL_ARB_vertex_program есть функция glProgramLocalParameter4fvARB, но она не позволяет слать больше 4 float(1 регистр).
Можно использовать для матриц константы GL_MATRIX0_ARB - GL_MATRIX31_ARB
и передавать через glMatrixMode это чуть улучшает ситуацию. Недавно я использовал новое расшерение GL_EXT_gpu_program_parameters оно позовляет засылать константы пачками. Причем это прямой аналог передачи констант для Direct3D9. Радует поддержка расширения на ATI.
Для GLSL передавать все константы для шейдера за 1 вызов не получится. Потому что нет у порядочности хранения uniform переменных. И функции для передачи параметров могут передавать либо матрицу либо vector4 и т.д. Можно передать матрицы 1 вызовом но их нужно хранить в массиве. Но с появлением расширения GL_EXT_bindable_uniform ситуация улучшилась но оно поддерживается пока только nVidia картами.

Lod'ы шейдеров в Direct3D10 и отсутствие FFP

2008-11-13T13:51:00.000-08:00

Привел от рисовку объектов при Direct3D10 рендере в порядок. Теперь они не исчезают при большом расстоянии от камеры.
В движке есть понятие Lod для шейдеров. С каким-то шагом можно задавать более сложные шейдеры для объектов. Это дает прирост производительность на старом железе(а может и на новом). К примеру возьмём дерево, которое анимируется на ветру вершинным шейдером, в шейдере есть тригонометрическая функция для нее генерируется достаточно много инструкций, очевидно дерево можно не анимировать с очень большого расстояния, в этом случае включится простой шейдер, просто трансформирующий вершину. Другой пример - нет смысла делать эффект бампа и освещения на большом расстоняии - можно ограничится диффузионным освещением или вообще без него. Конечно переключение возможно будет заметно. Аналогичная ситуация с анимацией травы. Можно сделать лоды для скелетной анимации. Но там более сложные параметры.
В случае OpenGL/Direct3D9, если не будет найден подходящий лод, то будет выставлены NULL шейдеры, т.к. для них есть фиксированный конвейер то можно вызвать IDirect3DDevice9::SetTransform(world) и glLoadMatrixf(worldViewMatrix). Для Direct3D10 в этом случае не будет ничего рисоваться. Я решил эту проблему таким образом. Для каждого формата вершин создал список шейдеров по умолчанию. В случае выставления NULL шейдера, будет браться шейдер по умолчанию, если есть вершинный буфер.
Это простое и удобное решение. Не нужно дополнительных шейдеров, тем более шейдера по умолчанию простые и короткие, поэтому их код хранится прямо в реализации класса рендера движка. Для шейдеров с альфа тестом, есть дополнительный список шейдеров по умолчанию для каждого формата, само собой с параметром - текущий AlphaRef, тут имеется ввиду значение, передаваемое в IDirect3DDevice9::SetRenderState(D3DRS_ALPHAREF, AlphaRef) в Direct3D9 и в glAlphaFunc(func, AlphaRef) в OpenGL. В Direct3D10 убран альфа тест из FFP, поэтому нужен такой параметр по которому делается discard.
Таким образом объекты перестали исчезать.

Добавлен встроенный профайл

2008-11-10T22:18:00.000-08:00

Добавил в движок встроенный профайл. По очень простой схеме,
некий класс содержащий данные о текущей строке имени файла и имени функции. Этот класс имеет конструктор с такими параметрами. С помощью макроса
#define PROFILE Profile::ProfileData data(__FILE__, __LINE__, __FUNCTION__);
можно в начале любой функции добавлять отсчёт времени. В конструкторе запоминается стартовое время работы. В деструкторе формируется строка в виде "File, line, function, time"
и рассчитывается время работы функции, данные добавляются с список. Все банально и просто. Нужно ещё решить как-то проблему мигания значение цифр, что происходит из-за разброса значений времени.

Объединение одинаковых пересекающихся объектов на сцене.

2008-11-06T12:34:00.000-08:00

При сильно загруженной сцене бывает очень много вызовов от рисовок геометрии, всем известными под названием DIP (IDirect3DDevice9::DrawIndexedPrimitive для Direct3D9, glDrawElements для OpenGL и ID3D10Device::DrawIndexed для Direct3D10). Большое количество таких вызовов может нанести серьезный удар по быстродействию рендера, особенно это более актуально для Direct3D 9, именно в в момент вызова идет проверка на валидность пиксельного и вершинного шейдера, правильная линовка данных передаваемых из вершинного в пиксельный, проверка вершинных деклараций на соответствие того что использует вершинный шейдер и что находится в вершинном буфере, так-же индексы вершин и остальные параметры. В OpenGL все намного проще, после выполнения каждой функции может возникнуть ошибка. Таким образов время как-бы равномерно распределяется между всеми вызовами функция перед вызовом от рисовки.
Ну в Direct3D 10 DIP cost значительно снижен.
Так-же частые вызовы может серьёзно нагрузить CPU по вызовам функций. Обычно до 1000 DIP на кадр ещё не все так плохо.
Итак при загрузки сцены я сделал некую простейшую оптимизацию, ищем объекты с одинаковы мешами и если они пересекаются своими ограничивающими боксами, собираем их в 1 мешь с учтя матрицу трансформации. Что это дает?
1) уменьшение нагрузки на CPU при обходе Scene Graph и при сортировке объектов;
2) уменьшение DIP cost при отриcовке в Depth текстуру для теней;
3) уменьшение DIP cost при финальной от рисовке объектов;
Минусы в том что будет небольшой перерасход памяти. Но если к примеру у меня на сцене дерево ели имеет 350 полигонов и их несколько сотен, то объедение по 3-4 в 1 мешь будут значительно сокращать DIP cost. Пока тесты особых положительных результатов не дали но число DIP и число объектов в кадре значительно сокращены в грубом приближении на 30% в среднем. Повышение FPS вроде не более 10%. Буду тестировать на более слабом железе. На будущее конечно нужно подумать об использовании Instansing'а. Железо сейчас c такой функциональностью уже достаточно доступно и инстансинг есть уже в 3 API в том числе и поддержка у ATI для OpenGL.

Подгонка шейдеров под все графические API

2008-10-31T12:59:00.000-07:00

Пока Direct3D10 рендер ещё сырой, иногда возвращаюсь к нему и постепенно дописываю.
Cейчас избавился в движке от OpenGL state(передаю матрицы трансформаций напрямую) .
Когда он был заменял макросы на соответствующие параметры при компиляции из Cg в GL_ARB_vertex_program. Код GLSL полученный из Cg не содержит GL state - видно nVidia сразу продумала это на будущее как deprecated функциональность.
При использовании этих макросов компилятор HLSL для Direct3D10 почему-то неверно распределял регистры в отличие от компилятора HLSL Direct3D9. Я пока не стал разбираться с этим, а временно скинул и переписал шейдеры специально для Direct3D10. Немного переписав шейдеры и добавив системный макрос D3D10 я избавился отлишней папки с шейдерами для Direct3D10.Настало время разобраться с использованием Cg для Direct3D10.

Добавлена оптимизация перемножения матриц через SSE

2008-10-22T21:55:00.000-07:00

Добавил в движок поддержку SSE в частности для перемножения матриц 4x4, 4x3. Написал аллокатор для STL std::vector выделяющий память, выровненную по границе 16 байт. Используются функции _aligned_malloc,_aligned_free. Большое спасибо Арсению Капулкину(Zeux) за исправленный код.

Разработка 3D движка

2008-10-03T14:43:00.000-07:00

Итак, постепенно сюда буду писать прогресс разработки собственного трехмерного движка. Этой идеей уже сейчас никого не удивишь. Очень много людей пытаются написать 3D движок.
Целью разработки прежде всего является желание стать профессиональным программистом.
Разработка происходит в свободное время, временами с перерывами и ненормированным графиком(2-3 часа в день в среднем) и начата довольно давно где-то в конце 2004 года. В общей сложности общее время плотной работы 2 года. Одновременно с движком изучался С/C++ 3D графика и остальные смежные области, так и программирование в целом. Особого плана работы не было. Делалось то что получалось постепенно расширялась функциональность, проводилась оптимизация, улучшение архитектуры. Некоторые ошибки, недочёты, до сих пор не исправлены, Причины тут разные: либо отсутствие времени, опыта, или желание улучить то что по силам в данный момент, вернувшись к тому что поправить/доработать сложней. Движок не претендует на полноту и совершенство т.к. все понимают задача эта нетривиальная. Итак опишу что сейчас сделано и реализовано:
I. Не графическая функциональность
1) Физика: гора неработающего кода на Tokamak в дальнейшем будет выкинут и заменен на Ageia PhysX. Есть базовая функциональность. позволяющая в будущем добавить физическую библиотеку
2) Звук на основе библиотеки OpenAL с потоковой загрузкой ogg(libvorbis) и mp3(libmad),
3D звук(требует тестирования)
3) Поддержка Lua скриптов с доступом из скрипта нескольких переменных что позволяет ка минимум менять анимацию, реализовывать слежение за камерой, Debug Log у консоль из скриптов
4) Консоль - незаменимое средство отладки диагностики и управления движком от перезагрузки ресурсов до смены текущего рендера. Является так-же средством просмотра лога в реальном времени изменения/переключения режимов работы движка и смены рендера.
5) Самый начальный уровень сети инициализация сокетов Брекли создание сервера и клиентов. Посылка данных.(требуется доработка)
6) Защита от фатальных ошибок(целочисленное деление на ноль, нарушенный доступ к памяти), протоколирование работы, c записью Dump'а памяти на диск.
7) видео проигрыватель на основе theora;
8) файловая система с поддержкой zip;
II. Графика
1) Поддержка Direct3D9/Direct3D10/OpenGL. Смена рендера возможно командой консоли changerender 0(1)(2) где параметр тип рендера.
2) поддержка шейдерных языков HLSL/Cg/GLSL(из Сg кода)
3) Shadow Map тени с само затенением.(Standart Shadow Map) - в данный момент ведется улучшения теней посредством алгоритма Parallel Split Shadow Map.
4) попиксельное освещение.
5) Свой формат шейдеров(описание шейдера + константы) с менеджером шейдеров, Гибкая возможность задания констант, не изменяя код движка, прямо в файле
6) Свой формат материалов на основе идей из RenderMonkey и Ogre.

7) Гибкая система частиц с набором неограниченного числа различных независимых эмиттеров со своим набором аффекторов. + сохранение/загрузка из файла с менеджированием.
8) Иерархическая организация сцены в виде Scene Graph.
9) Поддержка динамических объектов в Scene Graph.
10) Frustum Culling(Оптимизированая проверка Box'а всего по 2 точкам)
11) Occluision Culling(Software, ведутся исследования для реализации Иеррахического Occlusion Query HQQ)
12) Рендер множества объектов(как в виде генерации мешей, на площади или текстурированных прямоугольников(плашек), в данный момент используется для редера растительности)
13) Свой формат статических моделей;
14) Скелетная анимация + свой формат моделей;
15) Морфичная анимация + свой формат моделей;
16) Рендеринг ландшафта с использованием технологии "Chunked Lod"(требует заделывания щелей между лодами);
17) Задание отсечения объектов по дистанции;
18) Задание альфа теста по дистанции;
19) Лоды для шейдеров(возможно требует доработки)
20) Менеджер полно экранного постпроцессинга с загрузкой описания постпроцессинга из файла. (Bloom, Depth of Filed)

Из тулзов разработан редактор системы частиц, экспортер скелетной
и морфичной анимации из 3DS Max, экспортер статических мешей.

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

Код писался на C/C++. В коде отсутствуют глобальные переменные и функции(кроме WinMain) Используется STL/boost(boost::any, boost::shared_ptr). Код по возможности писался кросплатформенным. Движок гарантированно компилится на Microsoft Visual C++ 2005/2008, Intel C++ 10.x, gcc(MinGW) с последним компилятором возникли проблемы при компиляции Direct3D10.

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

Cg 2.1 Beta

2008-08-14T21:29:00.001-07:00

Вышел Cg 2.1 Beta. Очень радует поддержка Direrct3D10. Не так давно спрашивал про это у nVidia разработчиков, ответили не планируется пока поддержки. Компилятор свой для Direct3D10 они не писали что тоже радует, не будет ошибок и несовместимостей. для компиляции используют функцию D3DX10CompileFromMemory, для получения всех констант используется D3DX10ReflectShader. Не совсем понятно почему результат cgGetProgramString(cgProgram, CG_COMPILED_PROGRAM); выдает hlsl код опять с измененными именами констант, точка входа именуются "main" Вот к примеру результат компиляции:
// hlsl10v output by Cg compiler
// cgc version 2.1.0009, build date Aug 6 2008
// command line args: -q -profile vs_4_0 -entry VSmain -profileopts -d3d
//vendor NVIDIA Corporation
//version 2.1.0.9
//profile vs_4_0
//program VSmain
//semantic ViewProjMatrix : WorldViewProj
//semantic MatTexture : C4
//semantic tex1 : TEXUNIT0
//semantic tex2 : TEXUNIT1
//semantic ShadowMap : TEXUNIT2
//var float4x4 ViewProjMatrix : WorldViewProj : _ZZ2SViewProjMatrix[0], 4 : -1 : 1
//var float4x4 MatTexture : C4 : _ZZ2SMatTexture[0], 4 : -1 : 1
//var sampler2D tex1 : TEXUNIT0 : : -1 : 0
//var sampler2D tex2 : TEXUNIT1 : : -1 : 0
//var sampler2D ShadowMap : TEXUNIT2 : : -1 : 0
//var float4 Pos : $vin.POSITION : POSITION : 0 : 1
//var float2 texCoord : $vin.TEXCOORD0 : TEXCOORD0 : 1 : 1
//var float4 VSmain.Pos : $vout.POSITION : : -1 : 1
//var float2 VSmain.texCoord : $vout.TEXCOORD0 : : -1 : 1
//var float4 VSmain.shadowCrd : $vout.TEXCOORD1 : : -1 : 1

#pragma pack_matrix(row_major)

struct VS_OUTPUT {
float4 Pos : POSITION;
float2 texCoord : TEX0;
float4 shadowCrd : TEX1;
};

struct X1X {
float4 POSITION : SV_Position;
float2 TEX0 : TEX0;
float4 TEX1 : TEX1;
};

float4 _ZZ3SrZh0001;
float4 _ZZ3SrZh0003;
X1X _ZZ3SZDcout;
uniform float4x4 _ZZ2SViewProjMatrix : WorldViewProj;
uniform float4x4 _ZZ2SMatTexture : C4;

// main procedure, the original name was VSmain
X1X main(in float4 _ZZ4SPos : POSITION, in float2 _ZZ4StexCoord : TEX0)
{

VS_OUTPUT _ZZ4SOut;

_ZZ3SrZh0001 = _ZZ4SPos.x*_ZZ2SViewProjMatrix._11_12_13_14;
_ZZ3SrZh0001 = _ZZ3SrZh0001 + _ZZ4SPos.y*_ZZ2SViewProjMatrix._21_22_23_24;
_ZZ3SrZh0001 = _ZZ3SrZh0001 + _ZZ4SPos.z*_ZZ2SViewProjMatrix._31_32_33_34;
_ZZ3SrZh0001 = _ZZ3SrZh0001 + _ZZ4SPos.w*_ZZ2SViewProjMatrix._41_42_43_44;
_ZZ4SOut.Pos = _ZZ3SrZh0001;
_ZZ3SrZh0003 = _ZZ4SPos.x*_ZZ2SMatTexture._11_12_13_14;
_ZZ3SrZh0003 = _ZZ3SrZh0003 + _ZZ4SPos.y*_ZZ2SMatTexture._21_22_23_24;
_ZZ3SrZh0003 = _ZZ3SrZh0003 + _ZZ4SPos.z*_ZZ2SMatTexture._31_32_33_34;
_ZZ3SrZh0003 = _ZZ3SrZh0003 + _ZZ4SPos.w*_ZZ2SMatTexture._41_42_43_44;
_ZZ4SOut.shadowCrd = _ZZ3SrZh0003;
_ZZ4SOut.texCoord = _ZZ4StexCoord;
_ZZ3SZDcout.POSITION = _ZZ4SOut.Pos;
_ZZ3SZDcout.TEX0 = _ZZ4SOut.texCoord;
_ZZ3SZDcout.TEX1 = _ZZ4SOut.shadowCrd;
return _ZZ3SZDcout;
} // main end
Ну на самом деле данный код не планируется подсовывать D3D10CompileShader проще сделать все стандартно
взять ID3D10Blob* из cgD3D10GetCompiledProgram и самому создать шейдер миную Cg RunTime, точно так-же как я сделал в случае использования Cg в OpenGL для профилей
Direct3D9, и OpenGL (glslv,glslf,arbvp1,arvfp1).
В общем можно встраивать это в движок

Начал вести блог

2008-08-06T11:49:00.000-07:00

Ну вот подключил я себе интернет, чувствую себя в цивилизации. Сюда буду иногда выкладывать свои работы. Ну и высказываться.
Итак 1 из первых тестовых проектов на OpenGL. Тут я разбивал геометрию на патчи и строил Octree дерево. Это был 1 из первых алгоритмов реализованных мной с нуля. Вот демка для скачивания,требует поддержки расширения GL_ARB_vertex_buffer_objects.
Вот пара скриншотов: