Шашечки на лайтмапе смотрятся ниоч.
Ну вот, а ты говоришь, китаец починил CSG.Дядя Миша said:
Ну и решил затестить TyrUtils на предмет освещения. Фонг отключён по дефолту, швы никуда не делись, остались. Даже переход между копланарными фейсами заметен. Заодно сравнил производительность embree. Ну почти на уровне с халфовской трассой, процентов на 5 медленее. Но embree умеет кэшировать результаты трассы и вероятно на больших картах это даёт эффект.
Да этот угол у меня лучше запекается
Attachments
Ыщо, скриншотов вам в ленту.
Тексель - юнит. На этой паре видны сплошные преимущества отвязки люкселя от текселя, однако есть места, которые наоборот слегка деградировали. На прошлой паре скринов потолковые балки утратили плавный переход. Но там в принципе какие-то багги, так что я пока не могу сказать определённо, кто виноват.
2 ncuxonaT: а ты привёл формулы освещения к халфовским?
ЗЫ. и швы от пожарного ящика тоже никуда не делись
Тексель - юнит. На этой паре видны сплошные преимущества отвязки люкселя от текселя, однако есть места, которые наоборот слегка деградировали. На прошлой паре скринов потолковые балки утратили плавный переход. Но там в принципе какие-то багги, так что я пока не могу сказать определённо, кто виноват.
Post automatically merged:
2 ncuxonaT: а ты привёл формулы освещения к халфовским?
Post automatically merged:
ЗЫ. и швы от пожарного ящика тоже никуда не делись
Attachments
Last edited:
Нет, потому что они дно
Огромная, как жопа мамаши анальных первопроходцев ZHLT просьба: убрать к пёсьим удам эти сраные надписи, заменив их автоподменой шашечной текстурой. У меня в голове не укладывается как можно было написать редактор так, чтобы была такая срань - какой уровень рукожопия должен быть у авторов как первичного хаммера, который эти ошибки допускает, так и у авторов компиляторов, который из-за этих ошибок останавливается нахер. Ну видишь ты оторванный фейс. Ну округли до ближайших координат. Ну триангулируй, если битый. Если не получается округлить - ну сгенерируй тетраэдр или ещё как-то соедини вертексы. Но нет, б**дь, раньше лёгких путей не искали. Надо обязательно остановить вообще всё по любой мелкой х**не, Небо, аллаха - насрать что там целая огромная карта с тысячами брашей и гагабайтом лайтмап. Жизненно необходимо остановить весь компил только потому что один фейс битый, вместо того чтобы его пометить в самой карте, вместе со сраными этими текстуропроблемами, берущимися из ниоткуда.
Attachments
Last edited:
Ну халфовский рад ты использовал хотя бы?ncuxonaT said:
2 crystallize: да, и от этого он не стал лучше
2 Raid: между компиляторами и потребителем их продукта (например тем же движком), существует принципиальная разница в обработке ошибок. Компилятор не должен вносить отсебятину, он должен показывать пользователю на реально существующие проблемы. А не исправлять это. Вот движок, тот да, у него уже нет выбора, будет работать с чем дали.
2 Дядя Миша:
Да у меня анально бомбит просто, не обращай внимания. Всё было конвексное (ну не всё, но работало, там какие-то отслоившиеся фейсы откуда-то вылезли), а потом вдруг перестало - и начиналась дрочь с поиском по координатам. Но вообще смысл тот, что работать должно при любом раскладе, а об ошибках уведомлять - как в консоль, так и в игре как-то помечая проблемные участки. Чтобы работало - при любом раскладе - как раз нужны отключаемые автотриангуляторы, автоспайщики, и автоокругляторы крошащие неконвексные браши на конвексные фрагменты и достраивающие фейсы (или удаляющие если совсем срань какая-то вылазит). В общих чертах это выглядит так: ты сделал карту с хитровыкрученным камнем. Пришёл посмотреть - а его расхерачило на тетраэдры со щелями в полметра. Вывод однозначен сразу: это надо переделать. Но! Вся остальная карта остаётся доступна для тестирования, просто потому что она собрана. В этом смысл. Остановка компиляции - это уже из области точной подгонки финальной.
Да у меня анально бомбит просто, не обращай внимания. Всё было конвексное (ну не всё, но работало, там какие-то отслоившиеся фейсы откуда-то вылезли), а потом вдруг перестало - и начиналась дрочь с поиском по координатам. Но вообще смысл тот, что работать должно при любом раскладе, а об ошибках уведомлять - как в консоль, так и в игре как-то помечая проблемные участки. Чтобы работало - при любом раскладе - как раз нужны отключаемые автотриангуляторы, автоспайщики, и автоокругляторы крошащие неконвексные браши на конвексные фрагменты и достраивающие фейсы (или удаляющие если совсем срань какая-то вылазит). В общих чертах это выглядит так: ты сделал карту с хитровыкрученным камнем. Пришёл посмотреть - а его расхерачило на тетраэдры со щелями в полметра. Вывод однозначен сразу: это надо переделать. Но! Вся остальная карта остаётся доступна для тестирования, просто потому что она собрана. В этом смысл. Остановка компиляции - это уже из области точной подгонки финальной.
Last edited:
>Компилятор не должен вносить отсебятину, он должен показывать пользователю на реально существующие проблемы
Ещё как должен. Иначе всё это преврашается в идиотизм вида:
и так 20 раз. Ну а потом к нам в часть спирт завезли, ну и я перестал компилировать.
Ещё как должен. Иначе всё это преврашается в идиотизм вида:
Code:
10 СМЕСТИЛ 2 БРАША
20 ПОДОЖДАЛ ПОЛЧАСА
30 GOTO 10
2 Raid: Texture Axis perpendicular to face не останавливает компиляцию, и даже скорее всего к проблемам не приведёт. А с привязкой люкселей к юнитам, эта проблема вообще перестанет существовать, по идее.
А насчёт тетраэдров - я сейчас как раз и делаю такие компиляторы, чтоб жрало всё.
2 GNU/Hurt: есть тонкая грань между внутренними проблемами самого компилятора и косяками левел-дизайнера. Если микродырки и вырожденные браши можно списать на несоврешеннство среды и нехватки точности вещественных чисел, то криво наложенная текстура - это проблема исключительно дизайнера. Но это значит что надо останавливать процесс компиляции. Я отревизил все фатальные остановки, условно разделив их на две группы. Первая группа - для дизайнеров. В нее включены все остановки вида MAX_MAP_BUTERBRODS limit exceeded. Все что не имеет такого вида - это скорее всего внутренние ошибки компилятора, которые вообще не должны присходить, но маппер навряд ли может с этим что-то сделать. А вот всякие варнинги, типо texture axis perpendicular to face, leaf portals saw into leaf, point off plane или texture not found, компиляцию не останавливают. К тому же я полагаю, что вывод в консоль координат проблемного места - разновидность идиотизма. Пусть лучше карта соберётся и маппер своими глазами этот косяк увидит. Если он вообще вылезет визуально. Ну тут по аналогии с предупреждениями компилятора студии - он может выдать тонну предупреждений, unreferenced local variable, но это ни на что не повлияет. Так же и с картами и вообще с любым процессом компиляции - не каждое предупреждение приводит к каким-то нехорошим последствиям.
======================
Продолжаю ковырять сглаживающие алгоритмы VHLT. Китаец написал не менее десятка всевозможных улучшений, которые в лучшем случае влияли очень локально и незначительно, но при этом увеличивали время компиляции. Потом он плюнул и заморочился над фундаментальным решением - вот как раз через GROWSAMPLES. Там смысл в матричных преобразованиях, из текстурного пространства одного фейса в текстурное пространство другого фейса. Я не уверен, что это наилучшее решение, хотя сам подход верный. Скажем вальва в сорсе преобразует из текстурного пространства в 2д и накладывает лайтмапу в двухмерке. Такой подход гораздо проще.
А насчёт тетраэдров - я сейчас как раз и делаю такие компиляторы, чтоб жрало всё.
2 GNU/Hurt: есть тонкая грань между внутренними проблемами самого компилятора и косяками левел-дизайнера. Если микродырки и вырожденные браши можно списать на несоврешеннство среды и нехватки точности вещественных чисел, то криво наложенная текстура - это проблема исключительно дизайнера. Но это значит что надо останавливать процесс компиляции. Я отревизил все фатальные остановки, условно разделив их на две группы. Первая группа - для дизайнеров. В нее включены все остановки вида MAX_MAP_BUTERBRODS limit exceeded. Все что не имеет такого вида - это скорее всего внутренние ошибки компилятора, которые вообще не должны присходить, но маппер навряд ли может с этим что-то сделать. А вот всякие варнинги, типо texture axis perpendicular to face, leaf portals saw into leaf, point off plane или texture not found, компиляцию не останавливают. К тому же я полагаю, что вывод в консоль координат проблемного места - разновидность идиотизма. Пусть лучше карта соберётся и маппер своими глазами этот косяк увидит. Если он вообще вылезет визуально. Ну тут по аналогии с предупреждениями компилятора студии - он может выдать тонну предупреждений, unreferenced local variable, но это ни на что не повлияет. Так же и с картами и вообще с любым процессом компиляции - не каждое предупреждение приводит к каким-то нехорошим последствиям.
Post automatically merged:
======================
Продолжаю ковырять сглаживающие алгоритмы VHLT. Китаец написал не менее десятка всевозможных улучшений, которые в лучшем случае влияли очень локально и незначительно, но при этом увеличивали время компиляции. Потом он плюнул и заморочился над фундаментальным решением - вот как раз через GROWSAMPLES. Там смысл в матричных преобразованиях, из текстурного пространства одного фейса в текстурное пространство другого фейса. Я не уверен, что это наилучшее решение, хотя сам подход верный. Скажем вальва в сорсе преобразует из текстурного пространства в 2д и накладывает лайтмапу в двухмерке. Такой подход гораздо проще.
Last edited:
2 Raid: если тебя визуально ничего не парит, то и смысл искать проблему?
А на клипхуллы дизайнер всё равно не влияет.
======================
В сорсе обнаружил любопытную вещь - в FinalLightFace идёт радиальное сглаживание по соседям. Не средневзвешенное, а медианное (ну это как у нас зарплаты считают). Т.е. по уже готовым люкселям. Этот подход скорее всего сработает на углах в 90 градусах, чего принципиально нет у китайца. Вообщем будем тестить. Вы наверное обращали внимание, что VHLT начинает рассчёты освещения с FindFacePositions. Это вот как раз часть GROWSAMPLES. На с1a0d, их рассчёт занимает порядка одной секунды. Для VHLT, где BuildLightFaces занимает 29 секунд, это выглядит нормой, но не для моих компиляторов, где весь свет на экстра считается за три секунды. Я уже вчера пытался там оптимизировать всё возможное, но там какая-то чудовищная работа проделывается и подозреваю по большей части бесполезная. Это ясно уже по самому подходу поиска оптимальных позиций. Т.е. хаотичное метание по фейсу, проверки, подталкивание позиций, снова проверки и так - пока не найдет. Учитывая что геометрия там уже прошла CSG и избавилась от ненужных пересечений, у нас почти идеальный случай. Потом расскажу к каким выводам я пришёл в итоге.
А на клипхуллы дизайнер всё равно не влияет.
======================
В сорсе обнаружил любопытную вещь - в FinalLightFace идёт радиальное сглаживание по соседям. Не средневзвешенное, а медианное (ну это как у нас зарплаты считают). Т.е. по уже готовым люкселям. Этот подход скорее всего сработает на углах в 90 градусах, чего принципиально нет у китайца. Вообщем будем тестить. Вы наверное обращали внимание, что VHLT начинает рассчёты освещения с FindFacePositions. Это вот как раз часть GROWSAMPLES. На с1a0d, их рассчёт занимает порядка одной секунды. Для VHLT, где BuildLightFaces занимает 29 секунд, это выглядит нормой, но не для моих компиляторов, где весь свет на экстра считается за три секунды. Я уже вчера пытался там оптимизировать всё возможное, но там какая-то чудовищная работа проделывается и подозреваю по большей части бесполезная. Это ясно уже по самому подходу поиска оптимальных позиций. Т.е. хаотичное метание по фейсу, проверки, подталкивание позиций, снова проверки и так - пока не найдет. Учитывая что геометрия там уже прошла CSG и избавилась от ненужных пересечений, у нас почти идеальный случай. Потом расскажу к каким выводам я пришёл в итоге.
Насмотревшись на радиально-медианное сглаживание финальных лайтмап в сорсе, решил взапроверить чего буит на практике. Тем более шта в сорсе все эти карты от первохалфы давно скомпилены. Результаты на скриншотах. Полутьшы стало, безусловно, но далеко от идеале.
Вообщем механизм идеального сглаживания у меня вырисовывается примерно следующий: трансляция фейс-ту-фейс от китайца, радиальное сглаживание готовых лайтмап по сорсовскому методу ну и ессно ворлд-люксели. Ну и чтоб это всё было шустро.
Вообщем механизм идеального сглаживания у меня вырисовывается примерно следующий: трансляция фейс-ту-фейс от китайца, радиальное сглаживание готовых лайтмап по сорсовскому методу ну и ессно ворлд-люксели. Ну и чтоб это всё было шустро.
Attachments
2 Дядя Миша: почему не сделать как в The Last of Us?
http://miciwan.com/SIGGRAPH2013/Lighting Technology of The Last Of Us.pdf
страницы 8-12
http://miciwan.com/SIGGRAPH2013/Lighting Technology of The Last Of Us.pdf
страницы 8-12
-Что такое радиально медианное сглаживание? Скрины с HL: Source?
-Почему в Valve не юзали func_wall?
-Почему в Valve не юзали func_wall?
Доноры Красавчики
-
AHTu6uoTuK$285.00 -
TRUP@C$136.00 -
PoD-Stas$100.00 -
Somano$60.00 -
MAPA3MATuK$55.00
Members online
No members online now.