Xil | Предыстория 1/2
Испытывались разные 3D движки и среды, начиная с разработок 2000-х годов на DX7 и DX9 (из-за огромного количества созданных учебников, форумов, примеров, фанатских dll библиотек расширяющих возможности старых движков красивыми тенями, блеском жидкостей, и разными эффектами которых незаметно и движках на DX11). В результате того что учебников по более современным движкам крайне мало, по некоторым всего по 1 и те на иностранном языке, по другим вообще нет, лишь то что на сайтах с ними, а иногда нет и самих сайтов, закрыты (3D движки на DX9 и DX11), а вопросы возникают и ответов на них нет, то первые пробы после возникновения идеи сделать космическую RTS проводились на старых разработках к которым иногда есть и по 2-3 пособия и можно скачать многие десятки готовых улучшений и наработок для изучения. Планов делать на старых движках sci fi игру и что-либо публиковать конечно небыло, среды технически устарели для этого и либо работали на устаревших DX либо если это DX9 то имели ряд ограничений первых разработок (позволяли создать лишь небольшие 3D сцены). В них тестировалась гравитация (позднее перенесенная в более современные среды разработки), подключения к ним кода из разных языков программирования который выдавал координаты в виде чисел, в них замерялось насколько удобно вращать звезды в большом количестве что бы понять вообще возможно ли более или менее удобным способом управлять с экрана 3D скоплением звезд и флотами в них т.е. можно ли вообще создать sci-fi игру RTS в 3D и успешно управлять событиями в ней. Код был примитивным, в виде больших сгенерированных в разных программах кусков кода вставленных в движки и фиксированных не гибких массивов данных, т.к. это были только тесты, посмотреть как это может выглядть что бы понять на тестах воможно ли будет это сделать.
Документации по вышедшим из применения движкам было достаточно и была предпринята попытка расширить понятные среды разработок добавлением библиотек мягких теней и разных внешних dll модулей с эффектами (попытка довести их спецэффекты до уровня современных DX фанатскими апгрейдами, в результате оказалась создана сложная по коду модель под условным номером 0. После чего устаревшие движки был заброшены и из-за отсутствия шейдеров SM3 уровня, ограничений на источники света, низкой скорости работы и сбоев некоторых из них из-за несовершенства, но это изначально был лишь эксперимент. Пытаясь создать современную sci fi игру можно получить много хейта за работу в устаревших движках, что часто видно на некоторых форумах и ожидаемо. К чуть более новым движкам с достаточной документацией была непонятна лицензия, нужны ли отчисления какие-либо или нет, а сайты с ними закрыты что бы спросить (по некоторым записям из-за различных исков или судов за то что они бесплатные, а часть их кода, обрабатывающая 3D, была взята с интернета и находилась под лицензией непозволявшей полную бесплатность, и оплатить расходы предлагалась разработчикам за все скачивания их движка). Следующие поколения 3D движков последних DX9 DX10 DX11 которые были бесплатными и применялись около 2010-2015-х годов уже практически не имели документации и на форумах сопровождались описаниями разных несостыковок и ошибок (первых 3D движков было мало, на них было сконцентрировано больше внимания и создано больше документации в том числе на русском, описаны обходы сбоев и решения сложных вопросов, чем движков становилось больше тем меньше по ним описаний и почти нет документаций, предоставленных к ним кратких справок команд недостаточно для работы, а тех поддержки у бесплатных движков практически нет, без подробной документации их невозможно применять,). Вроде бесплатный движек на DX9 и DX11 есть, но без полной документации делать на нем ничего нельзя. Похоже что на определенном этапе онлайн были исходники кодов по работе с 3D, скачав их несколько разработчиков выпустили разные 3D движки, после чего им стали писать владельцы кода, и разработчики закрыли свои сайты даже не оснастив свои движки достаточной документацией.
Один из примеров работы с 3D графикой и ее неусточивость, недоисследованность, зыбкость программных платформ можно обозначить на реальном примере попытки создания sci fi игры, это освещение, начав работу с некоторыми платформами кажется что часть из них вполне подходит, бесплатные, держат сцену, выдают приемлемую дальность рендеринга и картинку, начинается разарботка на нем, создаются некоторые 3D модели, интерфейс и тут вдруг дело доходит до создания модели взрывов, взрыв, генерируемый в определнной точки пространства с разлетом обломков и частиц должен сопровождаться выспышкой света, освещенности, что бы яркость от взрыва действовала на поверхность рядом расположенных космических кораблей освещая пространство вокруг при взрыве. И - сбой, ошибка, EXE файл вылетает на рабочий стол потому что в трехмерном движке нельзя менять свойства источника света в процессе, а обнаруживается это уже после большой проделанной с движком работы. т.е. в DirectX можно, но реализация связки движка и DX содержит ошибку, и обойти это никак нельзя - программная команда смены свойств света - его яркости и цвета от источника единственная, других нет, просто она приводит к сбою всей программы и вылет на рабочий стол, ну вот так, можно только удалить свет, затем занового его создать с другой яркостью, и подставить его на место прошлого источника света и так множество раз в процессе всего эффекта взрыва - а это потребляет ресурсы системы больше чем нужно. Не проверив движек на работу освещения на разработку в нем затрачиваются усилия и время, а потом приходится или смирится и делать дальше без эффекта света от взрыва или искать другой. Такие ситуации иногда и приводят к тому что начинающие разработчики своих игр однажды бросают свои начинания и закрывают проекты не видя в себе силы или не имея времени на знакомство с другим движком т.к. они не закладывают такие ситуации или много таких ситуаций в свой план реализации проекта.