Jump to content
Korean Random
Dragon armor

Мод "Эмулятор сервера World of Tanks".

Recommended Posts

image.thumb.png.ad529cffabf73618e2437bcd9bb1876e.png

А визуализатор-то сто лет как есть, зачем силы тратить?)

https://github.com/mikeoverbay/nuTerra

 

 

On 2/29/2020 at 1:18 AM, DrWeb7_1 said:

Вероятно, с помощью довольно старой версии BigWorld World Editor, могу ошибаться.

Вроде там tankPosition в space.settings просто поднималась над ангаром и питоном добавлял модель минимального ангара, не влезая в space.bin

Собственно тут я своими руками(и свое утилитой) как раз и дополнил этот минималистик влезанием в space.bin

http://forum.worldoftanks.ru/index.php?/topic/745873-hell-hmhm-v2-минималистичный-ангар-15xx/page__st__520__pid__48918063#entry48918063

 

 

P.S. По разрушенным объектам есть отдельный файл "res\packages\scripts.pkg\scripts\destructibles.xml"

P.P.S. В space.bin также есть секции по разрушенным объектам - внутри bsmo/wsmo

P.P.P.S. В World Editor'е destructibles.xml с комментариями на русском

 

    <!-- Замечание: health разрушаемых объектов дожен быть integer'ом из [0, 2^16)
         Если выставить 0, объект будет считаться разрушенным, но визуально сохранит свое начальное состояние.
         Указываемое значение является референсным, здоровье конкретного объекта находится в
         квадратичной зависимости от его скейла по оси Y, и вычисляется по формуле:
         health = referenceHealth * scale * scale -->
    <!-- Падающие деревья и мелкие объекты анимируются с помощью физической симуляции.
         Физическая модель представляет собой стержень с пружиной в центре.
         Параметры:
         масса, длина, угол пружины, жесткость, сопротивление пружины, сопротивление воздуха, углубление в землю
         угол пружины - угол между прямой стержня и
         прямой проходящей через один из концов стержня и конец пружины -->
    <!-- Эффект разрушения задается параметрами:
         effect, lifetimeEffect, fractureEffect, touchdownEffect - имя эффекта в соответствующей секции destructibles_effects.xml,
         lifetimeEffectChance - вероятность запуска lifetimeEffect (от 0 до 1).
         Если это поле остутствует, вероятность принимается равной defaultLifetimeEffectChance.
         effectHP - хардпоинт эффекта.
         Замечание: деревья не имеют хардпоинта, эффект крепится к scene root дерева. -->
    <!-- Деревья. density - плотность листвы, влияет на видимость -->
    <!-- Trees, fallingAtoms, fragiles.
         kineticDamageCorrection - коэффициент позволяющий сделать зависимость урона от массы танка
         более ярко выраженной. Честная формулой для рассчета урона:
         damage = Ek * normaliser
         где: Ek - кинетическая энергия танка, Ek = 0.5 * mass * speed^2
               normaliser - коэффицинт масштабирования
         Работает скорректированная формула:
         damage = Ek * normaliser * (mass/unitVehicleMass)^kineticDamageCorrection
         где: unitVehicleMass - опорная масса.
              Эта масса, при которой совпадают урон по честной формуле и скорректированный урон.
         Пример: значение kineticDamageCorrection = 1, сделает зависимость урона от маcсы квадратичной.
         При отсутсвии поля kineticDamageCorrection, его значение принимается равным 0 и работает честная формула. -->
    <!-- achievementTag - тег (строка), позволяющий группировать объекты, в соответсвии с ачивками за их разрушение.
         Всем деревьям автоматически присваивается тег 'tree' -->
    <!-- fallingAtoms
         preferredTiltDirections - опциональный список направлениий падения объекта
         Значения указываются в градусах, разделяются пробелом. Значния могут быть десятичными дробями.
         Угол отсчитывается в локальной системе координат объекта в плоскости XOZ от оси OZ против часовой стрелки.
         Пример: Направление оси OZ = 0, Нарпавление оси ОХ = -90
         По умолчанию, если список не задан или пустой, направление падения совпадает с направлением воздействия.
         Если список задан, то будет выбрано направление падения, ближайшее к направлению воздействия.
         На скорость падения эти настройки не влияют.
     -->

Edited by SkepticalFox

Share this post


Link to post

Short link
Share on other sites
7 часов назад, SkepticalFox сказал:

А визуализатор-то сто лет как есть, зачем силы тратить?)

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

7 часов назад, SkepticalFox сказал:

Вроде там tankPosition в space.settings просто поднималась над ангаром и питоном добавлял модель минимального ангара, не влезая в space.bin

Ясно.

7 часов назад, SkepticalFox сказал:

P.P.S. В space.bin также есть секции по разрушенным объектам - внутри bsmo/wsmo

Таблица №15. Одна строка, предположительно, ссылается на destructibles.xml, другая на destructibles_effects.xml.

 

7 часов назад, SkepticalFox сказал:

P.P.P.S. В World Editor'е destructibles.xml с комментариями на русском

Интересно. Подумывал посмотреть World Editor, может что и полезного там будет.

 

Одно сейчас не могу понять - каким образом таблица bsmo[8] связана со статичными объектами? В этой таблице ссылка на bsma[0] содержится. На восьмую таблицу ссылается bsmo[7], но лишь в предположении, потому что максимальное значение в bsmo[7] как-раз соответствует количеству элементов в bsmo[8]. Вроде как в bsmo[0] есть такое же количество.

bsmo[8][bsmo[7][bsmo[0].index1].index].data - вроде всё просто и логично. Ссылка из одной таблицы на другую для ссылки на третью, из которой можно сослаться на четвёртую. Вот зачем это? Неужели всё это быстрее будет загружаться вместо того, чтобы загрузить один файл visual_processed? Всё-равно .primitives_processed открывается для чтения bsp2 дерева, хотя и копия геометрии объекта так же загружена в space.bin.

7 часов назад, SkepticalFox сказал:

wsmo

А этой секции ещё нет в 0.9.22.

 

С разрушаемыми объектами ещё много непонятного. Вот есть модель bldAF_004_vhouse\merged\lod0\bldAF_004_vhouse.primitives_processed. Домик глиняный.

А есть объект bldAF_004_vhouse\normal\lod0\bldAF_004_vhouse.primitives_processed - это тот же дом, но разрушаемый. Оба есть на карте. Недоступных мест нет, значит оба можно разрушить. Один объект подменяет другой? А разрушения как происходят? Там есть секции для разрушений. Это primitiveGroup?

В destructibles.xml есть ссылки на материал модели. Но в space.bin нет этих строк. Как тогда клиент узнаёт об этом? Всё-таки открывается .visual_processed?

Share this post


Link to post

Short link
Share on other sites
6 hours ago, Dragon armor said:

С разрушаемыми объектами ещё много непонятного. Вот есть модель bldAF_004_vhouse\merged\lod0\bldAF_004_vhouse.primitives_processed. Домик глиняный.

А есть объект bldAF_004_vhouse\normal\lod0\bldAF_004_vhouse.primitives_processed - это тот же дом, но разрушаемый. Оба есть на карте. Недоступных мест нет, значит оба можно разрушить. Один объект подменяет другой? А разрушения как происходят? Там есть секции для разрушений. Это primitiveGroup?

В destructibles.xml есть ссылки на материал модели. Но в space.bin нет этих строк. Как тогда клиент узнаёт об этом? Всё-таки открывается .visual_processed?

Да все же понятно ) BSMI ссылается только на неразрушенные модели внутри BSMO.

А вот уже эти модели модели внутри BSMO ссылаются на разрушенные модли внутри BSMO (смотри последний коммит в момем репо).

Для примера - в BSMO есть список моделей (models_loddings) а также список с информацией о типе объекта (model_info_items) той же размерности.

Так вот если type=0 - это статик объект, если type=1 - это объект, который можно свалить на землю, если type=2, то это объект который можно разрушить.

Также там есть info_index, который ссылается на секции falling_model_info_items/fragile_model_info_items в зависимости от типа (1/2)

Вот уже там, во fragile_model_info_items есть destroyed_model_index - model_id разрушенного объекта, и если model_id = 0xFFFFFFFF, то объект при разрушении просто исчезнет.

 

6 hours ago, Dragon armor said:
13 hours ago, SkepticalFox said:

wsmo

А этой секции ещё нет в 0.9.22.

И не будет ее больше никогда, она только до 0.9.20 была, потом объеденили её в 0.9.20 с BSMO

Даже комментарии оставил (похоже только мне понятные)

 

class BSMO_Section_0_9_20(Base_JSON_Section):
		    header = 'BSMO'
		    int1 = 1

		    _fields_ = [
		        (list, 'models_loddings',          ModelLoddingItem_v0_9_12        ),
		        (list, 'models_colliders',         ModelColliderItem_v0_9_12       ),
		        (list, 'bsp_material_kinds',       BSPMaterialKindItem_v0_9_12     ),
		        (list, 'models_visibility_bounds', MinMax                          ), # *.model/visibilityBox
		        (list, 'model_info_items',         WoTModelInfoItem_v0_9_12        ), # 0.9.12: WSMO['1']
		        (list, 'model_sound_items',        '<I'                            ), # 0.9.12: WSMO['5']
		        (list, 'lod_loddings',             '<f'                            ), # *.model/extent
		        (list, 'lod_renders',              LODRenderItem_v0_9_12           ),
		        (list, 'renders',                  RenderItem_v0_9_12              ),
		        (list, 'node_affectors1',          '<I'                            ), # link section 'pgroups' with 'visual_nodes'
		        (list, 'animations',               AnimationItem_v0_9_12           ),
		        (list, 'node_affectors2',          '<I'                            ),
		        (list, 'visual_nodes',             '<I16f'                         ), # *.visual/nodes
		        (list, 'model_hardpoint_items',    '<16f'                          ), # 0.9.12: WSMO['4']
		        (list, 'falling_model_info_items', WoTFallingModelInfoItem_v0_9_12 ), # 0.9.12: WSMO['2']
		        (list, 'fragile_model_info_items', WoTFragileModelInfoItem_v0_9_12 ), # 0.9.12: WSMO['3']
		        (list, 'vertices_data_sizes',      VerticesDataSize_v0_9_20        ),
		        ]

 

Вообще по структуре моего репо это должно быть очевидно -> каталог с каждой секцией содержит секции, в имени файла которых присутствует версия, с которой эта секция претерпела изменение(или появилась). Также и с именами секций/структур.

 

6 hours ago, Dragon armor said:

Да и как интегрировать этот визуализатор?

Это опенсорс, как моешь так и делай)

 

6 hours ago, Dragon armor said:

Неужели всё это быстрее будет загружаться вместо того, чтобы загрузить один файл visual_processed?

всмысле один помноженный на 300+ ? Конечно быстрее

Edited by SkepticalFox

Share this post


Link to post

Short link
Share on other sites

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

Кстати, подтвердил свои догадки на счёт ссылок внутри секции.

bsmo[0]
    bsmo[7]
        bsmo[8]

Хотя эта иерархия уже была очевидна.

52 минуты назад, SkepticalFox сказал:

всмысле один помноженный на 300+ ? Конечно быстрее

Ну не на 300, а всего лишь на 121 для той карты, которую использую, к тому же, эти файлы и так лежат внутри одного архива.

54 минуты назад, SkepticalFox сказал:

Это опенсорс, как моешь так и делай)

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

5 минут назад, Dragon armor сказал:

У меня и не было твоего репозитория.

Вообще, было, но очень старая версия, где только для 0.9.12 частично разобрано.

Share this post


Link to post

Short link
Share on other sites
11 часов назад, SkepticalFox сказал:

Да все же понятно ) BSMI ссылается только на неразрушенные модели внутри BSMO.

А вот уже эти модели модели внутри BSMO ссылаются на разрушенные модли внутри BSMO (смотри последний коммит в момем репо).

Для примера - в BSMO есть список моделей (models_loddings) а также список с информацией о типе объекта (model_info_items) той же размерности.

Так вот если type=0 - это статик объект, если type=1 - это объект, который можно свалить на землю, если type=2, то это объект который можно разрушить.

Также там есть info_index, который ссылается на секции falling_model_info_items/fragile_model_info_items в зависимости от типа (1/2)

Вот уже там, во fragile_model_info_items есть destroyed_model_index - model_id разрушенного объекта, и если model_id = 0xFFFFFFFF, то объект при разрушении просто исчезнет.

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

Получилось текстуры на объекты поставить. Они, в общем-то, не нужны, для физического движка это лишняя информация. Но для вьювера норм. Ещё не всё гладко, нужно будет с разрушаемыми объектами поработать, а то похоже, что друг на друга накладываются.

s_t1.thumb.jpg.08cba8ca5a458b5b794e41ccfb76a0fa.jpgs_t2.thumb.jpg.d841ae8c024f2710b78dd9a76332a431.jpgs_t3.thumb.jpg.f987053cdea2b0d7c2eefebac0c7d8e0.jpg

 

А вот таким забавным способом закрываются подсадки. Невидимые, но в физической модели присутствующие.

s_t4.thumb.jpg.1dc2454307f745089250f682b2edd935.jpg

 

Вопрос такой. Вот есть объект. Зачем ему материал s_ramp_0? Это то, что будет после разрушения? Но там даже текстура не прописана. Он невидим. Просто плавный подъезд? И такое во многих местах. Группа камней, например.

ramp - скат, трап, уклон. Невидимый физический объект для более плавного передвижения по нему. Получается, так и есть.

 

s_t5.thumb.jpg.ec0d824c47ea5ae94b92bcda8f73c332.jpgs_t6.thumb.jpg.cb4ff311e7f062cb34cc0121c8d9317d.jpg

Share this post


Link to post

Short link
Share on other sites
40 minutes ago, Dragon armor said:

ramp - скат, трап, уклон. Невидимый физический объект для более плавного передвижения по нему. Получается, так и есть.

https://github.com/v2v3v4/BigWorld-Engine-2.0.1/blob/c881231e0f72a129c4dd92e3b76eb1610f4a92c4/src/lib/physics2/worldtri.hpp#L34-L54

думаю bsp_material_kinds в BSMO ссылается на эти флаги, и у подобных невидимых объектов должны быть соответствующие флаги

я пока не проверял это

 

40 minutes ago, Dragon armor said:

Ещё не всё гладко, нужно будет с разрушаемыми объектами поработать, а то похоже, что друг на друга накладываются.

Так выложи в опенсорс, помогу с фиксом)

Ты там лишние группы примитивов грузишь из .primitives_processed, а нужно строго те, что указаны в BSMO

Edited by SkepticalFox

Share this post


Link to post

Short link
Share on other sites
10 часов назад, SkepticalFox сказал:

Ты там лишние группы примитивов грузишь из .primitives_processed, а нужно строго те, что указаны в BSMO

Вон он что. Ясно-понятно. Поправил, теперь только ramp рисуется лишним. А также три точки респа. Где-то в настройках карты явно прописано, какая точка на данном типе карты загружается. В общем-то, это не критично (особенно, на данный момент) для простейшего вьювера.

 

s_tt1.thumb.jpg.6d6421f4fe8df1346a502a7897354f94.jpg

 

Надо с физикой что-то делать. И похоже, придётся bsp2 дерево добавлять и свой обработчик столкновений. Либо попробую прямо из геометрии объекта взять, просто интересно, что получится. Благо, дамп физики можно сделать и посмотреть на результат.

11 часов назад, SkepticalFox сказал:

Так выложи в опенсорс

Не готов пока что к этому.

Share this post


Link to post

Short link
Share on other sites

 

Мдя, печально. Получаю ассерт в физическом движке, когда добавляю первый домик. Как мне помнится, в TreeCollision у меня нормально добавлялось около 400к полигонов, хотя и занимало много времени. А тут свалилось на 6000.

dgAssert (stack < DG_STACK_DEPTH);

На форуме у них попробую спросить, что делаю не так.

Share this post


Link to post

Short link
Share on other sites

У них там ещё и ручная активация аккаунта. Ладно, подождём.

 

Почему сообщения не объединяются?

Тест.

А сейчас объединилось. Угу, ясно-понятно.

Edited by Dragon armor

Share this post


Link to post

Short link
Share on other sites

@SkepticalFox Принято. Позже посмотрю.

Вот что получилось. Так видит физический движок загруженный мир. Летающие камни, подземные дома. Всё норм. Это фиксится. Всё позже. Пока хватит.

Кому интересно, вот геометрия. В импортёре stl, чтобы всё нормально было, надо сделать ось вверх Y, а ось вперёд -Z (минус Z). И отмасштабировать поменьше, чтобы не обрезалось.debug_0.7z

s_p1.thumb.jpg.1ab2f769705afbb30d989b27668304e9.jpg

  • Upvote 1

Share this post


Link to post

Short link
Share on other sites

@Dragon armor , как по мне, уже вполне интересный и хороший результат! :great:

Share this post


Link to post

Short link
Share on other sites

Никак не могу понять, в чём именно проблема. Не совпадает геометрия видимая и в физическом движке. Ладно по позиции, тут меняю оси местами (X->Z), хотя даже не понимаю, почему это помогает. Физический движок не зависит от системы координат. Когда ландшафт делал, так же были проблемы с позиционированием, пришлось местами поменять оси, тогда всё совпало. Но тут некоторые объекты оказались повёрнуты на 90º. Некоторые по одной оси, другие по другой.

Вот место на карте. Всё так, как и в игре. Позиция, ориентация, заборчики также стоят.

shot_007.thumb.jpg.6bb90b0e03200ca6da2b9edf4c2ab17b.jpgs_g1.thumb.jpg.c8f930dc350fd6d4a7c6540c3560fcaa.jpg

 

Вот в физическом движке. Именно эти два объекта повёрнуты по оси Z на 90º. Рядом дом по другой оси повернулся, поэтому лежит на боку. Заборчики неправильно ориентированы. Но при этом, все объекты на своих местах, позиция правильная.

s_g2.thumb.jpg.f214d9cbe2a0a3e0e0e48e66cdc00a4a.jpg

 

Геометрию загружаю одну и ту же, результат одинаковый, но почему ориентация не правильная? Почему в визуализаторе правильная ориентация, не требуется менять X на Z? Матрица одна и та же.

 

Забавный эффект произошёл. Хочу сделать одну вещь, для этого потребовалось с x32 перейти на разрядность x64. Внезапно увеличилась скорость работы с файлами при инициализации. По ощущениям, прямо на порядок. При загрузке визуализатора у меня грузятся все архивы из файла paths.xml. В 32 битной версии это занимало несколько секунд, а в 64 битной просто мгновенно происходит.

 

Поспешил насчёт правильности позиции в физическом движке. Не совпадает даже это.

s_g3.thumb.jpg.0abc4dbb4dd798a1c5df905253564a29.jpg

Share this post


Link to post

Short link
Share on other sites

Ну что тут скажешь) Без кода нихрена не понятно.

Ты матрицы BSMI транспонировал?

Share this post


Link to post

Short link
Share on other sites
2 минуты назад, SkepticalFox сказал:

Ты матрицы BSMI транспонировал?

Зачем?

3 минуты назад, SkepticalFox сказал:

Ну что тут скажешь) Без кода нихрена не понятно.

А во вьювере почему правильно? А? А, а, а?

Share this post


Link to post

Short link
Share on other sites

@SkepticalFox Мне не понятно, почему применение идентичной матрицы в irrlicht и физическом движке приводит к разным результатам. Что там за магия такая происходит? Матрица одна и таже берётся у меня, строкой выше назначается позиция во вьювере, строкой ниже в физический движок она же передаётся. В irrlicht какая-то магия происходит в getRotationDegrees (почему-то для него нужна позиция и вектор вращения, матрицу передать ему нельзя).

Позицию беру из BSMI, самая первая таблица (или нулевая в терминах си).

        core::matrix4 matrix_p;
        memcpy(matrix_p.pointer(), entity_position->mat, sizeof(*entity_position));

        scene::IMeshSceneNode *node_fr = smgr->addMeshSceneNode(mesh_preloaded[index], NULL, i, matrix_p.getTranslation(), matrix_p.getRotationDegrees());

И для каждой коллизии статичного объекта

            void *proxy = NewtonSceneCollisionAddSubCollision(scene_collision, obj_collisions[j]);
            NewtonSceneCollisionSetSubCollisionMatrix(scene_collision, proxy, matrix_p.pointer());

3d для меня достаточно сложная вещь. Хз что там нужно ещё делать.

 

Share this post


Link to post

Short link
Share on other sites

@SkepticalFox Очень простой движок для построения 3d сцен. Мне простота и нужна. Есть Ogre, но там инициализация на три экрана.

Share this post


Link to post

Short link
Share on other sites
11 minutes ago, Dragon armor said:

getRotationDegrees

https://github.com/zaki/irrlicht/blob/fd155bead0e24cc5018b9f4cee2d73c85b18badc/include/matrix4.h#L904

 

11 minutes ago, Dragon armor said:

scene::IMeshSceneNode *node_fr = smgr->addMeshSceneNode(mesh_preloaded[index], NULL, i, matrix_p.getTranslation(), matrix_p.getRotationDegrees());

Тут еще scale передать можно, чего не передаешь?

Share this post


Link to post

Short link
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...