akortunov

Да.

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

Она никому нафиг не нужна.

1. Никто никуда от ЕSМ-ов не уйдёт - для этого половину движка переписать надо. Также OpenMW сам себя никак не разовьёт - для этого нужны опытные разработчики от геймдева (например, в том же Godot минимум на порядок больше разработчиков задействовано). Поскольку для поддержания обратной совместимости с Морровиндом приходится тащить тонны костылей и поддержку морально устаревших форматов данных, то для геймдева этот движок в плане разработки игр не особо интересен. Позиционирование OpenMW как независимой программы нужно в основном по правовым причинам (чтобы Беседка не докапывалась). 2. SSD и огромные объёмы памяти есть далеко не у всех, да и даже с SSD старт игры по 5 минут, сохранения-загрузки по 3 минуты и вылеты по Out Of Memory - так себе результат. 3. Я всего лишь обрисовал причины, почему так никто не делает и чем это чревато. Если вас устраивает, что ваши плагины не смогут нормально обработать ни игра, ни редактор, ваше право продолжить разработку, только тогда не жалуйтесь, что движок кривой - он просто не подходит для планируемого вами варианта использования и в обозримом будущем что-то вряд ли изменится.

Ещё раз, оба движка (что оригинальный, что OpenMW) рассчитаны как раз на вручную созданные камерные миры с большой плотностью деталей и событий на единицу площади. Соответственно, сделать РЕАЛЬНО большие миры для этих движков очень сложно чисто технически как раз из-за подхода, используемого для создания и хранения данных. Даже если обойти ограничение на загрузку файлов больше 2 ГБ (которое может быть платформозависимым, кстати), обязательно вылезут другие проблемы: 1. Всё содержимое плагинов грузится в память при старте игры для кэширования. Соответственно, для загрузки файла весом 16 ГБ нужен сопоставимый объём RAM, плюс время запуска будет ограничено временем, которое понадобится компу для чтения и разбора 16 ГБ данных с диска. 2. Удалённый ландшафт обрабатывает весь мир сразу, и он тоже несколько гигабайт памяти при огромном мире есть будет, так что его скорее всего придётся отключать, и ваш большой мир игрок тупо не увидит. 3. Размер сохранений и скорость процесса сохранения зависит от количества посещённым игроком ячеек. Даже на родном мире при полностью обшаренной карте сохранения весят порядка 50 МБ и сохранение идёт секунды три. При росте количества посещённых ячеек объём данных будет расти линейно, скорость сохранения падать тоже линейно. Единственная реальная возможность для создания огромных миров за разумное время без подобных проблем - это процедурная генерация всего подряд, причём львиная доля мира должна быть полностью статичной, чтобы не приходилось хранить состояние и отслеживать изменения для сгенерированного контента, а тупо удалять его, когда в нём отпадает надобность. Но при таком подходе миры как раз получаются пустыми и бессмысленными, поэтому чаще всего его используют для разных планетариев, авиа- или морских симуляторов, когда детали мира не важны, т.к. игра не про них. Так что максимальный размер мира, на который вы реально можете рассчитывать без заточенного под процедурную генерацию движка - это примерно в 16 раз больше по площади (в 4 раза по длине и ширине), чем исходная карта, причём создание этого мира потребует кратно больше работы, к чему вы должны быть готовы.

Кем проведена? Это огромный объём работы. Если кому-то очень сильно нечем заняться, лучше пусть помогает TR или SHOTN разрабатывать - пользы в разы больше будет. Масштабы игры измеряются количеством уникального контента, который игроку новый опыт подарит, а не физическими размерами карты. Можно сгенерировать пустую равнину с деревьями размером 1000х1000 км, но эта равнина по реальному контенту будет уступать одной карте из Готики. Про несовместимость потенциального мода со всем подряд и про техническую корявость подобного решения даже уже не вспоминаю. Если уж совсем невтерпёж по огромным пустым мирам побродить, проще уж ту же Outerra скачать - там движок заточен под создание целых планет на лету без хранения больших объёмов данных. Правда, там реально ничего нет, кроме ландшафта, деревьев и травы.

Да, в нём, на оригинальном движке. Если швы там тоже есть, то проблема однозначно в анвине, а не на стороне OpenMW.

А Tamriel Rebuilt по-вашему как работает? Судя по скрину и по отсутствию жалоб на поведение TR и других ландшафтных модов, скорее всего какая-проблема с софтиной, которая нарезала масштабированный ландшафт на куски. Скорее всего, из-за масштабирования появились ошибки округления, и карта высот не покрывает пограничные ячейки полностью. Работоспособность плагина точно проверялась в Морровинде? Да, и 2 ГБ - это мир на порядок больше Tamriel Rebuilt. Делать его на базе формата ESM - это просто извращение. Для огромных открытых миров обычно используется процедурная генерация мира - никто не будет хранить положение каждого дерева и высоту ландшафта для каждой точки мира в огромном файле. Если есть желание, можно багрепорт создать (обязательно с указанием используемой ОС и ссылкой на скачивание оригинального ESM-файла), только сначала убедитесь, что вы не используете 32-битную ОС или сборку OpenMW.

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

А зачем? Это ведь не мод.

Добавил ссылку. Zini по-прежнему занят какими-то своими делами, пока обходимся без него.

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

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

Ну так проверь. Частичная подсветка слов допускается, но полная имеет бОльший приоритет.

Как обычно на английской версии. @# тупо убираются, вместо этого автоматически ищутся соответствия из top-файлов, а теперь еще и точные названия тем.

Движок не однопоточный, просто в Морровинде используется странный подход к организации моделей с кучей мелких шейпов и кучей отдельных мелких текстур. Изначально это было оптимизировано под древние видеокарты, которые не умели переваривать приличное количество полигонов и большие текстуры. Вот и подумали в Беседке - а давайте поделим модели на много мелких фрагментов и порежем дистанцию обзора, чтобы как можно меньше полигонов рисовать при более-менее нормальной на то время детализации объектов. Потом авторы MGE увеличили дистанцию обзора, и убедили пользователей и плагиностроителей, что 20-30 FPS в игре - это норма. Современные же видеокарты спокойно переваривают миллионы полигонов и 16k-текстуры, и тут уже все упирается собственно в количество шейпов, а не полигонов, и результате при отрисовке какого-нибудь корабля или NPC тратится на порядок больше ресурсов компьютера, чем оно реально надо. Поздние TES-игры, к счастью, используют более крупные шейпы, иначе там бы всё тормозило по-страшному, т.к. модели более детализированные, а отрисовка не параллелится в принципе, эта фича была добавлена только в DirectX12. До плагиностроителей же через 15 лет после выпуска игры наконец-то дошло, что ресурсы игры тоже можно и нужно оптимизировать, благодаря чему появились Morrowind Optimization Patch и Atlas Project. И да, у многих OpenMW работает быстрее, чем MGE с теми же настройками, и использует он по умолчанию 4 потока (основной поток, поток отрисовки, поток предзагрузки и поток генерации навмешей).

Учитывая, что с нашей стороны ничего особо не поменялось, это очень странно.

А что у вас за масштабирование экрана такое странное? Обычная смена разрешения не работает, что ли? Нормальная смена разрешения увеличивает ФПС, если скорость ограничена видеокартой, да, а вот как эти ваши хитрые костыли работают на разных устройствах, вообще непонятно.

Формат ESM-файлов в обозримом будущем никто менять не будет. Как минимум, для этого нужен полнофункциональный редактор.

Да, как обычно.

1. Понятия не имею. 2. На десктопах подойдет любой диспетчер задач. Насчёт Андроида не скажу.

Два набора настроек: [Terrain] distant terrain = true [Camera] viewing distance = 6666 и [Terrain] distant terrain = false [Camera] viewing distance = 6666 На одной и той же сцене сравниваем потребление памяти (через внешний диспетчер задач) и FPS (через внутриигровой профилировщик). Делаем это, естественно, с отключенным V-Sync. Желательно протестировать в разных городах и где-нибудь в глуши.

Желательно и то, и то.

Использует здесь кто-нибудь OpenMW на Андроиде? Там свежие патчи из 0.46 используются? Интересует сравнение FPS и потребления памяти с включенным удаленным ландшафтом с дефолтной дальностью прорисовки (6666) и с такой же дальностью, но с отключенным ландшафтом. На слабых пеках было бы тоже неплохо проверить, кстати.

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