в BSP творится натуральный ад, после того как вальва его разрезала на BSP и CSG.
оба проекта скомпилены с дабл-флоатом, но плоскости дампятся прямо в карту, попутно обрезаясь до флоатов. Соответственно и полный набор функций виндинга был переписан под флоаты и dplane_t. Китаец пытался это профиксить, через грёбанные макросы, чем еще больше запутал и усугбил ситуацию, ориентироваться в этой каше в принципе невозможно. К тому же кто-то очень ленивый, ввёл ограничение MAXEDGS в 24 штуки прямо на старте работы BSP, при том, что CSG никоим образом не ругается и ничего не предпринимает, если этот лимит будет достигнут. Сам по себе этот лимит нужен только софтварному рендереру, но ведь никто мешает проверять кол-во получившихся точек уже всех мержев, разрезов бсп и тджунков. К тому же, руководствуясь логикой фиксированного массива вертексов, из фейса выкинули виндинг и вместо него всунули этот фиксированный массив. К чему это привело, правильно, всех функции из polylib.c пришлось дублировать для порталов, нодов и сурфейсов. И это я еще молчу что при дублировании там вполне могли быть какие-то ошибки.
Самое ржачное, что китаец тоже поленился переписывать этот фиксированный набор на нормальные виндинги, видимо прикинул, что тогда директив препроцессору будет больше, чем собственно кода. Ублюдство полное.
Разгребаю потихоньку.
В поисках компилятора, который бы прожевал такого монстра как ad_sepulcher, я наткнулся на TyrUtils, это такие специальные компиляторы для первой кваки, которыми был собран весь AD. Список фичей очень сильно впечатляет, по сути это аналог китайца, но для кваки. Там тоже есть радиосити, детайл-брашы, делюкс-маппенк, поддержка -bsp2, амбиент-окулижен, который в терминологии квакеров почему-то называется dirtmapping (он ведь был еще в q3map2 но я всегда недоумевал что это, т.к. судя по названию, какая-то грязеразводилка на лайтмапах), вот только сегодня узнал что же это такое наконец. Вообще видно, что человек к созданию компиляторов подошёл основательно, у него там и гугловские юнит-тесты и набор стрёмных карт, для тестирования всяческих фейлов и регрессов.
Но поскольку я задался целью создать самые лутьшые компиляторы в мире, то буду изучать их тоже, естественно. Заодно буду вам рассказывать, если там найду что-то интересное.
Post automatically merged:
ЗЫ. Впрочем тени от моделек на карте есть только у меня
Post automatically merged:
Предварительная информация по тулзам. Тулзы остались на чистом Си, но для подключения контнейеров и шаблонов были переделаны в С++. Ну как переделаны - внутри обычные сишные функции из первокваки. Так же подключён embree. Правда есть и собственная реализация. Если честно, вот этого замута с embree я не понял вообще. Как будто-то нативная поинт-трасса кваки не способна что-либо протрейсить. Или что embree быстрее кушной трассы (что крайне маловероятно). Расширения файлов переименованы зачем-то в .cc и .hh соответственно. Виндинг оригинальный, неисправленный. Форматирование сорцев не табами, а пробелами, как в ZHLT. Уже видимо какая-то негласная традиция.
Компиляторы Ксерокса я обсуждаю ваське с самим Ксероксом, это гораздо удобнее.
Post automatically merged:
А я продолжаю копать TyrTools. Во всяком случае рад там самописный, Замечены классические патчи, но строятся они как-то странно. Dirt-mapping попячен с q3map2, о чём автор предупреждает в каменте. Так же присутствует разблуривание лайтмапы. Не думаю, что он это подсмотрел у китайца, скорее тоже модная тенденция. Делюкс-маппинг хранится в RGBA, четвертый компонент то самое, что я предлагал - окклюжен. Для того, чтобы спекуляр в тени не бликовал. Переотражение делюксмапы для радиосити я незаметил. Может не там смотрел. Виз обычный, за исключением одного любопытного момента - каждые 5 минут он сейвит текущий прогресс и можно досчитать виз позже. Нечто подобное вальва делала для рада, там трансферы сохранялись на диск.
Post automatically merged:
Для функдетайлов забавно сделано перенесение брашей в общемировую группу, в момент загрузки мира, все энтити чекаются еще раз и все найденные детайлы просто дописываются в конец списка мировых брашей. А в обычном режиме игнорируются. Так же реализована моя идея компилируемых префабов, но не в том виде, в котором предлагал я, а на уровне компиляции. Сам префаб хранится в .map, компилятор самостоятельно грузит эту карту и встраивает её на место, указанное маппером. Не знаю, может у этой замуты какое-то иное назначение.
Post automatically merged:
Теперь по детайлам. Всё как я и предполагал:
Код:
/* Two passes - exhaust all non-detail faces before details */
for (pass = 0; pass < 2; pass++)
Это чтоб вы понимали - код со второй кваки. Детайлы второй кваки славятся тем, что режут геометрию сами и их тоже режут секущие плоскости. Но делается это в самую-самую последнюю очередь. То есть, если прямо не нашлось ничего подходящего в структуральных брашах. То есть они вроде бы и детайлы, но толку с них мало. Разве что порталы не режут. Настоящие детайлы были в сорсе и ку3, но там и формат BSP меняли под это дело, а так же переписывали движок. Настоящие детайлы в VHLT, без изменения формата - это по сути маленькое настоящее чудо от китайца.
Давно ничего не писал. Вообщем тут такая тема интересная вылезла. Для ускорения рассчётов в BSP используется хэширование вертексов, что само по себе достаточно нетривиальная задача, поясню, чтобы нормально захэшировать вертекс, надо как-то закодировать его координаты в одну переменную, ну примерно так: z * hash_size * hash_size + y * hash_size + x; Получившееся значение с гарантией выйдет за лимиты 32-битной переменной, поэтому так никто не делает, а делают обычно y * hash_size + x; Т.е. предполагается, что XY у нас имеют уникальные значения, а Z мы быстренько переберём в небольшом хэш-списке. Проблема в том, что вероятность поймать коллизию в таком хэше процентов 15. Оригинальные функции от кармака пропускали примерно 500 дубликатов из 5000 вертексов. Китаец поругался на этот хэш, мол всё неправильно и замутил какую-то сложнейшую систему. Я ради интереса решил проверить. 300 дубликатов китайский хэш пропустил. Теоретически можно вообще на него наплюнуть, используя линейный поиск который ничего не пропускает. Но надо протестировать насколько это замедлит компиляцию.
Post automatically merged:
Да, забыл написать почему дубликаты вертексов это плохо. Дубликаты провоцируют несглаженные нормали в раде, поскольку угловые вертексы ищутся не по совпадению координат самих вертексов, а по совпдающим номерам ребёр, для ускорения процесса. Естественно начинается чертовщинка, особенно для углов. Впрочем как я подозреваю, это далеко не единственная проблема.
2 Дядя Миша:
БСП это самый быстрый компилятор, не думаю что сильно критично если он будет работать в 2-4 раза медленнее, пусть лучше всё смотрит, особенно если это поможет избежать к примеру вот этих вот битых фейсов дурацких, которые я тебе неоднократно показывал. От них не спасает ни триангуляция браша, доступная в джеке, ни расставление вертексов строго по сетке. Никогда не угадаешь где они вылезут.
Одно дело - когда речь о построении света - тут можно какие-то трюки делать для ускорения, а другое - когда о базовой визуальной геометрии, здесь ящитаю приоритет на абсолютное качество. Виз никак нельзя ускорить, или построение листов - дело тоже высокоточное?