Готика ½ Gothic World Editor 0.0.3

[DEDROIT]

​

О редакторе Нововведения Медиа

• 
  Ресурсы портала: World of Gothic.ru
  Страна разработчика: РФ
  Платформа игры: "Готика 1", "Готика 2", "Готика 2 - Ночь Ворона"
  Тип обновления: Пакет
  Рабочее название: Редактор миров
  Версия: alpha
  Язык: Русский, Английский
  Вес: ~20 МБ
  
  Автор/разработчик: DEDROIT
  
  Статус: Тестирование (99% в разработке)
  Дата релиза: февраль 2021 г. (бета версия)
  Версия 1.0: разработка приостановлена до 05.08.2021
  Дата обновления:
  
  Описание:
  Gothic World Editor — графический редактор миров, который дополнительно в себя включает инструменты по работе с моделями, текстурами и vdf томами (для игр: 'Готика 1', 'Готика 2', 'Готика 2 - Ночь Ворона', модов и аддонов на их основе).
  
  У программы свой собственный рендерный движок, свои парсеры форматов игр 'Готика' и своя логика работы с теми или иными объектами. Она является полностью независимой и не требует наличия установленной игры.
  
  Основные цели и задачи:
  
  
  

  • Добавление удобных инструментов при работе с ZEN
  • Поддержка современных OC
  • Объединение всех доступных инструментов в одной программе
  • Обеспечение независимости от движка и от ресурсов игры
  • Обеспечение отказоустойчивости
  
  Системные требования и ПО:
  
  Оптимальные системные требования:
  

  • Windows 7/8/8.1/10
  • Платформа x32/x64
  • Видео карта с поддержкой OpenGL 3.3 +
  • 50MB свободного места на жёстком диске
  • 2 ГБ ОЗУ

  Используемые технологии:
  

  • Visual Studio 2017
  • Основной язык разработки - c#(.Net 4.6.1)
  • OpenTK 2.0 - wrapper for OpenGL (OpenTK)
  • OpenGL 3.3 - 4.5 (в зависимости от видео карты) + шейдеры
  • MetroFramework - WinForms 1.4.0 (MetroFramework)
  • FreeImage 3.17.0 (FreeImage)

  
  Необходимое ПО:
  

  • Microsoft .NET Framework 4.6.1
  • C++2013 x64
  
  Информация по установке:
  
  Инструкция по установке:
  1. Установите Microsoft .NET Framework 4.6.1 или выше (Framework 4.6.1).
  2. Обновите драйвера видео-карты.
  3. C++2013 x64,
  4. Установите G1MDK и/или G2MDK в полной версии:
  для Г1 (g1mdk-1.08k и обновление файлов)
  для Г2 (g2mdk-2.6)
  
  Примечание: Игры - Г1, Г2, Г2:НВ, можно вообще не устанавливать. Редактору важен только каталог со структурой ресурсов игры:
  "..\data\Anims", "..\data\Meshes", "..\data\Textures" и т.д.
  
  
  Возможные проблемы и пути их решения:
  
  
  

  1. Не запускается редактор. Решение: необходимо установить .Net 4.6.1/C++2013 x64 и проверить поддерживает ли ваша видео карта OpenGL 3.3. Попробуйте в Spacer.xml поменять значение в теге glcontrol (например, на ForwardCompatible, т.е. установить значение = 2).
  2. Не загружаются ресурсы игры (запускается редактор, но в нём ничего нет). Решение: проверьте путь к игре (он должен быть такого вида - "C:\Gothic2\_work\data\"). Поменять его можно либо в GWE.xml в теге resources или в настройках редактора. Если путь указан верно, тогда проверьте наличие установленного полного GMDK.
  3. Редактор загружается, но почему-то не отображается небо или некорректно отображаются загруженные миры(zen). Решение: обновите драйвер для вашей видео карты. Если это не помогло, то зайдите в GWE-> Tools->Log и посмотрите какая у вас поддерживается версия OpenGL (версия должна быть >=3.3)
  
  
  Управление:
  
  
  Передвижение - WSDA
  Вверх/вниз - Q/E
  Обзор - движение мышкой
  Приближение/увеличении - колёсико мышки
  Удаление объектов - delete
  Клонирование объектов - ctrl+c/ctrl+v
  Ускорение и выделение нескольких объектов - зажатый shift/shift + click
  
  Есть ещё ряд комбинаций.
  
  
  
  
• 
  
  Нововведения и возможности:
  

  • Визуальный просмотр моделей в формате *.3DS
  • Визуальный просмотр моделей в формате *.MRM
  • Визуальный просмотр моделей в формате *.ASC
  • Визуальный просмотр текстур в формате -C.TEX/TGA/PNG/JPG/BMP
  • Экспорт текстур в формат DDS/JPEG/BMP/PNG
  • Распаковка и просмотр содержимого VDF архива
  • Экспорт данных из VDF
  • Загрузка ZEN (BinSafe, ASCII)
  • Просмотр свойств объектов
  • Камера (свободное движение по всем осям, движение вдоль одной оси)
  • Изменение позиции, угла поворота, направления камеры
  • Масштабирование, вращение, перемещение объектов мышкой
  • Инструменты Gizmo
  • Zoom, Hand
  • Добавление объектов в ZEN из любого места(из дерева, и VDF архва) с помощью drag and drop
  • Отображение/редактирование/добавление freepoint
  • Отображение waypoint и маршрутов
  • Импорт OBJ моделей
  • Визуальный просмотр текстур загруженных объектов
  • Визуальный список всех объектов с возможностью переноса во viewport
  • Поддержка *.WAV
  • Визуальный просмотр расстояния от выделенного объекта на указанное расстояние
  • Поддержка форматов Готики 1
  • Bullet physics
  • Поддержка *.DAT
  • Поддержка MDL, MDM, MDH
  • Логирование
  • Отчёты (количество объектов, текстур, моделей, анимаций)
  • OCtree (разбиение локаций на небольшие "участки", каждый из которых может включать ещё 8 зон)
  • Gizmo (вращение/масштабирование/перемещение с возможностью выбора Pivot и локали(Wold/Local))
  • Поддержка выделения сразу нескольких объектов
  • Инструменты для работы с сеткой путей
  • Гибкая настройка
  
  
• 
  Видео:
  
  
  
  Графика:
  
  
  
  
  
  
  
  

 

[DEDROIT]

Небольшой отчёт

Удалось полностью реализовать Octree.
Производительность выросла,примерно, в 2-3 раза, если находиться в стандартном режиме (т.е. рендер происходит только в тот момент времени, когда пользователь выполняет какие-то действия). Если находиться в игровом режиме (рендер осуществляется постоянно, даже если пользователь ничего не делает), тогда цифра увеличивается в 4-5 раз.

Если, для примера, взять Хоринис, на моём ноутбуке со встроенной видео картой, в обычном режиме 45-70fps, в игровом режиме 65+ fps
Т.е. 65 fps - это в самом тормозном месте.

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

На данный момент приступаю к исправлению всех найденных мною недочётов и к реализации функции "Сохранить ZEN (ASCII)"

 

[hell9999]

DEDROIT - Денис, интересует вот какой вопрос: изменение пропорций вобов с помощью инструмента scale сохраняется для конкретного воба и не сбрасывается после перезагрузки программы? В каких параметрах воба потом хранятся такие данные?
То бишь, вполне реально использовать один меш камня, к примеру, делая его клоны разных размеров прямо в спейсере, обеспечивая таким образом визуальное разнообразие без дополнительных кликов по спискам объектов?
И вдогонку, пришла в голову мысль - было бы просто здорово не просто просматривать имеющиеся текстуры, а перетаскивать их прямо на меш. Поясню, для чего может это понадобится. Допустим, у нас есть меш куска скалы с анврапом. И подготовлен набор текстур под эту развертку. В данный момент, для того, чтобы обеспечить визуальное разнообразие под каждую локацию, приходится на каждую текстуру заводить отдельный меш, увеличивая список вобов в разы, а учитывая, что этих самых вобов и так уже десятки тысяч, воберу ориентироваться во всем этом становится крайне тяжело. При наличии же возможности применить любую текстуру на любой меш, вобер бы сам подгонял результат по своим предпочтениям, ну и мы бы избавились от тысяч, по сути дублирующихся мешей, отличающихся только шкуркой.

 

[Gratt]

масштабирование объектов

Масштаб задается через матрицу воба, она полностью пишется в сейв. НО:

изменение их пропорций

-> Изменение пропорций в ZenGin может очень люто и безбожно убить физическую модель => столкновение персонажа с таким объектом может повлечь непредсказуемый эффект, например запустить тебя в стратосферу или выкинуть в другой конец локации.

а перетаскивать их прямо на меш

Для вобов можно без проблем реализовать модификатор материалов. Но тут надо подшаманить архиватор и самого движка.

 

[hell9999]

Изменение пропорций в ZenGin может очень люто и безбожно убить физическую модель => столкновение персонажа с таким объектом может повлечь непредсказуемый эффект, например запустить тебя в стратосферу или выкинуть в другой конец локации.

Можно поинтересоваться, отчего так? От несовпадений положения вертексов в самом 3дс файле и в отскейленом вобе? Или проблема в bbox?

Для вобов можно без проблем реализовать модификатор материалов. Но тут надо подшаманить архиватор и самого движка.

Зер гуд! Дело за малым - запилить сию фичу.

 

[Gratt]

Можно поинтересоваться, отчего так? От несовпадений положения вертексов в самом 3дс файле и в отскейленом вобе? Или проблема в bbox?

Без понятия, не разбирался. Но выглядит это как-то так
Но факт остается фактом

Спойлер

Чем сильнее искривляются пропорции, тем сильнее эффект. При равномерном масштабировании ситуация получше, но все равно коллизии считаются криво. +Если переборщить, то объект перестанет рендериться.

 

[hell9999]

Без понятия, не разбирался. Но выглядит это как-то так

Судя по тому, что ГГ провалился все-таки через шкаф, или же сбиваются настройки проницаемости воба (что маловероятно), или же действительно, при компиляции модели задается bbox, по крайним вершинам модели, который после увеличения габаритов самого воба остается прежним.

 

[Gratt]

Судя по тому, что ГГ провалился все-таки через шкаф, или же сбиваются настройки проницаемости воба (что маловероятно), или же действительно, при компиляции модели задается bbox, по крайним вершинам модели, который после увеличения габаритов самого воба остается прежним.

Да фиг знает с чем там проблемы, надо сидеть курить это все. Я так потыкался слегка и заметил такую штуку. BBox в норме, коллизии чекаются, НО обращаю внимание на то, КАК они чекаются. Видно что вектор трассировщика статичен по X и всегда в районе бошки. Луч находит отмасштабированный объект в исходных координатах, а вот точка касания пишется в репорт в пересчитанном виде - относительно новых координат. Это можно понять исходя из того, что луч начинает неестественно сильно отклоняться от головы гг. В общем наверное завтра гляну где сидит эта крыса и попробую перекомпилировать физику воба.

Спойлер

 

[Gratt]

Посидел покурил эту тему с коллизиями, в общем нашел я этих крыс, они оказались вполне очевидными.
Так получилось, что ZenGin в принципе не обучен работать с масштабом, методы скалирования попросту неиспользуются. В чем соль: попытка получить касательный полигон осуществляется хитрой математической формулой. Если говорить очень простым языком, то сам по себе воб содержит только исходные координаты вертексов. А ротация, позиция, скейлинг описываются в matrix4.
Например чтобы найти касательный полигон для воба, который был повернут, берется трассирующий луч, преобразуется в локальные координаты воба и получает локальную точку пересечения. Результат множится на матрицу и возвращается корректная мировая координата.
Но движок не учитывал масштаб и тупо брал исходный. результирующая точка, как и все полигоны воба, домножались на скейл и коллизии тупо уезжали, см видео в посте выше.
Переписывать родные алгоритмы я не стал, а слегка изменил трассирующий вектор. Перед тем, как движок начинает считать коллизии, подготовленный луч делится на квадрат скалирования и поиск пересечений протекает уже пропорционально размеру воба. У меня всё

Спойлер

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

 

[hell9999]

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

 

[Gratt]

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

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

 

[hell9999]

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

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

 

[OddDoc]

Прежде всего, выражаю огромный респектище автору за проделанную работу.

Но хотелось бы и внести несколько собственных, возможно полезных, мыслей по функционалу редактора, пока это ещё возможно.
А именно, по части текстурирования игровых локаций.
Люди, знакомые с редакторами игровых миров на кевйкоподобных BSP-движках, наподобие Radiant, Hammer Editor, наверное меня поймут. И, по моему скромному мнению, работа с текстурированием игровых локаций там выполнена на наиболее удобном к пользователю уровне.
Оговорюсь сразу, опыта работы с оригинальным Спейсером я практически не имею, так как моддингом Zengine ранее не занимался вовсе. Однако, понаблюдав за тем как оно происходит, пришёл к личному выводу что процесс текстурирования уровней довольно таки неудобен и требует довольно большого количества времени.

Итак, как оно выглядит на словах. (Могу сделать подробный "фотообзор", при необходимости позднее, хотя, на самом деле, разобраться лично сможет каждый, ну или глянуть виде в конце ).

На "квейкоподобных" движках, геометрия уровней строится из "брашей" - суть есть аналогов обычных примитивов любого 3Д-редактора, которые комбинируются, режутся и приводятся к построению нужной геометрии.
Текстурирование в соответствующих редакторах производятся во встроенном инструменте.
Условно говоря, порядок работы таков:
1) Берётся инструмент - появляется окно с настройками текстурных координат и кнопка выбора текстуры из библиотеки.
2) При открытом окне инструмента, курсор превращается в пикер, которым можно выделить как отдельный фейс на браше, так и несколько, на одном или группе брашей. Состояние выделения запоминается.
3) При нажатии на выбор текстуры - открывается отдельное окошко с галереей доступных текстур. Присутствуют фильтры по наименованию, свойствам текстуры (имеет ли альфу, анимированная и прочее). Из галереи выбирается нужная текстура. (В теории, сюда же можно добавить и импорт/экспорт текстур)
4) В основном окне инструмента жмётся условная кнопка Assign - текстура применяется к выбранным фейсам (полигонам, в нашем случае).
5) Далее переходим к манипуляторам в основном окне инструмента. Позиционирование - выровнять текстуру относительно сторон фейса, полигона (top, bottom, left, right, center). Разумеется, поворот текстуры относительно нормали полигона или фейса, в градусах. Масштабирование - выбираем степень скейла по сторонам X и Y текстуры. Кнопка Fit, например, для масштабирования текстуры, относительно реальных граней фейса, как с сохранением пропорций самой текстуры, так и без него.
Соответственно, все изменения отражаются в реальном времени, без необходимости дальнейшего подтверждения.

Дополнительно, в этот же инструмент можно вынести редактирование вертексов с собственными настройками (типа Soft Select), в отдельную вкладку окна инструмента. Что логически вполне обоснованно. Ведь мы производим манипуляции с оригинальным мешем игровой локации.

Преимущества достаточно очевидны. Необходимость использования архаичного метода из Спейсера отпадает (хотя, вероятно, стоит сохранить такую возможность для особенно консервативных моддеров). Так же, можно не заморачиваться с предварительным текстурированием в 3Д-редакторах, включая работу с UV редакторами.

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

Спойлер

Спасибо за внимание, товарищи.

 

[alex_draven]

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

 

[OddDoc]

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

В любом случае, расширение базового функционала явно пойдёт на пользу.

 

[Haart]

Хорошо бы еще кнопку, которая делает воб частью меша с теми же координатами.)

 

[MaGoth]

Хорошо бы еще кнопку, которая делает воб частью меша с теми же координатами.)

Интересно, каким образом?
Если это тупо булыжник, то тут все понятно, а если составной, да еще и с чаелдами ?!

 

[Gratt]

Интересно, каким образом?
Если это тупо булыжник, то тут все понятно, а если составной, да еще и с чаелдами ?!

В чем проблема скопировать всю инфу меша в список полигонов мира? Насколько я помню такое даже спакер умеет.

Хорошо бы еще кнопку, которая делает воб частью меша с теми же координатами.)

Только зачем? Не боишься потерять в оптимизации?

 

[MaGoth]

Ну, если спейсер умеет, то вопросов нет..

 

[Haart]

Только зачем? Не боишься потерять в оптимизации?

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

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

Если это тупо булыжник, то тут все понятно, а если составной, да еще и с чаелдами ?!

Не, естественно - воб без наследников. Не, можно и с наследниками, но нафига ? Обычно это или муверы, или мобы, а их переносить смысла особого нет.

Хм, думал сообщения объединятся автоматом...

 

[Vlad_Torop]

Только зачем?

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