FiEctro писал: Что такое матрица смежности и как она решает эту проблему?
это матрица с информацией, сколько у каждого фейса смежных ребёр.
Можно конечно построить настоящие рёбра, но для брашей это оверкилл получается.
Цитата:
Crystallize писал: Может в пэйнте нарисуешь чтоб мы поняли?
Фиолетовые стороны - это задние стороны браша. Чтобы из разрозненных фейсов гарантированно сконструировать браш, надо не менее четырёх.
Можно конечно и меньше, но его потенциально может раздуть на полкарты.
Идеальный случай, когда мы можем задетектировать планарные дыры в браше. А не одну вогнутую дыру. А для этого надо именно не меньше четырёх сторон. Далее. Стороны подбираются по общим рёбрам. Не по коллинеарным, а именно по общим! Теперь смотрим на картинку.
Красный фейс когда-то тоже был брашем, но дерево его уничтожило, оставив только один фейс. На уровне мержилки фейсов, красный и зелёный логично объединить в один. Но тогда браш - уже не соберётся никаким образом. Мог бы собраться один браш из фиолетовых и зелёной стороны и ещё один - из красной.
А если смержить красную и зеленую стороны, вместо этого получится пять брашей, созданных из фейсов, надеюсь теперь понятно.
Кстати, а как работает сорсовский декомпил? Он строит браши на порядок качественнее чем голдсорсовский.
Цитата:
Дядя Миша писал: Для NT я мог бы вообще дропнуть весь уровень в единую модель и так скомпилить. Но ето неспортивно.
Кстати интересно, насколько реально применять к вкомпиливыемым моделькам CSG операции? Например вот торчит ящик из под земли, нижние грани находятся снаружи уровня, реально их обрезать?
Добавлено 31-05-2023 в 11:27:
Цитата:
Дядя Миша писал: надеюсь теперь понятно.
Мне кажется прежде чем их мержить, их надо как то заранее подготовить, возможно сделать веса типа какие полигоны лучше мержить с другими, дабы если встретится такая фигня не нужно было пересчитывать всё, а только соседей. Ну типа как VIS где каждый лист знает что он видит, а что нет.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
FiEctro писал: Кстати, а как работает сорсовский декомпил?
Начиная с ку2 в карту сохраняются браши, поэтому там подобной проблемы вообще нет. Даже в первом дууме куда больше информации для точной реконструкции уровня. Речь именно про Q1/HLBSP.
Цитата:
FiEctro писал: насколько реально применять к вкомпиливыемым моделькам CSG операции?
Реально, но не особо эффективно. CSG лучше всего работает с выпуклыми объемами.
Цитата:
FiEctro писал: Например вот торчит ящик из под земли, нижние грани находятся снаружи уровня, реально их обрезать?
На полигональном уровне невозможно определить "снаружи и внутри".
Ну то есть принципиального ограничения нет, но оно просто того не стоит.
Ты будешь часами ждать рассчётов, ради удаления десятка тысяч полигонов (из миллиона), которые ни на что не повлияют.
Цитата:
FiEctro писал: возможно сделать веса типа какие полигоны лучше мержить с другими
Пробовал мультипроходной мержинг - сперва мержим все полигоны, не имеющие форму прямоугольника, затем - только имеющие. Кое-что кое-где конечно исправилось, но это половинчатое решение.
Потому что НЕТ чёткого критерия, что можно друг с другом мержить, а что нельзя. А нет его как раз потому что сурфейсы рассчены как деревом, так и субдивайдером лайтмапы. Поди отличи одно от другого.
Добавлено 31-05-2023 в 11:56:
К тому же компилятор, перед тем как рассечь сурфейсы субдивайдером мержит результат рассечения нодами. Это возможно просто потому, что уже не играет роли в момент пересечения с нодой трасса ограничена деревом, так что можно мержить их обратно без проблем. Т.е. информация о сторонах брашей частично теряется уже на этапе компиляции.
Добавлено 31-05-2023 в 11:58:
Для понимания, скажу, то что сделал я:
- имеет идеально наложенные текстуры
- собирается без дырок
- к сожалению большинство брашей созданы из одного фейса, в силу природы HLBSP.
Если мне удасться осуществить свою задумку - кол-во таким брашей, созданных из одного сурфейса просто упадёт на какой-то процент, от 10 до 20, но не более того. И это максимум что тут вообще можно сделать.
Добавлено 31-05-2023 в 11:59:
Альтернатива - создавать гигантский куб и выгрызать дыры в нём.
Дальнейшее редактирование подобного декомпила очень сильно затруднено.
Дядя Миша писал: Альтернатива - создавать гигантский куб и выгрызать дыры в нём.
А если ограничить толщину стенок чтобы они не доходили до границ куба? Вот например насчитало тебе браш длинной 10000 юнитов, а ты его принудительно говоришь нет, у тебя будет толщина 16 юнитов. Да и куб наверное можно не один сделать, что то вроде нарезать карту кордоном и для каждого участка сделать свой куб?
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Дядя Миша писал: ты точно хорошо понимаешь как устроено BSP-дерево? Конкретно в HLBSP.
Так, а смысл от него на этапе декомпиляции? Почему нельзя просто с геометрией работать?
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Не забудь в фичелисте упомянуть В других брашевых движках вообще есть такое?
А там как, из двух последних снапшотов берутся хуллы игрока, обтягиваются общим конвексным триггером, и он проверяется на пересечение с другим триггером?
Раньше триггер детектировал столкновение только когда объект проделывал путь за кадр. Т.е. движение на шаг, новая позиция, проверка на попадание в триггер. Сейчас же триггеры ловятся на всём пути этого движения.
Ну я ж сказал, две позиции игрока обтягиваются триггером-параллелограммом.
Цитата:
Дядя Миша писал: Впрочем, я уже объяснял и не раз. Где-то в этой же теме.
Не припомню.
Если в NT будет liblist.gam то надо как-то автоматически защищать его от перезаписи. А то два дня ищешь почему ничего не работает, а потом оказывается что в мае, видимо от того что старый Кварк ставил, он перезаписал в директории мода либлист мода и вписал туда пути к стоковым дллкам valve.
Да и в Xash3D тоже будет круто если кто-то сделает.
Наконец-то дошли руки до важнейшей вещи. Честно говоря не знаю, может быть во всех современных играх оно давно уже именно так и сделано, а может быть и нет. Речь идёт о наших любимых разрешениях экрана, конечно же. В старых играх эти разрешения были намертво вкомпилены прямо в код игрового движка, а игроку предлагалось выбрать разрешение самостоятельно. Ну или при первом запуске игра могла сама сделать это за него, ориентируясь на разрешение рабочего стола.
Основная проблема была в том, что можно было выбрать неверное разрешение и даже спалить некоторые модели мониторов таким образом.
Или же получить от кого-то игру с конфигом для одного монитора, запустить на своём компьютере и получить Out Of Range или нечто подобное.
Тут конечно уместно спросить - почему бы не получить список доступных разрешений монитора прямо из системы? А очень просто. Дело в том, что исторически, до появления DVI и тем более HDMI не существовало никакого способа узнать какие же разрешения поддерживает тот или иной монитор. Вы наверное помните, что года до 2002-го к мониторам прикладывали диск с драйвером и инструкцией в PDF. Так вот драйвер по сути был текстовым inf-файлом, который содержал только и исключительно список поддерживаемых монитором расширений, ну и его оригинальное название. А больше он не делал ничего. Потом впоследствии конечно эти драйвера стали встраиваться прямо в дистрибутив Windows самим Микрософтом, а интерфейсы DVI и HDMI позволяли получить список поддерживаемых режимов путём чтения микросхемы EDID на матрице.
Для тех кто не в курсе, поясню, что эта микросхема - аналог текстового драйвера, только в аппаратном исполнении и просто припаяна на саму матрицу. Т.е. путём перепрошивки туда можно записать любую пургу, хотя это конечно сложнее, чем редактирование inf-файла. Ну так вот. Все эти способы, так или иначе не дают надёжного определения рабочего разрешения. Поэтому я сделал следующие допущения:
1. LCD и AMOLED матрицы имеют только одно-единственное рабочее разрешение. Да, они могут работать в меньших, но в отличие от CRT, картинка будет мыльной и просто отвратительной. Поэтому данные режимы никто никогда не использует, а современные винды неплохо научились определять то самое дефолтное разрешение.
2. Эксперименты с максимально поддерживаемым разрешение и максимально поддерживаемой частотой экрана гораздо лучше и надёжнее ставить в свойствах системы, а не внутри какой-то игры. Игра зависнет и вам придётся собрать всю пыль с кнопки Reset.
3. Поэтому мы можем с уверенностью предполагать, что разрешение и частота обновления на рабочем столе - это единственное валидное разрешение полного экрана. Таким образом игра для полного экрана сможет использовать именно его и только его.
4. Разрешения которые нам вернул EnumDisplayModes с учётом того, что там много дубликатов и мусора мы можем пропустить сквозь фильтр разрешения десктопа. Очевидно что оконные разрешения не могут превосходить полноэкранное ни по какому из измерений и тем более не могут превосходить частоту кадровой или отличаться по битности.
Таким образом у нас всегда формируется список из актуальных и безопасных разрешений экрана.
5. И горячее сочетание Alt+Enter запоминает размер оконного режима - эта штука в старом ксаше так и не работала нормально.