![]() |
Страницы (255): « Первая ... « 126 127 128 129 [130] 131 132 133 134 » ... Последняя » Показать все 3825 сообщений этой темы на одной странице |
HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Наши проекты (https://hlfx.ru/forum/forumdisplay.php?forumid=1)
-- XashNT: блог разработчика (https://hlfx.ru/forum/showthread.php?threadid=5297)
Неудивительно отчего в халфе такое освещение всратое.
Оно там сначала клипается, а уже потом умножается на гамму.
Чёрт его знает как оно после этого выходит за границы Byte.
Главное и у меня в P2St точно так же. Я этот момент вообще не трогал.
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Но на гамму нужно не умножать, а возводить в степень
ncuxonaT ну я выразился немного некорректно. Я про последовательность действий.
Опробовал VTF для симуляции повертексного освещения. Ну как я и предполагал - всё сработало отлично. На ландшафте, понятное дело, всё превратилось в пятна, на ёлках-соснах в целом без особых изменений.
Но есть два момента. Во первых фпс упал почти на 1/8. Т.е. было 800 фпс, стало 700. Может быть это GT640 не слишком любит VTF.
Второй важный момент - повертексное тут не решит ничего, потому что для лайтмапы и для вертекса, во всяком случае на граничных точках, считаются те же самые позиции, те же самые нормали и та же самая окклюзия.
То есть повертексное само по себе тут разве что уберёт швы на лайтмапе, а больше от него толку не будет. А на деревьях нам надо рассчитать нормали по полусфере или взять какой-то зазор у источника света, ну халф-ламберт или что-то такое. Но с нормалями вообще тяжко. Они как правило невалидные все, мусор. Редко-редко когда попадется модель с исправными.
Я полагаю, чем генерить для листвы эти хитрые нормали, проще в материал дать подсказку. Ну то потом.
Добавлено 23-12-2020 в 19:15:
Набрался хабразде и решил повторить подвиг Элбера - собрать объединённую ЧАЭС из двух карт. Но, т.к. редакторами я не владею, решил пообъединять их в блокноте, посмотрел и понял, что это довольно-таки просто сделать. Пропсы на двух картах не пересекаются, а значит можно смело добавлять их в одну. Террайн взял тот, что поподробнее, проблема только в статик меше, то что есть в одном - отсутствует в другом.
Добавил сразу оба, а в компилятор ввёл проверку на дублирующуюся геометрию. Чтобы он мне просто повыкидывал лишние полигоны с этого же места. И это таки сработало! Собралась такая карта, весит 132 мегабайта.
Причём потребление компилятора во время работы не превысило даже 1 гигабайт, а ведь это пожалуй самая гигантская карта из всех, даже в лост-альфе нет такого ужоса. Всё прекрасно скомпилилось, правда свет я не считал еще.
Добавлено 23-12-2020 в 20:48:
Кстати, к вопросу о швах. Вот пример шва:
Кажется что всё ужасно. Но давайте включим диффузку.
А если посмотреть с другого ракурса, становится понятна и причина:
Там не просто шов, там еще и выступ. Конечно в идеале даже этого быть не должно, но уже вполне юзабельно.
Добавлено 23-12-2020 в 20:50:
Основная причина этих швов - неравномерность и сдвиги люксельной сетки.
Если мне удасться решить эту задачку, швов вообще не будет.
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Ну вот, если кому-то интересно, как выглядит повертексное через VTF
Добавлено 24-12-2020 в 09:57:
Способ хорош тем, что имея лайтмапу мы всегда сможем превратить её в повертексное освещение, например для маскировки швов на маленьких моделях. А вот наоборот уже хрена. Поэтому предпочтительнее считать и хранить лайтмапу вообще для всего, а повертексное не считать вовсе.
Тем более что, я вообще не планирую хранить значения освещённости в самих вертексах, я не представляю как это грамотно сделать для инстанс-моделей. В параное, как вы помните, при загрузке из оригинальной модели и массива повертексного освещения, налиту создавался дубликат, отчего потребление видеопамяти зашкаливало. Вероятно есть какие-то средства, чтобы объединять налету два массива. Скорее всего если массивы сгруппированы по атрибутам. Массив вертексов, массив текстурных координат, массив цветов. Вот в таком раскладе это работает. Но я не планирую так делать, это устаревший подход.
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Подшаманил мержинг сурфейсов, теперь ЧАЭС собирается 20 минут вместо часа. Причём 16 минут - это построение атласа. Очень уж этот уголок тормозной даже удивительно. Надо бы с этим что-то сделать.
Но тут двояко. Любой модный прогрессивный алгоритм с эвристикой чую будет работать еще дольше, сталкеровское попиксельное построение атласа вообще дико медленное, вот и фиг знает что его делать.
Добавлено 24-12-2020 в 13:58:
Кстати у меня тут есть одна любопытная идейка насчёт Кармаковского алгоритма, надо будет проверить.
Добавлено 24-12-2020 в 14:00:
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Crystallize ты про edge-detection совсем ничего не слышал?
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
А чего это скрины такие мелкие? Даешь FHD!
__________________
Killing Floor: Horzine Outbreak
Внедрил прогрессив-мешы. Спорная штука. Во первых она почти не поддаётся контролю. На параметры реагирует слабо. Во вторых, она сама решает насколько меш может быть симплифицирован, вот на одних прямо втрое получается, а на других - дай бог чтобы на 20%.
Не угадаешь. От топологии вероятно зависит. В некоторых случаях вообще полный фейл, т.е. работа проделана, а симплификации - нет.
Но результат в целом очень деликатный. Одно скользящее окно удаляет из исходного меша 1 вертекс, поэтому заметить деградацию с расстоянием игроку невозможно в принципе, как бы он не присматривался. Другое дело, что в среднем такие лоды снижают поликаунт ну максимум на треть, даже не вдвое. Ну я еще потыкаю, может сделаю алгоритм более агрессивным.
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Кстати, вот какая еще мысль мне пришла в голову. Для MU-моделей можно использовать ковариантную проекцию лайтмапы, она пытается из облака точек вычленить уникальную нормаль проекции, даже если объект замкнут сам на себя. Т.е. сфейлить она не может никогда. Но такая проекция обычно бывает очень растянута. Но для MU-моделей, которые в большинстве своём ёлки-метёлки, это даже лучше, т.к. будет чем-то напоминать повертексное освещение, только с большим разрешением. Ну и естественно - никаких швов. Впрочем. наверное там лучше завести переключатели всякие в материале.
Добавлено 26-12-2020 в 13:34:
Опробовал. Ну да, ковариантная проекция на MU-моделях выглядит очень растянуто, освещение перезатекает аж назад на дерево, но зато нету швов.
И очень-очень похоже на повертексное.
Я думаю надо сделать вот как. По дефолту - пусть остается ковариантная.
А если юзер прямо создал крутую текстурную развертку, из которой не стыдно строить лайтмапу, то можно переключиться на нее.
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
nemyax без самопересечений, без дегенеративных UV-островков.
Добавлено 26-12-2020 в 19:34:
ну чтож, финальный штрих - радиосити.
В данном случае надо просто наспавнить вторичных аналитических источников света от поинтлайтов. Ну можно и от лайтспотов тоже.
А потом эти лайты будут участвовать в общем процессе освещения.
Т.е. свет посчитается сразу как прямой, так и отражённый, не надо будет ничего там вымучивать в несколько проходов.
Добавлено 26-12-2020 в 21:26:
Кстати, насчёт завершения истории с прогрессив-мешами.
У меня тут, собственно, было два варианта. Bunnylod от Stan Melax, ну вы его все видели. И jmspmesh от Jeff Somers. второй - это вьювер с четырьмя самыми известными методами - QEM, QEM weighted by area, реализация от Stan Melax и shortest path (не знаю кто автор).
QEM и QEM weighted by area представлены так же библиотекой qSlim.
Пока я совал этому вьюверу модельки, идущие с ним в комплекте - всё было хорошо. Даже отлично. Но как только я переконвертил сталкеровские модельки и начал совать их - тут же начался тихий ужос. Оно вообще не в состоянии их адекватно обработать. Так что SWPM от Tom Forsyth, которую юзает сталкер - наименьшее зло. Да, оно симлифицирует до определённого порога. Но модель хотя бы не превращается в кашу на произвольном уровне симплификации.
Добавлено 26-12-2020 в 22:40:
Кстати. Shortest Edge, это нечто навроде метода от Stan Melax, только еще проще - без учёта курватуры. Как говорится, уже тупее некуда - выкидывается самое короткое ребро. Там вообще математики нет, если не считать VectorLength. Я этот метод опробывал тоже, слегка доработав реализации BunnyLod. И знаете - мне понравилось. И даже очень.
Добавлено 26-12-2020 в 22:52:
Минималка, 30% от исходного меша. Если ниже, то там уже полная дигродацыя начинается.
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Временная зона GMT. Текущее время 00:59. | Страницы (255): « Первая ... « 126 127 128 129 [130] 131 132 133 134 » ... Последняя » Показать все 3825 сообщений этой темы на одной странице |
На основе vBulletin версии 2.3.0
Авторское право © Jelsoft Enterprises Limited 2000 - 2002.
Дизайн и программирование: Crystice Softworks © 2005 - 2024