X-Ray Oxygen, (x64) Why not? Опции

[ForserX]

X-Ray Oxygen 1.7f
«X-Ray Oxygen» - это OpenSource проект по рефакторингу движка X-Ray, представляющий собой платформу для разработки игр или же модификаций. Проект не имеет мультиплеера, так же он неподдерживает 32 битные системы. Кроме рефакторинга, у нас есть расширенный скриптовый функционал для создания более гибкой скриптовой логики, так же различные улучшения в оружейной части, включая поддержку новых звуков и анимаций, если таковые имеются. Особую роль для нас играет графическая составляющая, какой же прок от движка в 2018 годе без хорошей графики ? Помимо этого, мы стараемся задействовать как можно больше функционала вашего процессора, из-за чего мы стараемся использовать различные наборы инструкций, таких, как SSE 4.1. Так же основную роль в наше время играет многопоточность, о которой мы стараемся не забывать.

К нам в проект требуются: C# программисты, C++/CLI разработчики, HLSL программисты, не помешали бы OpenGL/Vulkan разработчики, которых в ST-Community практически нет, а жаль... Если вы желаете помочь проекту, свяжитесь со мной или же воспользуйтесь системой Issues/PR на GitHub.

Основные изменения

• Полностью рабочий x64
• Переделанная Mixed конфигурация (для разработчиков)
• Удалёно много ненужного кода, в том числе стороннего API и мультиплеерного.
• Многоядерная обработка потоков
• Многопоточность
• Новая звуковая система: OpenAL Soft + EFX
• C# Скриптинг (Spectre Script Engine)

Планы

• Поддержка DirectX 12
• Обновление графической составляющей
• Улучшение оптимизации
• xAudio2

Полезный инструментарий (x64)

Все ссылки ниже имеют документацию
Плагин для LightWave 2015-2019
Плагины для Maya 2019

xrAI без ограничений на AI-Map
xrDO_Light с расширенным набором опций
xrLC Многопоточный с экспериментальным просчётом на GPU

Фикс для AE под 127 костей
Редактор погоды под 1335 релиз

Распаковщик .efd файлов
Растеризатор шрифтов в формат сталкера
Генератор солюшенов для Spectre

Engine | Source | News | Changelog | Наш сайт!

[WARNING!] Для работы данного проекта требуется C++ Redistributable for VS 2019 x64.
[WARNING!] Нет статического освещения. Бугага!
[WARNING!] Нет поддержки WinXP


Сообщение отредактировал ForserX - 12.06.2021, 00:13

[Willy]

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

Даже у long long количества ячеек есть предел (4294967296 ячеек, если быть точным). А тут потенциально бесконечная сетка, ограниченная размерами жесткого диска, на котором лежит файл AI, ведь ноды будут подгружаться и выгружаться согласно передвижению актёра.

Можно и компилятор стеки выбросить, чтобы никто потом не плакал "ой, на моём Pentium III не хватает моих 256 Mb RAM для компиляции сетки 30х30 км" и генерировать сразу готовую сетку в SDK (или заставить движок кушать "сырую" сетку -- тут уж как будет)

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

Сообщение отредактировал Willy - 25.01.2016, 17:44

[abramcumner]

А тут потенциально бесконечная сетка, ограниченная размерами жесткого диска,

Создание потенциально бесконечной сетки потребует потенциально бесконечного времени. Играть-то когда?

[Willy]

Создание потенциально бесконечной сетки потребует потенциально бесконечного времени. Играть-то когда?

Создание потенциально бесконечного мира Зоны потребует потенциально бесконечного моделлинга. А играть-то когда?

Ответишь на этот вопрос -- примерно таким же будет ответ и на вопрос, который задан мне.

[abramcumner]

Создание потенциально бесконечного мира Зоны потребует потенциально бесконечного моделлинга. А играть-то когда?
Ответишь на этот вопрос -- примерно таким же будет ответ и на вопрос, который задан мне.

Ответ простой - потенциальные бесконечности кроме фантазий больше нигде не встречаются. Есть подозрения, что в3 и ф4 уместятся в вышеупомянутую сетку

[Willy]

Ответ простой - потенциальные бесконечности кроме фантазий больше нигде не встречаются. Есть подозрения, что в3 и ф4 уместятся в вышеупомянутую сетку

Как насчет процедурно генерируемой Зоны и процедурно генерируемой сетки, соответственно?
Это вполне реально.
Создавать вокселы, добавлять заранее подготовленные юниты (постройки, пропы) а потом сглаживать поверхность -- это даже на Unity уже реализовано и успешно продается года два или даже больше.

Но это уже на МайнСталкер какой-то похоже. Хотя, я бы разок сыграл.

[abramcumner]

Как насчет процедурно генерируемой Зоны и процедурно генерируемой сетки, соответственно?
Это вполне реально.

Заклинание "процедурно генерируемая" делает предложение в 10 раз более убедительным? Или помогает выполнить потенциально бесконечный цикл за 10 секунд?
К сведению сетка и сейчас "процедурно генерируется" Ручками ноды никто не расставляет.

Ну и еще заклинание:

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

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

Сообщение отредактировал abramcumner - 25.01.2016, 18:54

[Willy]

abramcumner, а зачем потенциально бесконечный цикл, если можно выполнять функцию, которая "достроит" мир по мере необходимости на основе полученных данных (рандом, положение актёра, время, что_вам_будет_еще_угодно) и вызывать ее при перемещении / по интервалу времени / каждый фрейм рендера / по желанию ? Да и не обязательно выполнять эту функцию в основном потоке -- можно вынести в параллельный поток именно под эти нужды, чтобы можно было играть во время генерации.

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

И это будет вполне играбельно.

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

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

[abramcumner]

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

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

abramcumner, а зачем потенциально бесконечный цикл, если можно выполнять функцию, которая "достроит" мир по мере необходимости на основе полученных данных (рандом, положение актёра, время, что_вам_будет_еще_угодно) и вызывать ее при перемещении / по интервалу времени / каждый фрейм рендера / по желанию ? Да и не обязательно выполнять эту функцию в основном потоке -- можно вынести в параллельный поток именно под эти нужды, чтобы можно было играть во время генерации.

А можно просто подойти к монолиту и сказать: "хочу сталкер2"

Ты как-то прыгаешь из стороны в сторону. Если ты уже на лету все генерируешь, то размер сетки вообще не важен - пусть она будет хоть 100х100 - ты же ее нагенерируешь тут же.

[RedMagic]

* Если все выше получится, можно подумать о поддержке огромных локации

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

На самом деле можно сделать поддержку открытых локаций которая будет работать на любом железе. Другое дело что реализация подобного механизма потребует немало усилий, сейчас уже почти прошли те времена когда разработчики боролись за каждый килобайт свободной памяти.
На данный момент почти все игры с открытым миром используют много различных уловок которые позволяют снизить нагрузку. Кому интересно - можете почитать статьи по разбору мира GTA 5, и системы рендеринга (пример уловки: когда ГГ находится в автомобиле, то на улице чаще появляются автомобили того же типа что и игрока. Это позволяет выгрузить лишние модели и освободить память), ссылок сейчас не скину, помню точно только то что на хабре была статья про рендеринг GTA 5.
PS: Может для кого-то это будет открытием, но вот еще одна оптимизация ресурсов которую применили в Super Mario. К сожалению сейчас такого почти не наблюдается, обычно разработчики даже не заботятся об оптимизации т.к. вычислительная мощность игрового ПК позволяет "расслабится".

Ответ простой - потенциальные бесконечности кроме фантазий больше нигде не встречаются. Есть подозрения, что в3 и ф4 уместятся в вышеупомянутую сетку

Как насчет процедурно генерируемой Зоны и процедурно генерируемой сетки, соответственно?
Это вполне реально.
Создавать вокселы, добавлять заранее подготовленные юниты (постройки, пропы) а потом сглаживать поверхность -- это даже на Unity уже реализовано и успешно продается года два или даже больше.

Но это уже на МайнСталкер какой-то похоже. Хотя, я бы разок сыграл.

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

[Willy]

Так все-таки грузить зону по кусочкам это правильно или нет? А то я уже запутался.

На вкус и цвет фломастеры разные ©
Но потоковая подгрузка мира без минутных пауз и "Клиент: Синхронизация" нравится гораздо бóльшему количеству людей.

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

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

А потом оказывается, что сетка уже процедурно-генерируемая. А бесшовная зона уже подгружается чанками.

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

А сетка генерируется той процедурой, которая вообще находится в SDK и берет явно не те структуры ("сырые" -- на основе .object-ов же генерируется сетка), которые используются в самом движке (скомпилированная геометрия мало похожа на формат .object)

====

процедурно-генерируемая

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

Ты как-то прыгаешь из стороны в сторону. Если ты уже на лету все генерируешь, то размер сетки вообще не важен - пусть она будет хоть 100х100 - ты же ее нагенерируешь тут же

Я прыгнул в сторону только один раз на том моменте, когда мы с тобой договорились, что мир будет генерироваться "на лету", а не заранее моделироваться 3D-Artist'ом. Далее все сообщения несут в себе мысль в ключе "Если бы мир генерировался процедурой прямо во время игры". Как геометрия, так и AI-сетка может генерироваться в процессе игры в отдельном потоке (а не в SDK руками, а потом еще компиляцией нагенерированого в xrAI). И в таком случае -- да, размер сетки и геометрии будет ровно таким, каким необходимо и задано в коде движка.

STALKER2011x, спасибо за объективность.
upd. Насчет органичности вписывания, типов структур и прочего.
Есть Indy-игры, в которых заранее подготовленные 3D-модели частей уровня складываются в одно целое в виде случайных комбинаций (пускай тот же SCP:Containment Breach). Если бы была чанковая подгрузка в процессе игры, то можно было бы поступить именно таким образом -- подставлять готовые структуры на процедурно генерируемый в процессе игры террейн. Я не думаю, что это слишком сложно.

Сообщение отредактировал Willy - 25.01.2016, 19:43

[Trollz0r]

Едрить фантазёров понабежало

[abramcumner]

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

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

А сетка генерируется той процедурой, которая вообще находится в SDK и берет явно не те структуры ("сырые" -- на основе .object-ов же генерируется сетка), которые используются в самом движке (скомпилированная геометрия мало похожа на формат .object)

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

[Willy]

abramcumner,

===

Очень сомнительно Ты просто намешал кучу терминов в кучу.

Вам виднее, магистр. У моего провайдера Википедия работает в отличии от вашего.

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

Нужно будет сменить алгоритмы A-Life на те, которые не будут использовать сетку (алгоритмы Дейкстры и А*).
Проще на ходу сгенерировать сетку, как это делает SDK и "научить" движок использовать "сырую" нескомпилированную сетку вместо той, которую предоставляет нам xrAI.

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

Стриминг я упоминал только в ключе как раз-таки загрузки готовой геометрии в самом начале. При создании "на лету" я рассказывал о потоках создания данных (сетки, геометрии), а не чтения их из ресурсов. Мы же договорились, что у нас процедура генерирует и сетку и геометрию? Кстати, это тоже потоки, в которые эта процедура генерации "сущностей" будет осуществлять дозапись, не так ли?

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

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

С таким подходом мои слова про "откусываешь по кусочку" -- инструкция по поеданию яблок. Не делай больше так, а то станешь похожим на нашу жёлтую прессу.

Посмотрим сюда:

К сведению сетка и сейчас "процедурно генерируется". Ручками ноды никто не расставляет.

Твоя фраза? Твоя. А в каком приложении "Ручками ноды никто не расставляет" ? Не в SDK ли часом?
А в движке на данный момент есть такая функция? Я видел только в SDK. В работающем xrEngine.exe как-то не довелось видеть кнопку "Сделать AI-сетку".

===

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

Сообщение отредактировал Willy - 25.01.2016, 21:36

[abramcumner]

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

Конструктивизм был у krovosnork`а и у меня про монолит и сталкер2. От тебя только вакханалия процедурной генерации текстов. А еще вот выяснили, что потенциально бесконечная сетка это оказывается сетка 100 на 100. Тоже считаю конструктивным.

Ну я надеялся, что Giperion расскажет подробней, начал ли он новый проект(разработка СДК), а на старый(новая платформа для моддинга) забил. Или просто первый этап он сделал и начал второй. А так только флудить и остается.

Сообщение отредактировал abramcumner - 25.01.2016, 22:03

[Willy]

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

Конструктивизм был у krovosnork`а и у меня про монолит и сталкер2. От тебя только вакханалия процедурной генерации текстов. А еще вот выяснили, что потенциально бесконечная сетка это оказывается сетка 100 на 100. Тоже считаю конструктивным.

Странный ответ какой-то.
Моя процедурная генерация текстов является результатом того, что ты начал предоставлять мне данные, которые не совсем соответствуют действительности, не так ли? За это все время ты ни разу не указал чего-либо, что может вписаться в шаблон типа:

"Должно быть <вот так> потому что оно сделано <вот тут> именно таким образом и это можно использовать в X-Ray."

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

Сейчас же вдруг

сетка 100 на 100

"переехала" в какое-то из моих сообщений, так что ли? Или нынче множество "бесконечность" стало равняться 10 000? (100x100)
Грубо говоря, вызовешь функцию генерации нодов 10 000 раз -- получишь сетку 100х100.
Будешь вызывать при передвижении актёра в цикле -- получишь сетку, которая будет генерироваться, пока актёр двигается. Если актёр будет двигаться бесконечно -- получишь бесконечную генерацию сетки. Бесконечная генерация сетки генерирует бесконечную сетку, не так ли?

Вот только вопрос твоей компетентности возникает, раз у тебя сплошные вопросы и сплошь и рядом неверные ответы да теории, что бесконечность равна десяти тысячам.
Но что-либо доказывать я не собираюсь. Мне за это не платят и хлеб по почте не приходит. Если тебе приведенных фактов мало, то могу только процитировать: "Спасение утопающих -- дело рук самих утопающих".

Ну я надеялся, что Giperion расскажет подробней, начал ли он новый проект(разработка СДК), а на старый(новая платформа для моддинга) забил. Или просто первый этап он сделал и начал второй. А так только флудить и остается.

Я бы на месте тов. Giperion похвалил и тебя, abramcumner, и RedPython за "добрые" ^{<=*сарказм*} напутствия. Они ведь так хорошо ободряют и подсказывают что именно надо делать! Надо закрыть тему, закрыть репо и со спокойной душой считать, что добрых 40 или даже 50% сообщества уж точно "прогнило" © и ни на что, кроме "фу, не сможешь, сольёшься, дай билд! Пруфы!!11!" не способно. Не так ли?

[Flammable]

Нужно будет сменить алгоритмы A-Life на те, которые не будут использовать сетку (алгоритмы Дейкстры и А*).
Проще на ходу сгенерировать сетку, как это делает SDK и "научить" движок использовать "сырую" нескомпилированную сетку вместо той, которую предоставляет нам xrAI.

Навигацию без графов, подходящую для таких игр, как сталкер, делать еще не научились, насколько мне известно. Было бы здорово вместо клеток фиксированного размера использовать т.н. navigation mesh: его можно генерировать в рантайме, как в том же CryEngine. Целиком избавиться от заранее заданных графов, наверное, не получится, потому что клеточки используются для постоения детальных путей, а длинные пути строятся в других графах, которые собираются вручную левелдизайнерами под конкретный уровень.
Хорошая сторона X-Ray состоит в том, что реализация A* в нем способна работать с произвольными графами.

[abramcumner]

Надо закрыть тему, закрыть репо и со спокойной душой считать,

Чтобы закрыть репо, его сначала надо открыть

Извини, Willy, я не считаю конструктивными заявления типа: "мы все будем генерировать на лету", " мы сделаем полную симуляцию жизни", "потенциально бесконечные" и тому подобное. Просить ст2 у монолита и то конструктивней.

Хочешь конструктивное - скажи, я тут добавляю в ЛЕ процедурную генерацию карты. Убери косяки, оптимизируй и только тогда можно будет посмотреть и подумать - можно ли ее засовывать в движок "на лету". Тоже самое с сеткой и прочим.

[Cossack-HD]

Зачастую бывает проще написать с нуля, чем пытаться внести новый функционал в изначально неприспособленный под это код, да ещё и в n-итирациях.

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

[Giperion]

Первый раз что ли видишь, как говорят одно, а делают другое?

А ты точно умеешь читать?

Главная цель: Сделать сталкер более дружелюбным для моддинга.

Я писал вот это. Это главное.
А вот список запланированных фич я могу менять постоянно. Хоть по 100 раз на дню. Имею полное право, проект принадлежит мне. Разработчики Сталкера так же постоянно меняли концепцию игры, да и не только Сталкера - многие разработчики так делают. Даже моды - и те объявляли одно, а в релиз уходили другими.

Я предлагал SWIG, как более быстрое решение.

SWIG плохо подходит, по сравнению с Lua - это шило на мыло, нету экзепшенов, LINQ и других классных вещей. Да и скриптовой код не должен дублировать код исходников - это банально не красиво, да и не юзабельно.

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

Поддержка огромных локации осуществима за разумное время. Это факт.

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

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

Или помогает выполнить потенциально бесконечный цикл за 10 секунд?

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

Едрить фантазёров понабежало

Флудеров тоже смотрю достаточно, абсолютно не конструктивный пост.

[Willy]

Чтобы закрыть репо, его сначала надо открыть

Закрыть == удалить. Согласен, немного неточно.

Извини, Willy, я не считаю конструктивными заявления типа: "мы все будем генерировать на лету", " мы сделаем полную симуляцию жизни", "потенциально бесконечные" и тому подобное. Просить ст2 у монолита и то конструктивней.

А где такие заявления в моем исполнении? Я где-то писал, что "будем"? И что это будет в X-Ray? Это были примеры. Вполне реальные примеры, хоть и в виде теории или "так работает в других играх"

Хочешь конструктивное - скажи, я тут добавляю в ЛЕ процедурную генерацию карты. Убери косяки, оптимизируй и только тогда можно будет посмотреть и подумать - можно ли ее засовывать в движок "на лету". Тоже самое с сеткой и прочим.

Ах, значит теперь понятия "предложения" и "реализация" -- одно и то же или как? Тем более речь шла о процедурной генерации как примере, а не "вот, хочу сделать и подарить прогнившему © сталкерскому сообществу".

В любом случае, в моих словах есть ссылки на факты. В твоих словах только ссылки на "докажи сам или слабó?" или же "ты не прав", но при этом варианта лучше ты не предлагаешь. Достойное поведение, чтобы указывать на неконструктивность.