Формат Mpr

[Jet]

Вот информация, по формату .mpr, которую мы раскопали.

Задавайте Ваши вопросы по этому поводу только в этой теме.

[heller]

а где описание sSecData1 и sSecData2 ?

[ALtair]

В заголовочном файле куча ошибок и неточностей. Соотнося с текстовиком заголовок мр файла должен получиться следующим:

Код:

typedef struct sMpHead    // Заголовок файла
{
    DWORD    dwSig;      // Сигнатура, всегда 0xCE4AF672
    float    fScale;      // Максимальная высота
    long    nSecX;      // Количество секторов по X
    long    nSecY;      // Количество секторов по Y
    long    nTexture;  // Кол-во текстур
    DWORD    dwTextureSize  // Размер Текстуры
    DWORD    dwnTiles;  // Кол-во Тайлов
    DWORD    dwTileSize;  // Размер Тайла
    WORD    wNumMaterials;  // Кол-во используемых материалов.
    DWORD    dwNumAnimTiles;  // Кол-во анимированных тайлов.
}

Непонятно, почему количество тайлов почти везде совпадает с размером текстуры. Может быть этот параметр отвечает вовсе не за количество тайлов?
И еще. Что за анимированные тайлы? Это как вообще? Это к воде и лаве относится что ли?

И еще, в МР файле насколько я понял нет ничего, что отвечает за воду. А то, что в заголовочном файле названно sMpWater на самом деле есть ничто иное, как параметры материала. Этот материал я бы описал следующим образом:

Код:

typedef struct sMpWater  // Заголовок файла
{
    DWORD    dwSecNo;  // Номер секции - тут возможно идет не номер секции, а Material Power, либо просто индекс материала.
    float    fFaceColorR;
    float    fFaceColorG;
    float    fFaceColorB;
    float    fFaceColorA;
    float    fDiffuseColorR;
    float    fDiffuseColorG;
    float    fDiffuseColorB;
    float    fSpecularColorR;
    float    fSpecularColorG;
    float    fSpecularColorB;
}

[heller]

Берем sec без воды
размер = 9229 байт
размер sSecData1 = размер sSecGroundData + размер sSecTextureData = 9 байт

считаем sSecData1*32*32 = 9216 + 2 байта заголовок
получаем 9218, итого остается 11 байт, а надо считать 16*16, в чем дело?

аналогично пробовал 7*32*32+2*16*16+2 , тоже не сходится...

[Jet]

а где описание sSecData1 и sSecData2 ?

Согласен, неточности имеют место быть.
sSecData1 = sSecGroundData
sSecData2 = sSecTextureData

DWORD dwSecNo;

Тип материала
Структуру sMpHead ты описал верно.

Код:

.MP
sMpHead
Материалы[wNumMaterials]
Тайлы[dwnTiles]
Анимация Тайлов[dwNumAnimTiles]

Код:

.SEC
sSecHead
sSecGroundData[33x33] // Карта высот суши 33x33
if (sSecHead->bWaterFlag)
{
 sSecGroundData[33x33] //Карта высот воды (лавы) 33x33
}
sSecTextureData[16x16] //Карта текстур для суши. 16x16
if (SecHead->bWaterFlag)
{
 sSecTextureData[16x16] //Карта текстур для воды(лавы). 16x16
 BYTE[16x16] // ID Тайлов
}

Берем sec без воды
размер = 9229 байт
размер sSecData1 = размер sSecGroundData + размер sSecTextureData = 9 байт

считаем sSecData1*32*32 = 9216 + 2 байта заголовок
получаем 9218, итого остается 11 байт, а надо считать 16*16, в чем дело?

аналогично пробовал 7*32*32+2*16*16+2 , тоже не сходится...

Исправляюсь...

5 + 33*33*8 + 2*16*16 = 9229
5 + (33*33*8 + 2*16*16 + 1*16*16)*2 = 18965

5=SECHead
8=SECGround
2=SECTexture
1=BYTE

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

[heller]

Тогда другой вопрос... почему карта текстур 16x16 а не 33x33
Также интересно зачем ID Тайлов нужен вообще? почму только у воды...

[Jet]

Тогда другой вопрос... почему карта текстур 16x16 а не 33x33
Также интересно зачем ID Тайлов нужен вообще? почму только у воды...

16x16, думаю для экономии ресурсов
33x33, думаю для реалистичности
ID тайлов, я так думаю для озвучки (у различных тайлов различный звук), а почему только у воды - я, к сожалению, не в курсе , т.к. разбор .mpr формата мы приостановили, так и не выяснив некоторых деталей...

[ALtair]

Джет, поясни пожалуйста поподробнее по поводу анимации тайлов. Что это такое и с чем её едят?

[v1s0r]

Привет всем!
Мда, сколько лет прошло?

У меня пара вопросов по формату карты, а именно сама высота:
WORD wHeight;

Я успешно прочитал файл и визуализировал меш уровня, но мне пришлось подгонять высоту.

На примере bz8k.mpr
float fScale (max_z): 30.635298
Однако значения высот в wHeight находятся в рамках (примерно) 15000-45000.
У меня сомнения, что fScale это макс. высота.
Вот так я подогнал высоту:

Код:

0.025f * (ground_data[i * VERTEX_SIDE + j].wHeight / fScale)

Я работаю над проектом с открытым кодом для ПЗ. Пока всё в зачаточном состоянии, говорить рано. Но он обещает быть интересным.

Огромное вам спасибо, что раскрыли sSecTextureData, а то бы пришлось дооолго заниматься реверс-инженирингом!

Вот ещё ссылка на описание mpr, кто не знает.
Но там тоже местами неправда.
http://svn.gipat.org/trac/GGWiki/wiki/Docu...tion_mpr_format

[ALtair]

Эмм, С высотой там все в порядке, все правильно описано и fScale - это максимальная высота. Суть в том, что значения в wHeight показывают лишь "уровень" террейна в точке спроецированный на диапазон [0.0, fScale]. Если у тебя там визуально не совпадает картинка загруженного собственноручно террейна с тем, что ты видишь в игре, то, вполне вероятно, у твоего приложения может быть неправильно выставлен Aspect Ratio. Ну или правильнее будет сказать не "не правильно", а, скорее, "отлично от ПЗ".

[Sagrer]

Но там тоже местами неправда.

подскажешь где неправда - поправлю %). Ты про оффсеты чтоль? А х его з что оно на самом деле, надо экспериментировать на движке, подсунуть ему разные значения, но мне чего-то вломы, смысла имхо никакого нет %).

[v1s0r]

Можно поправить раздел с описанием LandTextures (sSecTextureData). Хотя я сам ещё не дошёл до текстур, не проверял.

[ALtair]

подскажешь где неправда - поправлю %). Ты про оффсеты чтоль? А х его з что оно на самом деле, надо экспериментировать на движке, подсунуть ему разные значения, но мне чего-то вломы, смысла имхо никакого нет %).
[right][snapback]39813[/snapback][/right]

Я ж вроде уже объяснял тебе, что за оффсеты?

Сие есть тупо дополнительные "смещения" вершины в горизонтальной плоскости. Они позволяют добиться псевдо-иррегулярности сетки, что в некоторых местах может помочь избавиться от визуальных артефактов.

Принимают значения, соответственно, от 0 до 127. При нулевых значениях вертекс будет совпадать с узлом регулярной сетки. При значении (127, 0), к примеру, вертекс будет смещен на полклетки вправо.

[v1s0r]

Ага, т.е. тут так же, как и с высотой - считать относительными значениями, а не тупо прибавлять/отнимать у координаты?

Кстати, ALtair, а что нового ты ещё узнал из mpr с момента последнего обновления документа?

[ALtair]

А о каком таком "документе" речь?

[v1s0r]

А о каком таком "документе" речь?
[right][snapback]39824[/snapback][/right]

mpr.h, если ты, конечно, участвовал в его создании.

[ALtair]

о_О Никогда б не назвал хидер документом )) Ну да ладно.

Собстно, я обладаю всей полнотой знаний по формату mpr, если чо.

[v1s0r]

о_О Никогда б не назвал хидер документом )) Ну да ладно.

Собстно, я обладаю всей полнотой знаний по формату mpr, если чо.
[right][snapback]39843[/snapback][/right]

У меня осталась пара вопросов: это материалы и тайлы.

Про тайлы вообще непонятно, в том числе и про анимированные (последних подозрительно мало, 1-2).

С материалами частично понятно, частично нет. Скомбинировав инфу с хидера и доку от Sagrer, понятно назначение материала для воды для её прозрачности.
Но есть ещё другие типы материалов, например для поверхности.
Поэкспериментировав, я обнаружил, что при комбинировании цвета поверхности и текстуры получается картина подозрительно похожая на ночь. Кроме Кании. Там везде зелёный цвет, с белой текстурой плохо получается. Подскажи, пожалуйста, что ты об этом знаешь. А то может вы уже всё досконально исследовали!

[ALtair]

Про тайлы вообще непонятно, в том числе и про анимированные (последних подозрительно мало, 1-2).[right][snapback]39903[/snapback][/right]

В той секции, которая обозначена "тайлами" указывается привязка материалов к текстурным тайлам. Геометрические тайлы при отрисовке будут использовать указанный текстурный тайл с примененным к нему материалом.

А в секции анимированных тайлов просто позволяет сгруппировать некоторые текстурные тайлы в анимационные последовательности. В текстуре, к примеру, содержится 4 кадра анимации воды, так вот в секции анимированных тайлов будет сказано, что с такого-то по такой текстурный тайл лежит пачка кадров анимации, которую надо воспринимать как единый текстурный тайл. Ферштейн?

С материалами частично понятно, частично нет. [right][snapback]39903[/snapback][/right]

Подскажи, пожалуйста, что ты об этом знаешь. А то может вы уже всё досконально исследовали!
[right][snapback]39903[/snapback][/right]

Материал - это обычная для Direct3D сущность. В материале хранятся настройки поверхности для Fixed-Function Pipeline, а именно: Цвет самосвечения (Emissive), цвет отражения (Diffuse), цвет блика (Specular), цвет общего освещения (Ambient) и четкость блика (Specular power). Подробнее можно почитать в документации к Direct3D. В MPR-ском материале заданы, конечно же, не все эти параметры, а лишь тип материала (указание, где именно используется), цвет отражения (Diffuse, включая альфу), коэффициент самосвечения (SelfIllum), который по сути участвует в конечном итоге в расчете Emissive цвета материала вот так: Emissive = SelfIllum * Diffuse, и настройки волн для воды.

[v1s0r]

Ферштейн?

Спасибо. Буду втыкать и экспериментировать. Попрошу помощи, если что.

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