DirectX 8. Начинаем работу с DirectX Graphics

Прежде всего, нужно ориентироваться на блочную структуру, организации сцены. То есть нужно стараться, чтобы у вас были готовые небольшие локальные кусочки поверхности, которые вы можете рисовать отдельно. При этом, конечно, не стоит забывать, что по скорости рисовать два фрагмента по 400 треугольников ничуть не медленнее, чем рисовать два фрагмента по 200 треугольников. Поэтому размер фрагмента должен быть достаточно большим. При этом достаточно важно накладываемое требование на локальность кусочков. Наилучший вариант - это квадрат, но, к сожалению, квадратная организация фрагментов неоптимальна. Вы должны решить, что для вас в данный момент важнее, вывод поверхности максимально быстро или у вас есть какие-нибудь другие приоритеты (например, организовать квадратную фрагментацию гораздо проще). Дело в том, что вы будете использовать кэш видеокарты только при короткой длине линии (до восьми вершин). Вы должны захватить как можно больше вершин в кэше при обратном проходе (за счет этого можно практически вдвое увеличить скорость вывода ландшафта). Никакой практической сложности при выводе ландшафта нет. Только нужно не забывать, что линии нужно соединять без лишних треугольников, поэтому между переходами приходится вставлять вырожденные треугольники (этот механизм используется для увеличения длины линии заданной через TriangleStrip). Такие вырожденные треугольники практически бесплатны, ведь трансформированные вершины в момент использования обычно уже находятся в кэше видеокарты, и даже если их там нет, то они будут выбраны из кэша при обратном проходе, а поскольку они вырождены, то рисуются они только одной линией. То есть нам получается значительно выгоднее нарисовать лишние треугольники, но не разрывать цепочку (несколько вызовов DIP c маленьким количеством треугольников обрабатываемом при каждом вызове). Естественно, что каждому фрагменту нужно ставить в соответствие две переменные — расстояние до центра и флаг видимости (которые можно вычислять любым способом, главное — чтобы было правильно :) ). Обычно вычисляют процессором, но, например, можно для этого использовать функцию ProcessVertices (которая для этого и была создана, она, правда тоже считает процессором, но, вроде как, использует SSE или 3DNow!).

Мы реализовали поверхность с некоторыми, иногда очень важными ограничениями. Например, текстурные координаты вершин общие для всех смежных треугольников, что не всегда удобно (можно, конечно, заставить поработать художников и тогда это не проблема :) ). Зато, это позволяет использовать обычные редакторы двумерной графики для редактирования ландшафта (карты высот), что, в общем, не очень важно, но что значительно важнее — это позволяет уменьшить объем файла ресурса (для сети это очень важно).

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

Тени могут быть заранее рассчитанными, либо считаться в реальном времени. Хороший вариант предложил Mircea Marghidanu в своей статье "Fast Computation of Terrain Shadow Maps" доступной по ссылке www.gamedev.net/reference/articles/article1817.asp. В своем классе я использовал именно подобный метод и, как он и просил, помещаю на него ссылку. Метод хорошо описан по-английски и я не вижу смысла повторять, то же что там уже сказано. Конечно, там приведена OGL реализация, но это не очень важно, как можно сделать под D3D вы можете посмотреть в исходниках. Ссылка на них есть в начале статьи. Конечно, для использования в реальном приложении метод нужно разделять (то есть обсчитывать в каждом кадре только небольшое количество точек, таким образом распределяя нагрузку на процессор). Кроме того, в реализации создается текстура для проективного текстурирования на объекты (которые, я надеюсь, появятся в следующей статье). Конечно, класс оставлять в том виде в котором он есть мы не можем. Поэтому к следующей статье нам необходим простенький редактор, позволяющий редактировать ландшафт в трехмерном виде. Он должен позволить задавать текстурные координаты треугольникам (а в случае Height-map, правильнее говорить "вершинам"), а также ставить в соответствие текстуры, которыми мы будем текстурировать конкретные треугольники. Свободное текстурирование ландшафта, так же как отсечение невидимых фрагментов ландшафта и вывод фрагментов в порядке Front-to-Back мы тоже рассмотрим в следующей статье.