какая фильтрации разница, слева направо или справа налево?Дядя Миша said:
2 Дядя Миша: ты посмотри в атласе, что там фильтруется.
2 Дядя Миша: можно хотя бы просто посмотреть лайтмапу как картинку.
Может быть стоит тестировать компиляторы на кастомных картах, и не кидать нам сюда скрины c1a0d и всякого другого старья? Карты thambs'а идеально подойдут в качестве примеров. На них будет действительно видно изменения в компиляторах.Дядя Миша said:
2 Ku2zoff: я вчера отловил багу, которая вылезала только на карте-коробке.
Не торопись, до всего дойдет очередь.
Слева классическая привязка люксель к текселю, справа - люксель к юниту.
Собственно, я про этот артифакт уже говорил. Ну это из самого наглядного.
Не торопись, до всего дойдет очередь.
Post automatically merged:
Слева классическая привязка люксель к текселю, справа - люксель к юниту.
Собственно, я про этот артифакт уже говорил. Ну это из самого наглядного.
Attachments
Last edited:
2 Дядя Миша:
Как будет работать вторая схема? Только под Ксашем, или под ГС тоже? Если только под Ксашем, то потребуется ли для этого отдельный/дополнительный обсчёт РАДом?
Как будет работать вторая схема? Только под Ксашем, или под ГС тоже? Если только под Ксашем, то потребуется ли для этого отдельный/дополнительный обсчёт РАДом?
Если юниты минимизируют отклонения - зачем вообще было вводить какие-то там тексели? Какие подводные камни? Подозреваю что это такой же логический косяк вступающий в противоречие с физикой: когда казалось "логичным" завязать развёртки моделей на разрешение, как в оригинальной хл. Большей идиотической срани представить трудно, с гуляющими координатами.
ЗЫ: всё больше складывается впечатление, что вальва на заре становления подбирала программистов с сильно завышенным самомнением, с полной уверенностью в собственной правоте. Тк мочить такую херню могут только ЧСВшные подростки, покладая **й на всевозможные фактические исследования и доводы рассудка. Ну или хорошие менеджеры. В эту пользу говорит целый компромат серьёзных багов, на которые вальва успешно положила жирный болт даже не пытаясь разобраться: лишь бы в релизе работало, что полностью соответствуюет любой бизнес-модели продукта, который должен быть в топе. ААА-гаемс, как щас говорят.
ЗЫ: всё больше складывается впечатление, что вальва на заре становления подбирала программистов с сильно завышенным самомнением, с полной уверенностью в собственной правоте. Тк мочить такую херню могут только ЧСВшные подростки, покладая **й на всевозможные фактические исследования и доводы рассудка. Ну или хорошие менеджеры. В эту пользу говорит целый компромат серьёзных багов, на которые вальва успешно положила жирный болт даже не пытаясь разобраться: лишь бы в релизе работало, что полностью соответствуюет любой бизнес-модели продукта, который должен быть в топе. ААА-гаемс, как щас говорят.
Last edited:
Как думаешь, правду они говорят что у них ближе к релизу взорвалась CVS?Raid said:
2 Qwertyus: только под ксашем, да. Естественно всё освещение придется пересчитать.
Вообще касательно тех или иных решений, которые сейчас кажутся идиотизмом - на момент выхода первокваки, не то что видеокарт не было в природе, точнее 3д-ускорителей, OpenGL и DirectX находились в противозачаточном состоянии, но самое главное - у большинства компы даже дуум тянули не особо охотно, не говоря уже про кваку. Я её пускал на 486-м, AMD-k5 150 Mhz. Она еле-еле ворочалась в разрешении 320х200. Это сейчас большинство изменений проходит бесследно для производительности. Откуда вы знаете как бы это повлияло на тогдашние машины.
Эту привязку сделал еще Кармак. Значит тогда был какой-то смысл.
На Порнхабе почему-то нет краундфандинга и коворкинга тоже нет.
Не ближе к релизу, а 26-го апреля 1986-го года. И не CVS, а ЧАЭС. А так верно.
Post automatically merged:
Вообще касательно тех или иных решений, которые сейчас кажутся идиотизмом - на момент выхода первокваки, не то что видеокарт не было в природе, точнее 3д-ускорителей, OpenGL и DirectX находились в противозачаточном состоянии, но самое главное - у большинства компы даже дуум тянули не особо охотно, не говоря уже про кваку. Я её пускал на 486-м, AMD-k5 150 Mhz. Она еле-еле ворочалась в разрешении 320х200. Это сейчас большинство изменений проходит бесследно для производительности. Откуда вы знаете как бы это повлияло на тогдашние машины.
Last edited:
ДМ, а ты когда CSG чинил, занимался проблемой генерации лишних плоскостей типа тех что Crazy Russian показывал на cs_mansion при пересечении двух 8-угольных туннелей?
2 crystallize: я наработки китайца использовал, думаю он это починил еще до меня.
Так, ну вот вам наглядно преимущества халфовских длайтов на лайтматрице, с привязкой к юниту вместо текселя. Конечно для паранои, да и для ксаш-мода это не имеет значения, там фонарики от скейла не зависят, но я стараюсь мыслить масштабно, поэтому мои наработки сразу идут по разным направлениям. Это тоже пригодится.
Первые два скрина - привязка к текселю, вторые два скрина - привязка к юниту.
Post automatically merged:
Так, ну вот вам наглядно преимущества халфовских длайтов на лайтматрице, с привязкой к юниту вместо текселя. Конечно для паранои, да и для ксаш-мода это не имеет значения, там фонарики от скейла не зависят, но я стараюсь мыслить масштабно, поэтому мои наработки сразу идут по разным направлениям. Это тоже пригодится.
Первые два скрина - привязка к текселю, вторые два скрина - привязка к юниту.
Attachments
Last edited:
Странно, на прежних скринах не было таких конских артефактов на текселях. Там точно больше никаких проблем не осталось?
Почему для текселей переход от лампы к стенке более мягкий чем для юнитов?
Почему для текселей переход от лампы к стенке более мягкий чем для юнитов?
2 crystallize: на прежних скриншотах я вам эту лампу не показывал.
Я вам показывал то, что хорошо осветилось. А вы думали что весь уровень так же осветился и говорили - давай скорей затестить.
Нашёл причину этого бешеного китайского сглаживания. Условие #ifdef HLRAD_GROWSAMPLE
И снова - ни единого комента о том, что это такое.
Я вам показывал то, что хорошо осветилось. А вы думали что весь уровень так же осветился и говорили - давай скорей затестить.
Post automatically merged:
Нашёл причину этого бешеного китайского сглаживания. Условие #ifdef HLRAD_GROWSAMPLE
И снова - ни единого комента о том, что это такое.
Last edited:
Нет, почему: http://cs-mapping.com.ua/forum/showpost.php?p=935701&postcount=126Дядя Миша said:
Так а там что, куча поинтлайтов ещё всунута вдобавок к лампам?
Last edited:
Ты видишь как называются эти скриншоты? vhlt_0000 и vhlt_0001.
Не, это патчей маловато сгенерилось для сурфлайта.
Post automatically merged:
Это всё что удалось найти про HLRAD_GROWSAMPLE от самого китайца.
Насчёт времени компиляции - оно практически не меняется. Как было 32 секунды так и осталось (для сравнения мой компилятор управляется за 3 секунды, т.е. в 10 раз быстрее, выдавая схожий результат).
Скриншоты слева направо - сглаженный VHLT, VHLT с отключённым GROWSAMPLE и p2rad. Помоему VHLT без GROWSAMPLE артефачит даже хлеще.
Можно конечно взять этот китайский код к себе, но мне хочется поэкспериментировать. Как я понимаю GROWSAMPLE это увеличение конечного размера лайтмапы с последующим даунскейлом, но поскольку код китайский - он максимально запутан. Есть и более простые способы - например накрутить скейл через texture_step, умноженный на коэффициент, а потом даунскейлить и блюрить лайтмапу в 2д. Но! Как я уже упоминал, любая попытка блюрить и даунскейлить лайтмапу приводит к негативным последствиям и лайт-ликам, именно из-за того, что это операция над картинкой. Интересный выход из положения я увидел в TyrUtils - там для лайтмапы сохраняются еще и окклюдед-пиксели и при даунскейле эта информация учитывается. Как раз для того, чтобы свет не вылазил из-под стены. К тому же эта информация всё равно потом пригодится, я планировал её сохранять изначально.
Post automatically merged:
Вообще говоря, вот это вот:
Подразумевает под собой трансляцию из одного текстурного пространства в другое, что в общем случае гораздо более сложная задача, т.к. текстурные матрицы часто взаимно перпендикулярны друг-другу. Ну не перпедикулярны, а тангента или бинормаль смотрят в противоположные стороны, как в примере на той колонне. Для люкселей привязанных к юниту ситуация полностью противоположная - там связь между люкселями почти идеальная, даже без дополнительных трансляций. Так что в перспективе сглаживание должно выйти на порядок лучше. Вообще без артифактов.
Post automatically merged:
Почитал что пишет китаец про свои релизы. Он обычно немногословен. Но кое-что интересное удалось узнать. Например BrinkHack, который исправляет клипноды, путём непосредственного вмешательства в уже построенное дерево, появился не потому что исправляет какие-то фатальные недостатки самой коллизии по хуллам, а потому что (со слов самого китайца), его брашы для клипнодов слишком идеальны, в отличие от старых, калечных. Отсюда и ошибка.
Не вдаваясь в справедливость этого утверждения, тем не менее вывод можно сделать именно тот, который я предполагал с самого начала - сперва мы строим идеальные клипноды, в которых почему-то появляются зацепы на углах. А потом по-бырому пишем код, который объемом превышает весь код CSG, для борьбы с этим явлением. Самое страшное, что этот механизм еще и работает и достаточно неплохо. Правда не слишком быстро. Так что да, мем "китайский код", это не стёб и не прикол.
Post automatically merged:
Впрочем. Китаец упоминал про какие-то ошибки в движке. Вероятно надо подкрутить эпсилоны в SV_RecursiveHullCheck.
Attachments
Last edited:
Доноры Красавчики
-
AHTu6uoTuK$285.00 -
TRUP@C$136.00 -
PoD-Stas$100.00 -
Somano$60.00 -
MAPA3MATuK$55.00
Members online
No members online now.