Сегодня знаменательная дата! 02.06.2024 можно считать днём, когда движок наконец-то полностью и окончательно отвязался от брашей в качестве основного и определяющего строительного материала!
Отныне XashNT переходит из разряда брашевых движков семейства Quake, в семейство современных полигональных движков
Как это определяется? Очень просто. В брашевом движке вы не сможете построить уровень только из моделей, вам обязательно понадобится хотя бы небесная коробка, ну или что-то вроде этого. К тому же при таком подходе у вас не будет просчитана видимость. В XashNT теперь можно полноценно считать видимость без использования брашей, полноценно работает коллизия и накладываются лайтмапы. Тем не менее я не планирую полностью избавляться от брашей по двум соображениям:
1. Поддержка классических брашевых уровней из старых игр. Это останется по прежнему доступно, более того - XashNT будет собирать такие уровни гораздо лучше и точнее чем оригинальные компиляторы тех игр. Но есть и другая интересная возможность. Как вы знаете эти уровни довольно плохо поддаются декомпиляции обратно в браши (зависит от формата BSP). Так вот, теперь есть возможность сдампить эти уровни в полигональную модель и скомпилить обратно под XashNT. Единственное что потребуется от моделлёра - это расставить порталы для обеспечения видимости. Впрочем их потребуется расставить в любом случае. Так что этот кейс сохраняет одно из важных направлений для любителей возиться со старыми играми и поэтому я не могу его просто взять и выбросить.
2. Несмотря на то, что XashNT умеет обходиться полностью без брашей, они ему всё же нужны. Для трёх важных случаев:
- Без брашей не будут работать триггеры. Вернее будут, но не слишком чётко. Могут срабатывать через раз, зависит от протяжённости триггера и места его пересечения другим примитивом. Полигональный движок коллизии может весьма точно определить момент пересечения двух тел, но нет абсолютно никакой возможности точно определить - продолжает ли тело застревать "в текстуре" или уже освободилось. Именно поэтому вы и наблюдаете чертопляску когда код антизастревания пытается вытолкнуть объект из текстуры. Потому что пересечения определяются по пересечению рёбер, а это происходит далеко не всегда. Это не ограничение XashNT это ограничение любого полигонального детектора коллизии. Решения этой проблемы не существует в принципе.
Точнее существует - в виде брашей, т.е. конвексных замкнутых примитивов
- Так же без брашей и по той же причине будут не очень хорошо работать всякие давилки, типа дверей, поездов и прочего. Хотя могу сказать, что в принципе этот момент в будущем скорее всего будет успешно исправлен. Ну просто потому что поездам не надо проникать в игрока, в отличие от триггеров. Просто на данный момент используется старый код детектирования коллизии из Quake (естественно в кодобазе на Shot, не в движке).
- Водяные объемы. Ну тут всё просто - нахождение предмета в воде определяется по результату возврата функции POINT_CONTENTS, а контентсы можно считать только и исключительно для объема. Если в первыми двумя пунктами ещё есть вероятность, что я это дело разрулю и исправлю, то здесь без вариантов. Вода будет работать только и исключительно с брашами. Если в движке нету брашей, там соответственно нет и никакой воды. Либо вода есть - но фейковая, как в Сталкере. Либо вода есть, но глобальная на всю карту и задаётся через гигантскую плоскость, как в Кризисе. А вот чтобы делать какую угодно воду, как в Quake - тут без брашей не обойтись.
Вроде как в любом физическом движке есть замкнутые коллайдеры для триггеров? Причём и трассу ими можно делать, там коробкой, сферой или капсулой. А вот для полигонов уже мешколайдер. Так что в целом это и всё и без брашей может работать даже для полигональной геометрии как в Юнити.
Но если делать по заветам Кармака, то да придётся писать целую систему. В Юнити кстати проваливания я крайне редко замечал, в основном только в тех случаях когда объект имел какое то неадекватное ускорение.
Да и не сказал бы я то что брашевая коллизия в целом стабильнее полигональной, я когда занимался переводом моделей в браши и пытался компилировать промежуточные результаты в бсп, замечал то что прекрасно обрабатывалось на полигональных движках, жутко обсиралось на брашевых - игрок проваливался под карту практически на ровном месте, в основном я как понял большой вклад в эту нестабильность вносили разбиения геометрии на более мелкие фрагменты, чего у полигональных движков нет.
Ещё я помню очень давно когда я делал карту на конкурс по хл, был случай когда на ровном месте появлялась невидимая и непроходимая плоскость.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
FiEctro писал: Вроде как в любом физическом движке есть замкнутые коллайдеры для триггеров?
Безусловно, если аппроксимировать триггер до бокса - то и XashNT способен обойтись без брашей. Но триггеры в той же халфе бывают порой весьма сложные и неконвексные конструкции, так-то.
Цитата:
FiEctro писал: Да и не сказал бы я то что брашевая коллизия в целом стабильнее полигональной
В перепеве Рабиновича она конечно довольно глючная.
Добавлено сегодня в 13:23:
22.04.2022
Цитата:
Дядя Миша писал: Читаю тему с самого начала, неспешно. Очень хорошо что я это сделал, например освежил в памяти, сколько же на самом деле было итераций у системы материалов. Спустя 2 года, мне уже кажется, будто я её выдумал и реализовал буквально за месяц. Но нет, она менялась очень много раз.
28.05.2024
Цитата:
Дядя Миша писал: Решил перечитать тему с самого начала, её скоро уже закрывать, по достижению 256 страниц. Память человеческая весьма ненадёжна.
Ну то есть мозг сам решает, что ему помнить, а что с забыть.
С превеликим удивлением узнал, сколько же было неудачных интераций у моей материал-системы. Сейчас-то она мне кажется вполне естественной и логичной, как будто бы я к ней пришёл сразу. А там - минимум пять промежуточных версий, причём в довольно короткий промежуток времени, около двух месяцев. Интересно.
Это уже становится традицией - каждые джва года перечитывать тему и удивляться сколько же было итераций у системы материалов. И каждый раз - как в первый раз.
Дядя Миша писал: 1. Игровую часть планировалось оставить в С++ библиотеке и вынести туда как можно больше связанных вещей, чтобы у юзера было как можно больше свободы действий. Это действительно было сделано, но движение в данном направлении превращает пользовательские библиотеки в подобие сорсовских. Куда обычному дизайнеру просто страшно залезать. Это явно не то, чего бы мне хотелось.
Надо просто стиль кода держать ближе к какому-нибудь Q2 и подальше от Сорса.
И давайте ка я прокомментирую то предидудщее резюме спустя два года.
Цитата:
1. Игровую часть планировалось оставить в С++ библиотеке и вынести туда как можно больше связанных вещей, чтобы у юзера было как можно больше свободы действий. Это действительно было сделано, но движение в данном направлении превращает пользовательские библиотеки в подобие сорсовских. Куда обычному дизайнеру просто страшно залезать. Это явно не то, чего бы мне хотелось.
Смена концепции: игровая часть должна быть в скрипт-машине, которую легко отредактировать, не устанавливая громоздких IDE.
Статус: еще не реализовано
Уже реализовано, отлажено, отточено и используется. Создан собственный язык программирования HeadShot ну или просто Shot.
Цитата:
Система материалов. Концепция, если внимательно ознакомиться с темой, менялась раз пять-шесть, в процессе имплементации. Получившийся язык позволяет гибко описать абсолютно любой материал, однако он слишком громоздкий для обычно пользователя. Решение было найдено при помощи системы макросов, которые позволяют притвориться одним из стандартных языков описания материалов. Таким образом пользователю даже не придётся переучиваться. Или наоборот - он сможет создать свой язык описания системы материалов.
Статус. завершено наполовину, поскольку нет динамического освещения и теней, что вероятно потребует некоторых нововведений в уже существующую систему.
На самом деле с 2022-го года система менялась минимальным образом. Изначально выбранная концепция оказалась весьма удачной, поэтому добавление динамического освещения или скажем бампа-параллакса вообще никак её не затронуло. Теней-зеркал-порталов-мониторов (т.е. мультпроходного рендерера) по прежнему нет. Точнее говоря - рендерер изначально спроектирован как мультипроходный и таковым является. Но сами проходы не используются, пока что. Зеркала и мониторы на данном этапе разработки - явно не то, на что следовало бы тратить время. А работа над полностью динамическим освещением я планирую начать не раньше имплементации ещё двух способов оптимизации рендеринга - динамической окклюзии и импосторов.
Цитата:
Формат уровней. Изначально предполагалось использовать Q1-like формат, слегка доработанный. Во многом в рамках этого эксперимента и создавались p2st-компиляторы. Затем был использован Q3-like формат,
который тоже меня не устроил по ряду показателей и наконец в процессе была выработана концепция Uniform Mesh. Это очень хороший механизм, позволяющий расширять любой формат без потери совместимости.
Статус: формат завершен, однако текущие реализации на его базе еще будут изменяться (без потери совместимости) и расширяться.
Увы бинарная совместимость после этого смелого заявления была сломана и даже не один раз. Но фундаментальной смены принципов на которых основан формат не произошло. Там всё по-прежнему.
Цитата:
Статическое освещение. Как вы помните, изначально я не планировал его внедрять, однако под давлением общественности и собственных соображений всё же сделал это. Смена концепции: первоначальный лайтмаппер не умел считать отражённое освещение, но в итоге там появился полноценный радиосити.
Статус: лайтмаппер закончен, но я не исключаю его дальнейших оптимизаций.
Из нововведений в лайтмаппере появилсь лайт-стили, визлайт-матрица, амбиент-кубы и запечённое освещение по единственной точке. Но да - на саму архитектуру лайтмаппера это никак не повлияло, всё добавлялось легко и просто, идеально ложась на неё.
Цитата:
Редактор ресурсов. До сентября прошлого года не хотелось связываться с этой темой вообще. Были надежды, что его заменит Jack или Blender.
Натурные эксперименты показали, что об этом нечего даже и думать.
Смена концепции: я не хотел делать редактор, поскольку он ожидаемо был бы похож на QuArK, но теперь я создаю редактор, у которого внешний вид заложен в скриптовых файлах, а следовательно может быть адаптирован под внешний вид любого редактора, будь то Jack или даже Unity.
Статус: в процессе разработки (именно над ним я сейчас и работаю).
Плагин для Джека появился, но задача написания собственного редактора не только никуда не исчезла, но и усложнилась. Ведь теперь мне надо не просто написать редактор, а написать его на основе VCL из Delphi, который я портирую на свой язык программирования Shot. Собственно портирование VCL это и есть куда более сложная (для меня) задачка, нежели написание редактора.
Какой краткий итог можно сделать из всего этого? Всё что было обозначено - так или иначе реализуется. Да, в некоторых случаях происходит "откат" готовности, как в случае с разработкой собственного языка программирования и портированием VCL. Но я считаю при планировании на большой срок в архитектуру приложения закладывать спорные решения просто нельзя. И по прежнему следую этому правилу.
В идеале конечно бы полностью отказаться от сторонних библиотек и форматов, но данная задача не является приоритетной.
Добавлено сегодня в 13:43:
Цитата:
Crystallize писал: Надо просто стиль кода держать ближе к какому-нибудь Q2 и подальше от Сорса.
Я придерживаюсь кодо-стиля как в голдсорсе. Вроде бы никто не жаловался, что он непонятный. А вот Q2 это наоборот тихий ужос и антипаттерн.
Добавлено сегодня в 14:36:
По поводу вот этого: https://hlfx.ru/forum/showthread.ph...8746#post208746
могу сказать, что даже сверхупрощённый интерфейс вызвал в конечном итоге проблемы. Поэтому я принял волевое решение полностью отказаться от библиотек. Ксаш полностью построен на .exe файлах и грузит только системные библиотеки самой винды. Ну а настройки передаются через командную строку.
Дядя Миша писал: По поводу вот этого: https://hlfx.ru/forum/showthread.ph...8746#post208746
могу сказать, что даже сверхупрощённый интерфейс вызвал в конечном итоге проблемы. Поэтому я принял волевое решение полностью отказаться от библиотек. Ксаш полностью построен на .exe файлах и грузит только системные библиотеки самой винды. Ну а настройки передаются через командную строку.
Там у тебя получался какой-то ад в духе Мастера, гибкость ради гибкости.
Добавлено сегодня в 18:53:
Цитата:
Дядя Миша писал: Я придерживаюсь кодо-стиля как в голдсорсе. Вроде бы никто не жаловался, что он непонятный
Дядя Миша писал: ситуация на рынке движков, абсолютно не устраивает их пользователей, но альтернативы у них всё равно нет. Вот и приходится терпеть и успокаивать себя тем, что всё что они видели - еще хуже.
Не уверен, что мне это знакомо. Пользуюсь UE и пока что не поменял своего мнения на его счет, даже прочувствовав на себе его недостатки. Меня больше другое смущает: а почему движок, который меня на данный момент полностью устраивает - всего один? Вот случись чего с ним или с самим Суини - уже не очень представляю, куда деваться. Альтернативы уже конечно присмотрены "на всякий", но это скорее компромиссные решения, чем полноценные аналоги.
__________________
To start the match, Let's draw the sketch, Then add some magic from your heart!
Take gold and blue, Take silver too and put a sparkle in your art!
I love that dress, I love It, YES!!! I love the way It makes me feel.
I love the shoes, I love to choose, It was a dream and now It's real!
Дядя Миша писал: Дизайнеры в код не хотят лезть вообще. Ни в какой.
Поправочка - они не хотят лезть в код который не понимают. Именно поэтому в Юнити все пользовательские скрипты изолированы от фреймворка.
Тут всё зависит от удобства IDE и отладчика. Если из этого только блокнотик то конечно единицы в этом ковыряться будут. А так то вон макароны в анриле довольно бодро таскают, не смотря на то как плохо оно выглядит в итоге. Чистый код нужен только матерым программистам.
Цитата:
Дядя Миша писал: Ведь теперь мне надо не просто написать редактор, а написать его на основе VCL из Delphi
А под линуксом в теории такое будет работать? Или только вайн?
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Под вайном точно всё работает и производительность адекватная.
Грубо говоря, портирование на Линукс сводится к тому, чтобы встроить куски вайна внутрь приложения. И получить ту же самую производительность, но при этом потерять довольно много времени.
| IP: 
вчера 15:07
