HLFX.Ru Forum - XashNT: блог разработчика

Страницы (255): « Первая ... « 108 109 110 111 [112] 113 114 115 116 » ... Последняя »
Показать все 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)

Отправлено Дядя Миша 25-07-2020 в 13:45:

Цитата:

FiEctro писал:
А карты модели делать можно будет?

ну пока через вставку точечной модели в скайбокс. Впрочем, для Метро того же, карты именно так и делаются. Только там скайбокс не нужен.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 26-07-2020 в 13:22:

Вы таки будете удивлены, но даже обычный линейный свет во всех трёх кваках немного различался, ниже скриншоты.

Quake 1:

C++ Source Code:

angle = (1.0 - 0.5) + 0.5 * angle;

add = (light->photons - dist) * angle;

add = max( add, 0.0 );

В первом квейке был не Фонг, а Халф-Ламберт, из-за чего там освещение персов так идеально гармонировало с лайтмапой. Просто они были освещены единой моделью освещения.

Quake 2:

C++ Source Code:

add = (light->photons - dist) * angle;

add = max( add, 0.0 );

классический линейный свет по Фонгу

Quake 3:

C++ Source Code:

add = light->photons * 0.9375 - dist * angle;

add = max( add, 0.0 );

Тут непонятно. С одной стороны, это свет, который идеально вписывается в заданный радиус, т.е. фактор освещённости превращается в мировые юниты. С другой стороны - корректно ли это? Обратите внимание на убранные скобки, множитель практически не влияет, я его вставил, потому что он есть в самом ку3.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 26-07-2020 в 13:25:

Сделай ещё ХДР лайтмапы как в Лост коасте

У Психопата имхо самое красивое освещение получилось, остальное какое то кривое гамно, которое ещё не те цвета что выставил маппер рисует.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!

Отправлено Crystallize 26-07-2020 в 14:01:

Цитата:

Дядя Миша писал:
Обратите внимание на убранные скобки

скобки Кармак убрал, не ты?

Цитата:

FiEctro писал:
У Психопата имхо самое красивое освещение получилось, остальное какое то кривое гамно, которое ещё не те цвета что выставил маппер рисует.

Пишешь три строчки гамма-коррекции и будет те цвета рисовать.

Отправлено Дядя Миша 26-07-2020 в 16:16:

Цитата:

Crystallize писал:
скобки Кармак убрал, не ты?

Странный вопрос. Я вам показываю модели освещения из разных квак и сам скобки убираю?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 26-07-2020 в 16:33:

ИМХО ку3шный вариант самый паршивый, видите вот это уродливое белое пятно по центру с чёткими гранями? Оно занимает практически всё освещаемое пространство, когда на первых двух вариантах хоть это пятно по прежнему и присутствует, но переход уже не такой жёсткий, и мапперам нет необходимости увеличивать радиус этого уродства.

Отправлено XaeroX 26-07-2020 в 16:50:

Я полностью согласен с FiEctro в обратную сторону. Вариант в ку3 самый корректный и красиво выглядящий, разумеется, при правильных радиусах и при наличии радиосити (которой в ку3мапе нет, но могла бы быть).
Проблема в том, что он напрямую не совместим с халфовской моделью. Но и это поправимо, в принципе. В vmap я сделал поддержку обеих моделей, ну вы помните, я показывал халфовские карты под волатилой.

__________________

Отправлено Дядя Миша 26-07-2020 в 17:28:

Цитата:

FiEctro писал:
ИМХО ку3шный вариант самый паршивый

это не имеет никакого значения, дизайнер сам будет задавать формулы освещения, причём сразу для реалтайма и лайтмапы, чтобы они совпадали.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 26-07-2020 в 17:39:

Цитата:

Дядя Миша писал:
причём сразу для реалтайма и лайтмапы, чтобы они совпадали.

Для матчинга статики и динамики можно просто считать статик-лайты так же, как динамики - по радиусу с квадратичной аттенуацией, а не по фотонам. А статики оставить с полноценным затуханием. Я в волатиле так и сделал, и вы можете посравнивать картинки на статике и динамике.

__________________

Отправлено Дядя Миша 26-07-2020 в 17:57:

Ну если формулы одинаковые, какая разница где считать?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 27-07-2020 в 04:32:

Цитата:

Дядя Миша писал:
Просто они были освещены единой моделью освещения.

Так они же освещались люкселем под ногами, а не какой-то отдельной моделью освещения.

Отправлено Дядя Миша 27-07-2020 в 09:55:

Для квадратичного радиуса затухания обычные значения света подходят мало. Ну вообщем-то, как это имеет место быть для area light, вы же обращали внимание, что там значения идут от нескольких тысяч.

В Quake3 любое значение точечного лайта умножается на 7500. Не знаю почему именно 7500.
В халфе, как мы помним квадрат самого себя делится на 10 и опять умножается на себя. Таким образом.
Для халфы:
Интенсивность 100.
l1 = 100 * 100 / 10;
intensity *= l1; // 100 * 1000
Результат 100 000 едениц умножить на DLIGHT_SCALE 2.0 (по умолчанию директ в халфе умножается на 2). Т.е. 200 000

Для Quake 3
Интенсивность 100.
intensity = 100 * 7500;
Результат 750 000 едениц.
В 3.75 раз выше.

Добавлено 27-07-2020 в 12:38:

Слева халфа, Справа ку3

Добавлено 27-07-2020 в 12:55:

В халфе экспоненциальная функция получается. Потому что при яркости 200, халфа уже даст 1 600 000, а ку3 1 500 000 соответственно.
При значении 300, 5 400 000 и 2 250 000.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 27-07-2020 в 19:57:

Цитата:

Дядя Миша писал:
С одной стороны, это свет, который идеально вписывается в заданный радиус, т.е. фактор освещённости превращается в мировые юниты. С другой стороны - корректно ли это?

О, я так делал в старой версии After Engine, когда приделывал 2D нормал-мэппинг. А то в 2D очень уж неудобно когда радиус лайта нечеткий

__________________
-Brain is dead-

Отправлено Дядя Миша 29-07-2020 в 09:56:

Наконец-то удалось как следует протестировать альтернативный упаковщик "уголком", за который так топил наш друг.
В обычных условиях оценить эффективность затруднительно, это надо считать неиспользованные пиксели, причём на одном и том же наборе данных, а тут никогда не угадаешь. Но вчера у меня появилось одно очень простое соображение. Вот у нас есть глобальный список лайтмап-кусочков, которые должны быть упакованы в атласы. Как мы обычно делаем в таком случае? Мы их пакуем-пакуем-пакуем, а если AllocBlock вернул false, то атлас считается заполненным, но ведь это в корне неверно! Это всего лишь означает, что в атласе уже нет места для этого конкретного куска. Он слишком большой. Но вероятно есть места для меньших кусков? Алгоритм реализуется очень просто - мы каждый раз пытаемся добавить в очередную страницу атласа все имеющиеся у нас кусочки лайтмап (разумеется помечая уже добавленные). Если AllocBlock нас послал - мы просто пропускаем этот кусочек и пытаемся добавить еще какой-нибудь. И так, пока не пробежим весь список. Разумеется он отсортирован от большого к малому.
И вот на таких вводных, я наконец-то получил чистые условия. Уголок действительно пакует эффективнее, т.к. он вообще не оставляет дыр при таком подходе. На той же q3dm1 я получил 5 идеально заполненных лайтмап без единого свободного пикселя. И шестую - заполненную процентов на 30. С Кармаковским алгоритмом я получил шесть неидеально заполненных лайтмап и седьмую, слегка начатую.
Но тут еще конечно вопрос, почему сам алгоритм оставляет довольно большие дыры в некоторых местах. Скорее всего особенность работы by design. Потому что, как я понял, для упаковщиков 70% успеха - это грамотная сортировка и подача. То есть всё свелось к тому, может ли алгоритм теоретически обеспечить 100% заполнение или нет. Да не случайным образом, а выдавая стабильные результаты. Ну вот пять полностью заполненных страниц вполне меня убедили в этом.
Полагаю это и есть самый валидный тест упаковщиков.

ЗЫ. картинки прикладываю, правда на данный момент их поровну, но дырки в заполненных атласах на кармаковском алгоритме видны невооруженным глазом, причём уже нельзя сказать "ну он их так расположил".

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 29-07-2020 в 18:38:

Дядя Миша
А вот ту формул(ы) освещения, она вкомпилена будет, или её можно будет задать/выбрать в конфиге?

__________________
http://www.moddb.com/mods/monorail-quest

Временная зона GMT. Текущее время 18:48.

На основе vBulletin версии 2.3.0
Авторское право © Jelsoft Enterprises Limited 2000 - 2002.
Дизайн и программирование: Crystice Softworks © 2005 - 2024