Я сначала подумал что сам меш спонзы целиком загрузили, но как оказалось это теже браши просто на модельках ткани лайтмапы. Выглядит ничего так, получше вертексного освещения.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
FiEctro писал: Выглядит ничего так, получше вертексного освещения.
- Лайтмапное освещение на спонзе выглядит лучше, чем вертексное.
- Чем?
- Чем вертексное.
Имхо, освещение должно быть незаметным. То есть нет ощущения, что объект выбивается яркостью, или наоборот, слишком чёрный. Никто не будет ползать по уровню с лупой и разглядывать каждый пиксель. В крузисе для этих целей вот вообще скрин-спейс амбиент окулижен запилили, и были таковы!
Но грязи на лайтмапах быть не должно, вот что.
Между прочим, этот ваш хвалёный q3map2 он што делает? Он на мелких поликах аппроксимирует люксели с вертексного. А у меня значит при малых разрешениях лайтмапы там артефакт на артефакте, ну понятно.
Добавлено 27-06-2019 в 13:45:
Впрочем ладно, сперва надо с рейтрейсером разобраться.
Добавлено 27-06-2019 в 17:42:
Рейтрейсер, я починил, если кому-то интересно, но непонятно - в сорсе лайтмапы рейтрейсер считает, папка raytrace в SDK. Типа такое ускорение по сравнению с медленной кудвашной трассой. Я не готов сделать окончательный вывод, тут слишком много факторов. Может быть в вальве не дружат с SSE. Камрад Ксерокс неоднократно мне на это намикал. Может быть KD-tree для этих дел не слишком годится. Может еще какие-то факторы. Я переписал его с SSE обратно на FP, справедливо рассудив, что раз уж он медленее на SSE, то тут либо лыжы такие, либо шестёрка ни спровляется. Забегая вперёд, скажу, что дажы после всех моих апчхимизаций скорость его работы что на SSE что на FP, осталась идентичной. Хотя я юзал эти стримы, групповые трассы и прочие ништяки, но что-то у меня так и не заладилось. Тут видимо дело в следующем. Рейтрейсер строит дерево разом для всего мира и всех моделей. Ну можете себе представить какого размера будет это дерево. А у меня - маленькие деревца для каждой модели. И трасса их отсекает по ббоксу. И это всегда эффективнее чем траверс по дереву, ну это очевидно. Но оригинальный рейтрейс я не могу разломать на такие локальные трассы - там жы надо группами трейсить по 4 штуки, иначе от SIMD никакого толку. Неустранимое противоречие. Забегая вперёд, скажу, что я получил сопоставимую с моим референсом производительность разбив трассу на отдельные модельки.
То есть примерно те же яйца, плюс-минус доли секунды. Но какого-то профита, сами понимаете это не дало. Что остаётся в такой ситуации?
Надо еще попробовать BSP-дерево из третьего дуума, которое не режет полигоны. Оно там тоже для колоизации и возможно от него будет какой-то толк.Ну в принципе и всё. Если и это не поможет - я умываю руки. Быстрее уже не получится.
Ну чтож, проверил еще AxialBSP Tree из третьего дуума. На игрушечных картах все результаты идентичные. Тогда мне пришло в голову нагрузить как следует - я разрешил вторичке от солнца трассировать модели и выставил _spread. Тут-то все различия и вылезли на ружу. Компилировал kung.bsp, если вам интересно. Итак, референс с AABB Tree - 56 секунд.
AxialBSP Tree - 1 минута 8 секунд. Переделаный на FP рейтрейсер из сорса - 32 секунды. Так что, как видите - мои усилия были ненапрасны
На картах с моделми, типа ЧАЭС, будет заметный прирост в скорости. Единственное что меня слегка удивило - это то что Axial BSP такой тормозной. Ну правда он не режет полигоны, т.е. это как бы не совсем настоящее BSP. От такие пирожки. З котятамi.
XaeroX писал: Ты уверен, что FP-версия быстрее не из-за шестёрки?
не уверен, но повторюсь, там неразрешимое противоречие. BSP-трасса по кушному дереву не имеет себе равных по скорости. А вальвовская реализация предполагает что вся геометрия помещается в единое дерево, из-за чего оно сильно распухает, становится избыточным. Простой пример - карта-коробка, на ней высокополигональная моделька-шар. Если поместить их в дерево, получится почти три тысячи узлов. Если отдельно, то карта коробка в представлении KD-Tree 88 узлов. А для халфовского BSP - естественно шесть. То есть возникает противоречие, SIMD надо кидать по четыре трассы за раз, причём желательно в одном направлении, чтобы дерево могло для всех четырёх трасс найти необходимый лиф. А когда мы разделили трассу на локальные деревья, это фактически нереализуемо. Но это уже быстрее, т.к. вместо траверса вызывается BoundsIntersect и часть деревьев вообще игнорится. Вот при таком подходе мне действительно удалось получить прирост, от одной трети до двух раз в разных кейсах, причём тут что забавно - чем больше пучков трасс в одном направлении - тем оно быстрее, ну очевидно попадение в кэш. То есть оптимизация к которой стремились - получилась всё равно, но неявным образом и без ухудшения юзабельности с точки зрения юзера. Не надо группировать трассы по 4, не надо их набивать в стрим, возиться итд.
Добавлено 28-06-2019 в 10:46:
Там теперь новая на пасть. Intermediate-data для трассировки студиомоделей на той же ЧАЭС занимает 500 мегабайт
я достаточно вольно обращался с этой датой в процессе имплементации лайтмап на моделях и там дата фактически четырежды дублируется. Надо это дело оптимизировать конечно.
500 мегабайт это норм. Волатильный компилятор имеет привычку аллокать по 3-4 Гб оперативки на больших и сложных картах. Никаких проблем с этим нет (на 64-битных осях).
А что касается 32-битных... Для игры - ок, а для разработки - надо всё-таки апгрейдиться. Тот же джек на 32-битных иногда падает с банальной нехваткой памяти. Можно конечно уменьшать Undo levels - но лучше всё же обновить комп и поставить хотя бы 8 Гб памяти.
Перед тем как перейти на 64-х битную компиляцию, надо сперва по максимуму оптимизировать 32-х битную, ящетаю. У тебя вот ЧЭАС не компилится даже на 64-х битах, а у меня компилится на 32х.
Добавлено 28-06-2019 в 12:13:
Кстате. Я вот еще што подумал. Надо трансферы перевести с fixed point на халфы. Возможно радиосити станет полутьшы выглядеть. Но это не точно.
XaeroX ну для теста-то можно увеличить, скринов наделать там, я не знаю. Эти лайтмапы увеличить - одну константу поменять, делов-то. Уж за ради скринов можно было бы вполне. Значит там еще какие-то сложности.
Дядя Миша писал: Значит там еще какие-то сложности.
Ну да, есть ещё одна сложность - Перилос Ворп делать надо.
Тебе хорошо - экспериментируй себе да экспериментируй. А мне ещё карты надо рисовать, сюжет придумывать, спецэффекты прорабатывать.
| IP: 
27-06-2019 07:17
