не подскажите как рассчитать глубину(depth) в Shaders.

2ReaVeR:
Похоже, что не просто опечатка

>> v = -m*v
Так это была не просто очепятка в книге?

Потом, у меня не получается наладить гравитацию в вашем Arwen. Помогите пожалуйста.

Спасибо,
если под инвертированием v Вы имеете в виду
v = -m*v
то так действительно будет правильно.

Уважаемый Алексей Викторович.
Кажется, я нашел у Вас в книге "Графика трехмерной компьютерной игры..." и, соответственно, в исходниках ошибку
Файлы Transform2D.h и Transform3D.h:
Transform2D& invert ()
{ m.invert ();
v = m * v;
return *this;
}
Разве здесь не нужно инвертировать и вектор v?

2Step-Pan:
Проверьте, нет ли у Вас в include и lib каталогах компилятора файлов от старых версий DirectX
У MSVC 6 проблема именно в этом.
В DX9все это есть, можете посмотреть их примеры

DirectX я подключил, но сейчас выдается сообщение при линковании:
DirectXInputReader.obj : error LNK2001: unresolved external symbol _c_dfDIMouse
И аналогичное для _с_dfDIKeyboard и _DirectInput8Create@20
Подскажите, пожалуйста, как от этого избавиться.
Стоит DXSDK 9.

Подскажите пожалуйста, где установить связь к DirectX SDK (9 версии). И что нужно изменить в проекте?

Скачайте с сайта engine_libs.zip
Там исходники библиотек и проекты (dsp, dsw) для сборки библиотек

Проблема. Где взять zlib.h, jpeglib.h, zlib.lib и подобные файлы? Без них не компилируются файлы ZipFileSystem.h/.cpp, PngDecoder.h/.cpp, JpegDecoder.h/.cpp .

Вышла очередная версия GameBase (v0.3).

Наиболее важные изменения в тестовой игре:

+ игра наконец то приобрела аркадный характер. Правило подсчета очков:
- за выпущенную ракету отнимается 0,5
- тестовые цели разрушаются с 3-х попаданий, за разрушение даётся +3,0
- при попадании в одну цель даётся столько очков, сколько секунд летела ракета
+ экран начала новой игры с выбором размеров поля и количества монстров
+ появилось оружие - ракеты, разрующие поверхность земли
+ можно находиться под водой
+ режим "пулемета" ракетами
+ появились уничтожаемые объекты-цели
+ добавлено управление звуком

Наиболее важные технические изменения:

+ оптимизация перебора ближайших актеров в коллекции актеров Аквы
(тестовая сцена 300 на 300 клеток содержащая 1000 летающих объектов-целей
(которые постоянно проверяют возможность столкновения друг с другом)
выдаёт 140-150 fps на Athlon XP 1.6 + Radeon 9800 Pro, при этом fps
меняется незначительно (1-5 кадров) при добавлении на сцену нескольких десятков ракет,
которые постоянно проверяют возможность столкновения с объектами-целями)
+ групповые радиобаттоны в MenuItemSimpleButton
+ проработана и задокументирована система многостадийной отрисовки объектов игры
(для учета прозрачных поверхностей, и т.п.)
+ затухание громкости звука с расстоянием (линейное)
+ сделана и задокументирована система актеров (монстров, подвижных предметов на поле и т.п.)
+ сделана и задокументирована подсистема шаблонов классов Math, реализующая примитивные
операции и вычисления над трехмерными объектами:
- типовые операции над векторами в пространстве (скалярное, векторное умножение и т.п.)
- определение точки пересечения плоскости и прямой
- определение того пересекает ли прямая треугольник в пределах его границ
- рассечение полигона плоскостью на 2 других вдоль линии пересечения
(спасибо Алексею Борескову)
+ полностью переделана объектная структура GameObject:
классы GameObject и GameObjectList упразднены, т.к. распались на более
логичную связку List и ListItem с одной стороны и модуль сериализации с другой
+ переработана объектная модель файловой системы - создана еще одна прослойка
между файловой системой и данными в виде FileSystemProvider

2 ReaVeR:

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

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

Что касается модели освещения с помощью динамических источников света и нормалей - она как правило используется там, где важно спекулярный эффект освещения - в гоночных симуляторах особенно. Если не знаете, это когда отполированная поверхность автомобиля, например, достаточно четко отражает на себе блики от источников света - "световые пятна". Всего пару-тройку лет назад графические акселераторы дошли до такого уровня что эту модель освещения стали применять и в другого рода играх. Игра света и тени на оружии, которое держит в руках герой Unreal, или Quake 3, например...
Вообще у новичков, сталкивающихся с современными 3D-технологиями рождаются как правило две иллюзии:
1. 3д-ускорители - это мощная штука, сотни миллионов полигонов в секунду - это не проблема для них. Это не так. Мой Radeon 9800 Pro на 4x AGP слоте "тормозит до 5-10 fps", стоит только видимой области в GameBase достигнуть 200 на 200 вершин (а это "всего лишь" 200*200*2*2=160000 треугольников из которых три четвертых отсекаются еще на cull view frustrum этапе, а оставшаяся часть покрывает площадь экрана всего лишь 3-4 раза). Стоит ли говорить что GeForce2 MX400 "вешается" при ГОРАЗДО БОЛЕЕ скромных площадях видимой области изображения.
Поэтому самая главная задача разработчика 3D-игры - это минимизация количества выводимых в 3D API полигонов (кстати задача распадается на множество подзадач, среди которых - минимизация количества вызовов API-шных ф-ий, чтобы снизить требования к пропускной способности шины, чему могут помочь шейдеры кстати, минимизация не только числа выводимых полигонов, но и покрываемой ими площади изображения, т.е. желательно один пиксель прорисовывать (в идеале) 1 раз, и т.п.).
2. Предлагаемые 3D API (D3D, OpenGL) возможности придуманы не просто так и они все активно используются в 3D-играх. Это, как ни странно, тоже миф. Подавляющая часть полигонов, которые вы видите в 3D-играх рисуется сходя всего лишь из одной функции 3D-карт, а именно:
- отрисовка текстурированного треугольника (возможно с использованием цветовой вершинной компоненты), либо отрисовка мультитекстурированного треугольника (без всяких цветовых вершинных компонент). Модели освещения по Фонгу, имхо, применяются процентах так в 5 выводимого на экран игр изображения, если не меньше.
В последнее время набирают силу шейдеры, но в целом ситуация с ними пока еще находится в той ситуации которую я описал выше.

Запамятовал что в D3D называется вершинным буфером, однако то огромное поле про которое вы говорите ни в какой буфер не влезет. Если речь идет про массивы вершин (когда информация об очередной вершине передается как индекс в массиве), то для сеточного ландшафта это желательно делать. Но опять же, сам массив должен строиться "на лету", в каждом кадре.

> Потом, если делать небольшое количество квадратиков
> на кв. метр ( 1; 0.01 ), то ландшафт будет очень
> угловатым, и нельзя будет делать небольшие овраги.

Возьмите какую нибудь более-менее современную игру с претензией на ландшафтную. Например Project IGI 2. Побегайте, посмотрите как там с этим обстоят дела и убедитесь что компромисс неизбежен.

2 =A=L=X=:

Ну как же нормали не нужны? Ведь наклонная гора должна нормально затенятся, ведь если векторы нормали во всех точках будут равны, то освещение будет плоским, что явно нежелательно.

Потом, всё сказанное утверждает, что мне придётся отказаться от вершинных буферов?

Потом, если делать небольшое количество квадратиков на кв. метр ( 1; 0.01 ), то ландшафт будет очень угловатым, и нельзя будет делать небольшие овраги.

2ReaVeR:

Хочу прокомментировать:

> ....Direct3D требует явно заданные координаты вершин,
> нормали, текстурные координаты ): 32 байта на вершину,

Во первых - то что D3D "требует" не означает что вам нужно хранить все эти данные. Всё что вам нужно (для начала) - это хранить только высоту. Причём очень может быть, что для вашего ландшафта может хватить диапазона высот из 65536 позиций, т.е. два байта на вершину (WORD, short int). Конечно при отрисовке все остальные параметры нужно "довычислить", и нормализовать. Т.е. имея массив WORD land[ MAX_X ][ MAX_Y ]; координаты вершины i, j в виртуальном пространстве найдём как:
x = xOffs + xCoef * i;
y = yOffs + yCoef * j;
z = zOffs + zCoef * (land[ i ][ j ] / 65536.0f);
примерно так, НО сразу замечу, что эти преобразования легко укладываются в модельную матрицу, следовательно нужно просто сместить её на вектор (-xOffs, -yOffs, -zOffs) и помножить на матрицу растяжения (xCoef, yCoef, zCoef / 65536.0f). Можете скачать GameBase - там как раз в модуле aqua_level реализован случай ландшафта сделанного подобным образом (правда на OpenGL).
Во вторых D3D, как и OpenGL, НЕ ТРЕБУЕТ чтобы для вершины обязательно были заданы все перечисленные вами параметры - обязательны только координаты точки, всё остальное опционально и настраивается.
Шейдеры тут применять не требуется - вычислять то тут собственно нечего.
1. координаты точек уже вычислили
2. информация о цвете не нужна
3. информация о нормалях не нужна
4. информация о материале не нужна
5. про текстурные координаты см. ниже

> 4x4 вершины на кв. метр,
> 1000000 кв. метров на кв. километр: 512 Мб.
> А если ограничить область, видимую одновременно,
> то придется отказаться от открытых пространств.....

Ого... хотите сказать что одновременно можно будет увидеть всё это великолепие?? Уверяю - любая видеокарта треснет, если на ней попытаются вывести такое количество полигонов. Тут требуется серьезная оптимизация. В настоящее время количество полигонов, подаваемых на вход 3Д API лучше держать в районе 10000-20000, но не более. Тут я думаю поможет многоступенчатое "склеивание" удаленных вершин при отрисовке уровня.
Кроме того такое дикое количество вершин явно черезчурное. Зачем такая детализация? Достаточно одной вершина на метр, а то и на 10 м для создания достаточно правдоподобной гео-карты, если сильно не извращаться с её наполнением. Кроме того, тут может помочь "склеивание" удаленных вершин при хранении лабиринта, а при приближении к ним - генерация "на лету" деталей.
Под "склеиванием вершин" я подразумеваю уменьшение детализации (точек на квадрат поверхности) с удалением от игрока (ступенчато) путем усреднения высоты соседних в исходном поле.
С текстурными координатами всё посложнее будет. Во первых - для достаточно реалистичного ландшафта текстуры надо варьировать по поверности. Во вторых, как уже правильно было замечено, координаты желательно хранить в самой вершине. Можно попробовать сделать так: сеточный ландшафт N на M вершин содержит (N-1) на (M-1) квадратов. Для каждого квадрата надо хранить:
1. номер текстуры, которая на него натягивается
2. u, v координаты в текстуре первой вершины в квадрате
3. 2 коэффициента растяжения/сжатия вдоль u и v координат (или uv-координаты вершины, противоположной первой, в квадрате, что даст тот же эффект).
В принципе опять же - если данных ОЧЕНЬ много, можно к примеру попробовать вариант где текстур не больще 256, uv-координаты первой вершины всегда (0,0), а коэффициентов растяжения/сжатия не более 16 штук (...4,3,2,1,0,1/2,1/3,1/4...) и таким образом уместить всё в два байта. Короче говоря вариантов то тьма, в конце концов можно вообще отказаться от сеточного движка и попробовать вершиннный, он хоть и требует всех 3-х координат для точки, но здорово экономит место на ровных плоскостях.

Алекс! Ты писал Гарант не "на пртяжении нескольких лет", а создал рабочий движок в 90-91 году. А уже в конце 91 года мы делали Гарант вместе - ты Windows- и Mac- версию, а я поддерживал досовскую :)