OpenMW или мечты иногда сбываются

[akortunov]

Официальный сайт OpenMW
Страница загрузки
Ссылка на загрузку актуального билда для Win64 (обновляется ежедневно)
 
Баг-трекер

Wiki

Список задач до релиза 1.0

Репозиторий с исходным кодом на GitLab

Discord: OpenMW (в наличии русскоязычный канал)
IRC: #openmw на irc.freenode.net

Полезные ссылки:
Реестр популярных модов для OpenMW с гайдами по установке
Руководство по портированию ретекстуров в OpenMW
OpenMW на Youtube
OpenMW на GitLab
Диздоки планов развития после 1.0
 
Сторонние проекты, основанные на OpenMW:
TES3MP - реализация мультиплеера для OpenMW.

Тема OpenMW на 4PDA - здесь можно найти сборки OpenMW для Android 5+ и гайды по решению проблем.

OpenMW для VR - основан на OpenXR, готовые сборки (устаревшие) есть только для Windows.

Порт на Switch - к сожалению, в настоящее время им никто не занимается.

Что такое OpenMW?

 

OpenMW - это попытка воссоздать игровой движок для популярной RPG TES3 Morrowind, полноценную реализацию всех особенностей игры с открытым исходным кодом. Для того, чтобы вы имели более полное представление о проекте, вот ключевые особенности OpenMW:

• Кроссплатформенность - запуск на Windows (7 или новее), Linux, MacOS X, Android (платформы x86 не поддерживаются).
• Виртуальная файловая система, позволяющая устанавливать моды в отдельные директории, а не засорять Data Files.
• Поддержка сжатых BSA-архивов для экономии места на диске.
• Исправление ошибок системного проектирования: "грязные" GMST записи в плагинах, проблема "удвоения" в сейвах, лимит на 255 плагинов и т.д.
• Улучшенный поиск пути - с помощью статического или динамического (на выбор) построения навигационной сетки на основе геометрии локаций (вместо использования вручную расставленных дизайнерами локаций маркеров).
• Улучшение интерфейса (поддержка TrueType-шрифтов, масштабирования интерфейса и миникарты, поддержка текстур высокого разрешения для элементов интерфейса, редактирования разметки интерфейса с помощью XML-файлов, клавиатурной навигации, поворота камеры с помощью гироскопов и т.д.).
• Улучшение графики (поддержка шейдеров постобработки, динамические тени от объектов, Distant Land (хоть и без генератора LOD-ов), анимированная трава, шейдер воды с поддержкой отражений в реальном времени, улучшенная система освещения без лимита в 8 источников света на объект, улучшенная система тумана и многое другое).
• Улучшенная поддержка анимаций (возможность использовать отдельные файлы для отдельных групп анимаций, возможность добавлять кастомные кости в скелеты, возможность задать новые анимации для топоров, булав и кинжалов, поддержка анимаций открытия-закрытия контейнеров).
• Начальная поддержка Lua-скриптов для расширения возможностей плагиностроения.
• Поддержка ICU для локализации Lua-скриптов, шейдеров постобработки и элементов интерфейса.
• Использование дополнительных ядер процессора для фоновых задач (например, для предварительной загрузки локаций для бесшовного перемещения по игровому миру или для обработки коллизий объектов).
• Отсутствие лимита 4Гб на адресуемую процессом игры память из-за поддержки 64-битных архитектур.
• Намного меньшее количество вылетов в сравнении с оригинальным движком.
• Возможность модификации движка под свои нужды (например, довольно популярен TES3MP - форк OpenMW с поддержкой мультиплеера).

OpenMW выпущен под лицензией GPLv3, весь исходный код написан с нуля.

Нужен ли оригинальный Morrowind для OpenMW?

И да, и нет.

ДА. Прежде чем использовать OpenMW, вы должны легально приобрести и установить Morrowind на ваш компьютер. OpenMW воcпроизводит только техническую сторону игры, и не содержит в себе каких-то материалов, защищенных авторским правом. Используются только данные уже установленной игры, либо с установочных файлов с диска или цифровой копии игры.

НЕТ. OpenMW - самостоятельный игровой движок. Он может быть базой для тотальных конверсий, не использующих файлы Morrowind. В качестве примеров можно привести Robowind Construct и StarWind.

Каково текущее состояние проекта?

Статус

OpenMW уже находится в состоянии "бета": основные функции реализованы, идет работа по оптимизации и паритету с MGE и MWSE. Кроме этого есть ряд проблем, в основном с физикой и поддержкой модов, использующих баги и недокументированные возможности оригинального движка.
OpenMW играбелен (можно нормально пройти сюжет игры и аддонов, ветки гильдий и т.д.), хотя и местами уступает MGE в качестве графики, но выигрывает по стабильности, а на многих машинах и по производительности и скорости загрузки локаций.

Какие технологии вы используете?

OpenMW построен с использованием различных библиотек и инструментов с открытым исходным кодом:

• Языки программирования: C++ (стандарт C++17 с частичной поддержкой C++20), GLSL, Lua
• Графика: OpenSceneGraph
• Физика: Bullet
• Звук: OpenAL
• Ввод-вывод: SDL2
• Интерфейс: MyGUI
• Поиск пути для ИИ: Recast & Detour

 
Я не программист, как я могу помочь проекту?

 

1. Можно просто играть и отсылать багрепорты

2. Можно тестировать разрабатываемый код, до того, как он попадёт в основную ветку. Там же можно вести обсуждение и предлагать изменения.

3. Можно тестировать моды. Основная цель - выявить проблемы с совместимостью.

4. Можно исследовать механики оригинального движка, особенно актуально в области тонкостей работы скриптов.

5. Можно обновлять Wiki.

6. PR тоже не помешает, особенно если он позволит привлечь тестировщиков и плагиностроителей.

7. Можно донатить разработчикам на Patreon'е:

• psi29 — проджект лид, поможете закрыть траты на хостинг
• Capostrophic — тысяча и один фикс + вагон фич
• AnyOldName3 — тени в OpenMW
• David Cernat — работа над TES3MP

Изменено 30 мая, 2023 пользователем akortunov

[Марк К. Марцелл]

Так *скрипнул памятью*. За давностию лет могу ошибаться, но если нет, то:

Так когда фактически зайдет солнце с такими настройками:

Время восхода/захода не изменится. Только длительность нарастания/угасания сумерек с соответствующим плавным переходом от одной световой схемы (день/ночь) к другой (ночь/день).

Чем Pre и Post отличаются?

Для заката, например - сколько продлятся сумерки до Sunset Time и после него.

почему опции сгруппированы по четыре штуки.

Сумерки до восхода/после восхода, сумерки до заката/после заката для каждого типа освещения.

[Capostrophic]

magamo довёл до ума старую версию тумана от visvaldas так, чтобы его можно было использовать без пересборки движка.

Скриншоты (не мои) 1, 2, 3.

Краткая инструкция по установке на винде:

1) скинуть файлы с заменой в %папка OpenMW%/resources/shaders

2) добавить следующее в settings.cfg (%учетная запись%\Документы\My Games\OpenMW):

[shaders]
force shaders = true

опционально, но желательно:

3)

[Camera]
viewing distance = 66666 # твикать по желанию. обычно эта настройка уже существует в файле; максимум слайдера равен 6666
[Terrain]
distant terrain = true # удаленный ландшафт. генерация лода для земли, без статиков.

 

Испытал. Туман очень плотный. В новом шейдере он должен быть поразреженней, но когда ж он ещё выйдет.

Есть и несколько других недочётов, но они относительно незаметные.

Изменено 22 августа, 2017 пользователем Capostrophic

[morrow]

magamo довёл до ума старую версию тумана от visvaldas так, чтобы его можно было использовать без пересборки движка.

Скриншоты (не мои) 1, 2, 3.

Краткая инструкция по установке на винде:

1) скинуть файлы с заменой в %папка OpenMW%/resources/shaders

2) добавить следующее в settings.cfg (%учетная запись%\Документы\My Games\OpenMW):

[shaders]
force shaders = true

опционально, но желательно:

3)

[Camera]
viewing distance = 66666 # твикать по желанию. обычно эта настройка уже существует в файле; максимум слайдера равен 6666
[Terrain]
distant terrain = true # удаленный ландшафт. генерация лода для земли, без статиков.

 

Испытал. Туман очень плотный. В новом шейдере он должен быть поразреженней, но когда ж он ещё выйдет.

Есть и несколько других недочётов, но они относительно незаметные.

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

[Capostrophic]

Богатые на события была пара недель... В любом случае, вот что ещё будет к 0.43.

 

Кортунов:

• При копировании игрового текста в буфер обмена не будут копироваться цветовые теги, портящие разметку.
  
• Развеять теперь можно только эффекты заклинаний.
  
• Функции GetPCRunning и GetPCSneaking теперь проверяют, действительно ли Нереварин бежит или крадётся, а не просто проверяют, что он в соответствующих режимах.
  
• ИИ теперь использует эффекты предметов, зачарованных эффектами, действующими "при использовании"
  
• Добавлен порог повороту к цели
  
• Более адекватно оценивается, будет ли законным использование предмета, при включенном применении специального цвета к наведенному на предметы с владельцами перекрестью и всплывающей подсказке: теперь они не будут краснеть при наведении на активаторы, кровати и двери (нелегален только взлом). Для проверки легальности сна на предмете с "кроватным" скриптом нет простого решения.
  
• Больше нельзя подбирать лут с неписей и существ, которые на момент анимации смерти были в бою (даже если были убиты в один удар). Это сделано для соответствия оригинальному поведению и позволяет избежать проблем с уничтожением трупов невовремя. Со спутников, в том числе призванных даэдра, которые прощают первые три удара, убитых за эти три удара, всё ещё можно снимать лут (если они не вошли в состояние боя), но это можно отключить. Тела призванных существ пропадают через 200 миллисекунд.
  
• Меню добавления пометки на карту и меню изменения описания класса теперь непрозрачны.
  
• ИИ теперь будет призывать только одно (сильнейшее) существо за раз, как в оригинале, иначе он потратит всю ману на каждое заклинание призыва существа в арсенале.
  
• Многостраничные заметки в дневнике теперь переносятся правильно.
  
• Игрок теперь не сможет менять оружие или заклинания во время каста заклинаний или атаки, а также менять в это время оружие на отмычку или щуп и разэкипировывать оружие. Анимацию атаки всё ещё можно прекратить, если сама атака начата не была.
  
• ИИ будет учитывать свой навык зачарования при выборе зачарованного оружия.
  
• На шкалах усталости показываются отрицательные значения.
  
• При снятии оружия/инструмента анимация атаки игрока сбрасывается.
  
• Проигрывается только одна копия конкретного звука на объекте за раз, при начале нового прошлый прекращается (как в оригинальном движке).
  

h313:

• Более справедливое распределение музыкальных треков.
  

Aesylwinn:

• В редакторе теперь можно перезагружать все ресурсы.
  
• Папка Video по мнению редактора называлась Videos. Исправлено. Баг не замечался годами.
  
• Исправлены многие вылеты при изменении путевых сеток.
  
• Исправлены значения по умолчанию фильтрации топиков.
  
• В процессе: просмотр и редактирование записей текстур ландшафта.
  

Loriel и hristoast:

• Мелкие исправления документации.
  

AnyOldName3:

• Добавлен файл EditorConfig, чтобы некоторые текстовые редакторы использовали традиционное для кода OpenMW форматирование.
  
• Файлы aps Visual Studio 2017 теперь игнорируются git, чтобы никто их случайно не залил в свою ветку и затем в pull request.
  
• Символ # в именах файлах плагинов теперь не будет портить отображение текста в загрузочных экранах.
  

scrawl:

• Для кэшированных ресурсов реализована функция releaseGLObjects
  
• Реализованы lightmode и vertexmode в NiVertexColorProperty; теперь будут правильно подсвечиваться окна в модах по типу Windows Glow.
  
• Несуществующая покраска вершин заменяется белым цветом.
  
• При прикреплении частей тела проверяется наличие узла Geometry.
  
• Ограничение частоты кадров теперь действует во всех случаях.
  
• На узле, содержащем StateSet, устанавливается шейдер.
  
• Animation::mSkeleton теперь правильно назначается на существах вне диапазона обработки, что повысит производительность.
  
• Переструктурирована двойная буферизация RigGeometry
  
• При неудачном удалении ноды логируется предупреждение
  
• Собственная реализация MorphGeometry; теперь нет зависимости от osgAnimation. Не нужны грязные хаки для некоторых фич.
  
• Флаг cullingActive на конце пути к узлу теперь можно проверить.
  

я сам:

• Теперь функции выяснения, знает ли игрок магический эффект у зелья или ингредиента, знает, что у зелья может быть вплоть до 8 магических эффектов, которые могут быть выяснены игроком, если у него достаточно высокий уровень алхимии; по 2 эффекта за каждые 15 уровней навыка. Раньше подразумевалось, что у зелья может быть только 4 эффекта.
  

Но заслуга не моя, я просто скопипастил код из замечания некоего Владимира Улиско. Так-то.

[akortunov]

Добавлен порог повороту к цели

 

Если что, здесь имеется в виду AiFollow. В Морровинде последователь начинает поворачиваться к лидеру, если угол между ними больше 45 градусов.

В OpenMW они же поворачивались строго к лидеру каждый кадр вне зависимости от угла. В ситуации, когда непись следует за другим неписем, это вело к дерганой анимации у последователя.

Изменено 3 сентября, 2017 пользователем akortunov

[Broken von Skull]

akortunov, а что вообще в планах на будущее? И большое спасибо за весь ваш вклад в OpenMW.

[akortunov]

akortunov, а что вообще в планах на будущее?

 

В первую очередь, продолжу дрессировать ИИ, в основном, боевой.

А вообще, сейчас основная проблема ИИ - это простецкий алгоритм обнаружения и обхода препятствий, который не умеет обнаруживать обрывы, и пытается обойти препятствие, только когда персонаж уже две секунды бежит на месте в стену.

 

Есть также кое-какие идеи по реализации недостающих отладочных скриптовых функций и доработке погоды.

 

 

И большое спасибо за весь ваш вклад в OpenMW.

Да особо и не за что, там изменения в основном мелкие.

Изменено 3 сентября, 2017 пользователем akortunov

[Ao3]

Это можно будет сделать разный цвет у рек в зависимости от типа почвы в регионе? Офигенно же.

 

Да что ж это за свиньи в Балморе живут, природнадзора на них нет! Одай в сточную канаву превратили.

Изменено 3 сентября, 2017 пользователем Ao3

[akortunov]

• Более справедливое распределение музыкальных треков.
  

 

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

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

[Broken von Skull]

А вообще, сейчас основная проблема ИИ - это простецкий алгоритм обнаружения и обхода препятствий, который не умеет обнаруживать обрывы, и пытается обойти препятствие, только когда персонаж уже две секунды бежит на месте в стену.

Ага, помню, что вы спрашивали про steering behaviour на форуме OpenMW.

Есть же разные библиотеки типа OpenSteer или SteerSuite. Или не вариант?

[akortunov]

Есть же разные библиотеки типа OpenSteer или SteerSuite. Или не вариант?

 

Вариант, но не очень хороший - придется тащить в OpenMW лишние зависимости.

К тому же, в классическом виде эти алгоритмы рассчитаны на двумерный мир. Неизвестно, как они будут вести себя в OpenMW (скорее всего их придется обрабатывать напильником).

 

Судя по отзывам в Интернете, самый надежный вариант при перемещении на большие дистанции и при обходе больших неподвижных препятствий - это варианты алгоритма A*. При обходе же небольших препятствий и движущихся препятствий (например, персонажей) как раз можно попытаться использовать steering.

Проблема в том, что Bethesda в свое время добавила маловато путевых точек в игровой мир (разработчики ориентировались на процессоры типа Pentium III). Вот и получается, что поиск пути работает не очень эффективно.

 

Отдельная беда с обнаружением препятствий. По-хорошему, надо кастить минимум три луча для каждого персонажа: два вперед, с левого и правого края collision box'а (чтобы обнаруживать препятствия спереди), и один куда-то вниз (чтобы обнаруживать обрывы). Но raycasting - это достаточно тяжелая операция в OpenMW, могут быть тормоза в локациях с большим количеством персонажей.

[Broken von Skull]

Навмешы бы.

На форуме OpenMW как-то заходила речь об их поддержке, но дальше слов дело не продвинулось.

[Capostrophic]

scrawl о лодах

 

Дальние объекты

 

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

 

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

 

Азы

 

Первый вопрос стоит в том, прегенерировать (и/или кэшировать) LOD'ы до начала игры, или же создавать всё налету (как ландшафтовый движок). Я считаю, что генерация налету очень даже возможна и наш лучший выбор — при смене модов не нужно удалять кэш, и когда мы используем много различных страниц на разных уровнях детализации в зависимости от местонахождения игрока, генерация всего заранее была бы непозволительно требовательной.

 

Базовая реализация не должна быть слишком сложной, если использовать большинство идей/кода удалённого ландшафта (например, древо квадров, вид и как работает предзагрузка). Прирост в производительности по сравнению с загрузкой ячеек как обычно возникнет благодаря возможности игнорировать физику, NPC, частицы и мелкие объекты. Кроме того, при оптимизационном проходе, объединяющем объекты (обычно мы этого делать не можем, потому что они всегда двигаются) должно сильно помочь.

 

Игнорирование маленьких объектов приводит к дилемме: нам нужно знать размер меша до того, как мы его загрузили, но чтобы узнать его размер, нам нужно его загрузить. То есть нам всё равно придётся всё загружать. Чтобы минимизировать влияние этого, я предлагаю кэширование в файл "файл меша -> размер/bounding box", чтобы нам не пришлось при каждом запуске игры загружать все меши.

 

LOD мешей

 

"Решение" номер один тут вовсе ничего не упрощать (кроме проведения оптимизационного прохода для сведения нод). Ведь Морровинд игра старая, и его меши уже низкополигональные по сегодняшним стандартам. Так что перед реализацией любого безумия я предлагаю использовать всё как есть.

 

Тем не менее, для очень высоких расстояний рендеринга и/или высокополигональных модовых мешей какая-то форма упрощения всё ещё потребуется. Это будет сложно, потому что какие-то меши не могут быть ещё сильнее упрощены, а ещё мы не знаем, какие меши должны быть гладкими (органические) или твёрдыми. Подозреваю, что это будет включать множество проб, ошибок и эвристики. Но нашей целью точно будет отсутствие белых/чёрных списков и ручных параметров для каких-то мешей, и чтоб всё работало "из коробки". В любом случае, в osg есть класс Simplifier, который уже более-менее отправная точка (но нужно применить коммит osg a13b66135f826688acb860fc7f0f0c911435645d, чтоб он заработал).

 

Альтернативный метод упрощения — использование спрайтов. Хороший пример этой техники — страничная геометрия в Ogre3D. Этот метод в целом прекрасно работает с деревьями, листвой и камнями, но не с другими мешами. Должно быть возможно использовать какую-то эвристику для выбора метода упрощения (например, если модель неизменна по Z-координате и использует прозрачность, это наверняка дерево или листва).

 

Заметьте, что в OSG есть класс Impostor, но возможности группами их собирать нет, так что делать нам придётся свой.

 

Текстурный LOD

 

Как и указано выше, нужное нам количество LOD'а ещё нужно предвидеть. Но я подозреваю, что текстуры могут быть большей проблемой, чем вершины. Потенциальная оптимизация — создание атласов текстур (другими словами, сведение нескольких текстур в одну, а затем использование координат UV для выбора правильной текстуры для каждого меша).

 

Типичная проблема с атласами такова, что мы не знаем, какие текстуры будут использоваться вместе и в какое время. Но для удалённых объектов мы знаем — они редко движутся относительно игрока — так что текстурные атласы могут быть в этом случае хорошей техникой. Мы можем создавать один или более атлас на каждый узел древа квадов. Единственная проблема — обработка "замощённых" (прим. меня — может, мудрю, и тут просто имеются в виду повторы) текстур/сеток. Интересно, как это делает MGE?

 

В osg есть TextureAtlasVisitor. Я его однажды испытал, и он не заработал правильно, но я мог что-то сделать не так. А ещё была проблема с обработкой Drawables, с тех пор исправленная (изменения всё ещё нужно будет применить к вашей установке OSG).

 

Включение/выключение дальних объектов

 

Несколько людей спрашивало, будет ли в OpenMW та же проблема, что и в MGE, когда объекты, динамически отключаемые/включаемые скриптами во время выполнения, не будут получать обновленные LOD'ы. Теоретически это можно решить очень легко, если принять то, что FPS немного просядет во время пересоздания LOD'ов. Хотя нужно заметить, что могут остаться проблемы со скриптами, выполняемыми только во время обновления ячеек (как случается и с домами игрока от линеек великих домов, насколько я знаю). В таком случае объект был бы изначально включенным, пока вы не заходите в ячейку. Это может быть с лёгкостью исправлено мододелами: нужно только добавить скрипт, отключающий объект в начале игры.

Изменено 6 сентября, 2017 пользователем Capostrophic

[Capostrophic]

Багтрекер слегка реформирован. Подробнее здесь. Вкратце, теперь будет так со следующими версиями:

• На текущий релиз назначаются срочные проблемы, проблемы, над которыми уже работают, и проблемы, для которых есть ясное решение. Нонсенса типа неподтверждённых багов там больше не будет.
  
• На 1.0 назначаются проблемы, которых нет в оригинальном движке и которые требуется решить до релиза 1.0.
  
• На openmw-future назначаются проблемы, которые либо есть в оригинальном движке, либо не нужны для решения для "полной реализации Morrowind.exe".
  

После 1.0 потребуется другое расписание, но это на решение позже.

Ещё было подчищено немного репортов.

 

Zini хотел начать релизный процесс 0.43.0 на этой неделе, но возможно повторение ситуации с 0.42.0, так как Atahualpa опять занят аж до середины октября и не может делать никому не нужные видео. Думаю, ноябрьский будет релиз (Дестинд предсказывал в новом новостном посте так же).

 

Мой ник теперь есть в списке авторов OpenMW; кроме упомянутого фикса getKnownEffects, я добавил лёгкую (до точки нулевого эффекта) оптимизацию, исправив скравлов мелкий косяк, допущенный при оптимизации анимации существ (теперь карта нод и при анимации существ правильно кэшируется). Ещё изменил написание комбинаций клавиш с использованием контрола; теперь будет Ctrl+чётотам, а не Ctl+чётотам, что должно быть резоннее. scrawl написал что-то на эльфийском по поводу того косяка и принял реквест. Ну ладно.

 

AnyOldName3 штурмует тени.

 

Как обычно, очередные добавления к 0.43.0.

Кортунов:

• Максимальный уровень для используемых сообщений на левелапах ("...и вдруг, после событий последних нескольких дней, вы наконец-то поняли, что живы.") теперь не ограничен. Раньше он был 20.
  
• Стихийные щиты теперь учитываются функциями скриптов GetResist и SetResist.
  
• На существ в бою будут нападать не все стражники в пределе обработки ИИ, а только в радиусе fAlarmRadius (30 метров).
  
• При вычислении соответствования требований к рангу используются базовые значения навыков.
  
• Если при варке зелия повысился навык алхимии, изменения значений примутся немедленно, и следующее зелье уже будет слегка лучше.
  

scrawl:

• Пара регрессий исправлена.
  

Мирослав Ремак:

• Для соответствования оригинальному поведению, при отсутствовании текстуры для иллюстрации в книге не будет показываться ничего -- а не розовый прямоугольник. При этом логируется предупреждение. В Tribunal есть место, где это важно.
  

Ну и ещё пара фиксов, которые скорее всего попадут в 0.43.

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

[akortunov]

Ну и ещё пара фиксов, которые скорее всего попадут в 0.43.

А может, и не попадут: scrawl'у не нравится используемый в этих фиксах метод.

Сам он хочет, чтобы игрок переключался между интерфейсными кнопками с помощью клавиши TAB и активировал выбранную кнопку с помощью клавиши ПРОБЕЛ.

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

Изменено 11 сентября, 2017 пользователем akortunov

[Capostrophic]

[akortunov]

Еще пара скриншотов:

 

 

 

Справедливости ради стоит отметить, что чаще всего тени глючат или отрисовываются в воздухе, но работа движется (в этой ветке: https://github.com/A.../osgshadow-test).

Изменено 21 сентября, 2017 пользователем akortunov

[akortunov]

Новый разработчик crassell решил реализовать вид из-за плеча. Вот как-то так:

 

 

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

Этих изменений пока нет в основной ветке.

Изменено 21 сентября, 2017 пользователем akortunov

[Scarab-Phoenix]

А нельзя ли лук переложить сразу в левую руку, как и должно быть у нормальных людей?

[akortunov]

А нельзя ли лук переложить сразу в левую руку, как и должно быть у нормальных людей?

 

Если кто-то переделает под левую руку анимацию атаки/прицеливания/бега под левую руку, то можно.

Вот только неизвестно, какие потом здесь проблемы вылезут.

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

[usolo]

Какие новости с фронтов?

И как вообще ведет себя крайняя сборка, скажем, на офисном ноуте? Как там с производительностью, с критическими багами, играть с которыми неприятно, с готовностью основного функционала?

[akortunov]

Какие новости с фронтов?

 

Чиним баги. Есть прогресс по теням. Релиз 0.43 не раньше ноября (опять видео).

 

И как вообще ведет себя крайняя сборка, скажем, на офисном ноуте?

 

OpenMW сейчас плоховато распараллелен, и работает довольно медленно на мобильных процессорах, даже на i7.

На персональных компьютерах ситуация лучше, т.к. там выше удельная производительность на ядро.

Для сравнения:

i7-3632QM + GT640M: 20-40 fps во внешних ячейках (куча графических реплейсеров, шейдер воды отключен).

i7-3632QM + GT640M, OpenMW с хакнутой физикой (30 обработок в секунду вместо 60): 40-50 fps во внешних ячейках (те же условия).

i7-7700 + GTX1050 2GB: 55-60 fps (все настройки на максимуме).

Это для обычного Морровинда. С Tamriel Rebuilt или Morrowind Rebirth fps будет ниже.

Если под офисным ноутом имеется в виду нечто с интегрированной графикой и Celeron'ом вместо процессора, то все плохо.

 

Критических багов (например, битых сохранений, стабильных вылетов) пока не видел, играть можно.

Но нужно обратить внимание вот на что:

1. Могут не работать некоторые скрипты (например, в квесте с театром в Морнхолде). Обычно глючный скрипт можно быстро поправить через редактор.

Также рекомендую использовать GFM - он устраняет часть таких проблем.

2. Сторонние плагины поддерживаются далеко не все. Обычно проблемы в этих случаях:

а) Плагин зависит от сторонних бинарных хаков (MWSE, MCP, MWE)

б) Плагин использует баги и недокументированные возможности оригинального движка, которые сложно воспроизвести (например, моды с анимированным транспортом)

в) Плагин использует дополнительные уровни текстур в моделях (например, карты нормалей - в OpenMW их не надо прописывать в модель). К таким плагинам относится множество графических реплейсеров (тот же MGSO).

Такой мод обычно можно адаптировать к OpenMW.

Изменено 26 сентября, 2017 пользователем akortunov

[usolo]

Спасибо огромное за инфо!

Грустно, что пока что все так с производительностью. Интересно - стоит ли надеятся на большую оптимизацию или более широкий выбор настроек графики? ИМХО, Морроуинд нужен не только для мощного железа, но и для довольно скромного тоже.

[akortunov]

Интересно - стоит ли надеятся на большую оптимизацию или более широкий выбор настроек графики?

 

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

 

Как по мне, сейчас OpenMW делает кучу избыточных вычислений на каждый кадр. Хороший пример - та же физика.

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

Слайдеры расстояния видимости и обработки ИИ тоже помогали.

 

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

Если что, профилировщик открывается двойным нажатием F3.

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

[edwvee]

OpenMW с хакнутой физикой (30 обработок в секунду вместо 60):

Где такой взять?

Что-то вообще произошло с оптимизацией за лето? Я вижу по теме, что фиксят всякие логические баги, но об основной проблеме - производительности нет упоминаний. Поиграть бы в игру с дистант лэндом или аналогом в 60фпс. Выставлял дистант терейн и + одна-две клетки в радиусе персонажа - та же производительность, что в мге хе с дистант лэндом. Притом да, ближайшие клетки детализированы, но вдаль видно меньше. Уже начиная с +3х клеток полные тормоза.

Как по мне, сейчас OpenMW делает кучу избыточных вычислений на каждый кадр. Хороший пример - та же физика.

Да пусть делает, лишь бы больше параллелизма.

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

Слайдеры расстояния видимости и обработки ИИ тоже помогали.

Разве ИИ сильно влияет? Все в геометрию обычно упирается. ИИ какие-то крохи в современных играх тратит.

Изменено 26 сентября, 2017 пользователем edwvee