HLFX.Ru Forum
профиль •  правила •  регистрация •  календарь •  народ •  FAQ •  поиск •  новое •  сутки •  главная •  выход  
HLFX.Ru Forum HLFX.Ru Forum > Разработка игр > Наши проекты > XashNT: блог разработчика
Часть I
Страницы (240): « Первая ... « 127 128 129 130 [131] 132 133 134 135 » ... Последняя »   Предыдущая тема   Следующая тема
Автор
Тема Новая тема    Ответить
Crystallize
Житель форума

Дата регистрации: Jul 2007
Проживает: Новосибирск
Сообщений: 4415
Возраст: 34

Рейтинг



Цитата:
Дядя Миша писал:
ну чтож, финальный штрих - радиосити.
В данном случае надо просто наспавнить вторичных аналитических источников света от поинтлайтов. Ну можно и от лайтспотов тоже.
А потом эти лайты будут участвовать в общем процессе освещения.
Т.е. свет посчитается сразу как прямой, так и отражённый, не надо будет ничего там вымучивать в несколько проходов.

Напоминает тысячи солнц на небосводе в TyrUtils. Может это можно всё-таки как-то параметрически реализовать? Я просто боюсь что будут видны пятна от отдельных лайтов.

Сообщить модератору | | IP: Записан
Сообщение: 199464

Старое сообщение 27-12-2020 12:57
- За что?
 Дядя Миша
racing for fish

Дата регистрации: Oct 2005
Проживает: Кубань
Сообщений: 32188
Нанёс повреждений: 392 ед.

Рейтинг



Цитата:
Crystallize писал:
Напоминает тысячи солнц на небосводе в TyrUtils.

оно и в ку3 так.

__________________
My Projects: download page

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

Цитата:

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

Сообщить модератору | | IP: Записан
Сообщение: 199468

Старое сообщение 27-12-2020 15:53
-
 Дядя Миша
racing for fish

Дата регистрации: Oct 2005
Проживает: Кубань
Сообщений: 32188
Нанёс повреждений: 392 ед.

Рейтинг



Ну вот, сляпал на скорую руку некоторое подобие радиосити.
Пусть пока хоть такое будет.

__________________
My Projects: download page

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

Цитата:

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

Сообщить модератору | | IP: Записан
Сообщение: 199481

Старое сообщение 28-12-2020 12:56
-
 Дядя Миша
racing for fish

Дата регистрации: Oct 2005
Проживает: Кубань
Сообщений: 32188
Нанёс повреждений: 392 ед.

Рейтинг



Честно говоря, толку от этих лодов примерно никакого, увы. Максимум, на который они способны без видимой деградации, это примерно половина от оригинального поликаунта, но часть секторов вообще нет смысла упрощать, они и так довольно простые, хотя их и много. То есть складывается идиотская ситуация, допустим взгляд с крайней точки карты, в кадре 4.5 миллиона треугольников. Включаем лоды, поликаунт падает до 3.6 миллионов. Ну и что? Фпс подымается максимум на 1-2. Он же экспоненциально падает. Импосторы могли бы поправить дело, но пока не хочется с ними связываться.

Добавлено 29-12-2020 в 10:53:

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

__________________
My Projects: download page

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

Цитата:

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

Сообщить модератору | | IP: Записан
Сообщение: 199482

Старое сообщение 29-12-2020 07:53
-
Ku2zoff
Мастер Ёда из Деревни Дуракоф

Дата регистрации: Apr 2007
Проживает: В Деревне дураков
Сообщений: 6749
Возраст: 33

Рейтинг



Цитата:
Дядя Миша писал:
Фпс подымается максимум на 1-2.

Кстати, спрошу, раз уж тема лодов затронута. Насколько мне известно, относительно современные видеокарты (не старше 10 лет) отлично справляются с большим количеством полигонов в кадре. Упор идёт в возможность загрузки в память жЫрных текстур неоправданно высокого разрешения. Ну и всякие вычисления для красивостей. Насколько это справедливо в случаях для каких-то конкретных движков? И почему, например, относительно гладкий и лысый Control имеет системные требования выше, чем высокополигональный и рельефный UT3 и его производные?

Сообщить модератору | | IP: Записан
Сообщение: 199486

Старое сообщение 29-12-2020 10:00
- За что?
 Дядя Миша
racing for fish

Дата регистрации: Oct 2005
Проживает: Кубань
Сообщений: 32188
Нанёс повреждений: 392 ед.

Рейтинг



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

Если бы прогрессивные лоды снижали поликаунт прогрессивно, от них бы действительно был толк. Но чудес не бывает. Нельзя из модели в 10000 полигонов сделать модель в 300 полигонов, чтобы она при этом не превратилась в полное дерьмо. То есть можно, конечно, но ручками.
А это значит, что под эти модели будет идти свой набор вертексов, значит под лоды придётся заново перерасчитывать лайтмапу, плюс даже при таком подходе, вовсе не факт, что они прямо здорово выровняют фпс. Наилучший подход, мне представляется, это хитрый программный растеризатор для окклюжена, но эта штука сама по себе может быть довольно тормозной на самом-то деле. Тут конечно двояко. Отрендерить один канал глубины в текстуру 320х200 - это мегабыстро. Рендерить можно прямо через рейтрейсинг, чтобы не заморачиваться матрицами проекции. Проблема в том, что перекрытие будет посчитано при таком подходе очень и очень приблизительно. И будут нужны еще доп. условия, чтобы не отсечь лишнего. А это значит, что часть работы была проделана впустую. И вот где-то есть оптимальная точка балансировки, когда от всего этого механизма есть польза, причём не факт, что это константа.

Добавлено 29-12-2020 в 15:04:

Давайте напишу немного про очевидные трудности, связанные с внедрением лайтстилей и о том, почему их (трудностей) не было в старых кваках.

Итак. Лайтмапу можно хранить двумя способами:
1. одномерный массив точек, и отсылки к каждому геометрическому примитиву, обычно простой поверхности.
2. предрассчитанный 2D атлас, отсылка через UV-координаты.

Первый способ позволяет строить лайтмапу какой угодно размерности, контролируя сколько лайтстилей получит каждый сурфейс (от четырёх, до нуля), второй, очевидно этого не позволяет. Как минимум потому, что построение атласа вообще не учитывает сколько там будет лампочек и какой вклад они внесут в освещение. Частично этому мешает тот факт, что атлас строится задолго до рассчёта освещения, но главным образом - что в атласе освещение считается не для отдельно взятого полигона, а для целой их группы. Причём объединение в сурфейсов в группу для наложения на нее единого куска лайтмапы имеет вполне конкретный смысл - отсутствие швов. Есть и второе соображение - сейчас вся геометрия в треугольниках. Если для каждого треугольника выделять свой кусок лайтмапы, получим двойной перерасход люкселей. Впрочем, если кто-то полагает, что этот способ всё же имеет право на жизнь - во второй параное именно этот подход и реализован. Каждый треугольничек освещается отдельно, занимает отдельный кусочек лайтмапы и освещение радует дикой грязью, где уже невозможно отличить шов от ошибки взятия нормали по фонгу. Корректных способов это разрулить попросту не существует. Только объединять в группу. В кваке, где всё было параллельно и попендикулярно, а сурфейсы квадратными, это не имело никакого значения, вообщем-то И то, как вы помните китаец приложил немало усилий, чтобы сгладить эти чёртовы швы между смежными поверхностями. Но если вы думаете, что его алгоритм - панацея, то спешу вас разочаровать. Я конвертил некоторые модели в брашы и пытался их компилить в p2st. Террайны, колонны (не витые, просто круглые). Результат был еще хуже, чем работал просто мой лайтмаппер по треугольникам. Там вообще дикий ужос. Китайский сглаживатель хорошо себя чувствует только с аксиальными рёбрами, судя по всему. Но даже если каким-то чудом допустить, что мы эти лайтмапы просчитали для каждой квад-пары (которой может вообще не быть в большинстве случаев) и получили такие симпатичные одномерные лайтмапы, прилинкованные к сейфейсам, это всего лишь означает, что эти сурфейсов получилось несколько сотен тысяч на более-менее приличной карте. Если рисовать их так - фпс умрёт, просто по факту перебора поверхностей, даже не отрисовки. Если их мержить при загрузке налету, неизвестно сколько это займет времени. Причём, как вы понимаете, чем больше карта, тем больше времени. Сделать это после рассчёта света тоже нельзя - тогда свет второй раз уже не посчитаешь.
Но даже, повторюсь, если на всё это наплевать и всё таки сделать именно так, то есть пример второй паранои перед глазами. Там есть лайтмапы на моделях и там есть лайтстили. Качество освещения вы видели. А если нет, то всегда можете заценить. Сорцы открыты, можете брать и пытаться это дело улучшить. Навряд ли это вообще возможно. К тому же, повторюсь, при таком подходе почти всегда дикий перерасход лайтмапы получается.
Я бы мог и другие причины назвать, но и этих достаточно. Особо подчеркну, что по отдельности они не кажутся какими-то фатальными, но когда всё это собирается вместе и сталкивается с практикой, начинается тихий ужос. Но конечно, если у кого-то есть достаточно свободного времени, он вполне может доказать, что и это подход имеет право на жизнь. Второй вариант - атласы предрассчитаны заранее. Мы не можем выделять здесь какие-то группы. Но зато мы можем выделять слои-каналы.
Ведь у нас в текстуре целых четыре канала RGBA. Можно отвести каждый канал под монохромный цвет. Таким образом убивается сразу джва зайца.
И лайтстили как бы сохранены и в то же время размер лайтмапы не вырос.
Но с цветным освещением придётся уже попрощаться. Нечто подобное используется в UE4 насколько я знаю. Но что делать, если цветное освещение хочется? Можно попробовать использовать технику, которую Humus назвал Modern Lightmapping. Когда в каналы сохраняется только тень, а свет считается динамически. Частично этот подход использовался и в сталкере, для смены времени суток, например. Минус в том, что всё равно придется заводить лайтмапу под индирект-освещение, если оно у нас есть. Правда и тут есть варианты - использовать индирект только для солнца, а обычным лайтам его не давать. В конце-концов в ку3 индиректа не было и ничего, не фатально. Причём по большому счёту его не было даже в q3map2 - по дефолту он выключен. Вы можете попробовать его включить, но тогда рассчёт света из 2 минут превратиться в пару часов или около того. Поэтому его всё равно никто не юзал.
Варианты с сохранением различной информации в лайтмапу, я естественно опробую, плюс тут еще и в том, что на одной и той же странице, но в разных участках могут быть сохранены совершенно разные лайтстили. Наконец можно цвет лампочки передавать в шейдер, а в канале держать только карту интенсивности. Такой подход тоже вполне себе имеет право на жизнь.

__________________
My Projects: download page

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

Цитата:

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

Сообщить модератору | | IP: Записан
Сообщение: 199488

Старое сообщение 29-12-2020 12:04
-
 Дядя Миша
racing for fish

Дата регистрации: Oct 2005
Проживает: Кубань
Сообщений: 32188
Нанёс повреждений: 392 ед.

Рейтинг



Сделал лайтмаппер прогрессивным. Как только страница посчитана, она тут же сохраняется на диск. Т.е. даже если лайтмаппер вылетел с нехваткой памяти, то всё равно часть света посчиталась и будет доступна.
Теоретически можно будет еще замутить досчёт, если допустим страницы по дате новее чем карта, ну то потом как-нибудь.

Добавлено 29-12-2020 в 21:20:

И еще раз оптимизировал потребление памяти. Лес из Лост Альфы не тянет даже на ТЭЛез16, там всего-навсего 22 тысячи деревьев. Но в целом довольно солидно смотрится. Я там даже заблудился однажды.
Но даже для освещения всех этих ёлок-метёлок надо около 2 гигабайт памяти. Можно попробовать сделать GPU-лайтмаппер, благо его архитектура идеально для этого подходит, но пока не знаю.
В будущем году можно будет попробовать.

Добавлено 29-12-2020 в 21:25:

Я себе к слову довольно смутно представляю, как работает GPU-солвер.
Тому шо, если у нас к примеру индирект от солнца - ну скажем 200 источников, это чтож, надо 200 шадов-мап нагенерить? А потом разом их применить? Нет, ну можно конечно итеративно, я видел, они в основном именно так и работают, но этот комбинаторный взрыв ИМХО сводит на нет все преимущества от использования GPU.

ncuxonaT напомни как ты действуешь. И сколько видеопамяти это потребляет.

Добавлено 29-12-2020 в 21:27:

Продолжая рассуждать - я бы мог к примеру KD-Tree засунуть в текстуру и тогда бы на GPU вместо шадовмап так бы всё считал в сингл-проходе, красотищща, но беда в том, что на больших картах Kd-tree само по себе строится до 15 минут.

Добавлено 29-12-2020 в 23:18:



Внимание на поликаунт. Вот это лоды в идеальном случае. Было 8 миллионов, стало пять. ну и что? Фпс не поменялся. Для GTX650 одинаково тяжело.

Добавлено 29-12-2020 в 23:19:

А экспоненциально снижать поликаунт не в состоянии ни одна лод-система.

__________________
My Projects: download page

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

Цитата:

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

Сообщить модератору | | IP: Записан
Сообщение: 199497

Старое сообщение 29-12-2020 20:19
-
ncuxonaT
каков стол, таков и стул

Группа: Опытный
Дата регистрации: Oct 2009
Проживает: город/село/деревня
Сообщений: 1626
Возраст: 33

Рейтинг



Дядя Миша под индиректом от солнца подразумевается свет от неба? Ну да, много шадовмап. Так старый лайтбейкер работал, только от неба шадовмап было не 200, а 1000 по умолчанию. А для какого-нибудь арканоса, где через маленькие окошки освещается большая карта, шадовмап нужно было не меньше 10000. И да, рендерилось оно итеративно с накоплением.
Но шадовмапы дают лики и акне, поэтому новый лайтбейкер перешел на рейтресинг. Он медленнее, но надежнее.

Сколько оно занимает места, давай посчитаем.
На каждый треугольник 3 вершины, вершины лежат в двух RGBA32F текстурах в виде (pos.x, pos.y, pos.z, uv.x) (norm.x, norm.y, norm.z, uv.y). Итого 32 байта на вершину и 96 байтов на треугольник.
В дереве 2N - 1 узлов, каждый узел это ббокс (RGB32F x2) и ссылки на двух детей (RGBA16 x6). X6, потому что сейчас я использую метод Хачисуки (https://cs.uwaterloo.ca/~thachisu/) с 6 деревьями. Значит, на узел 72 байта.

В сумме на треугольник 240 байт.

Если стоит задача экономии памяти, то можно выкинуть 5 деревьев, использовать индексы, а нормали хранить в RGB16. И, если допустить, что количество вершин в среднем равно количеству треугольников, то выйдет порядка 70 байтов не треугольник.

Добавлено 30-12-2020 в 07:09:

Ты деревья по-одному рисуешь? Инстансинг нельзя использовать?

Сообщить модератору | | IP: Записан
Сообщение: 199505

Старое сообщение 30-12-2020 04:09
- За что?
 Дядя Миша
racing for fish

Дата регистрации: Oct 2005
Проживает: Кубань
Сообщений: 32188
Нанёс повреждений: 392 ед.

Рейтинг



Цитата:
ncuxonaT писал:
только от неба шадовмап было не 200, а 1000 по умолчанию

погоди-погоди-погоди, 1000 шадовмап и каждая 4096х4096?
Так никакой видеопамяти нехватит. Тысяча это много, ста штук достаточно.

Цитата:
ncuxonaT писал:
В сумме на треугольник 240 байт.

У меня сейчас face_t занимает 96 байт. На этой карте с лесом общая память под уникальные фейсы - 800 мегабайт. А у тебя значит займёт больше двух гигабайт видеопамяти. Здесь звучит музыка из ералаша. Пара-пара-пам.

Цитата:
ncuxonaT писал:
Ты деревья по-одному рисуешь? Инстансинг нельзя использовать?

деревья и так в инстансе. Т.е. моделька дерева одна, а рисуется с разными матрицами скейла и ориентации. В OpenGL нет настоящего инстансинга, только фейки. Ну то есть если я средствами драйвера сделаю то, что они называют инстансингом, это всё равно будет на CPU, только на стороне драйвера.

Добавлено 30-12-2020 в 10:28:

Строго говоря, если уж GPU-лайтмаппер перешёл на использование рейтрейсинга, какой тогда смысл пытаться имитировать растеризацию?
Надо делать на CUDA, разве нет?

__________________
My Projects: download page

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

Цитата:

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

Сообщить модератору | | IP: Записан
Сообщение: 199507

Старое сообщение 30-12-2020 07:28
-
ncuxonaT
каков стол, таков и стул

Группа: Опытный
Дата регистрации: Oct 2009
Проживает: город/село/деревня
Сообщений: 1626
Возраст: 33

Рейтинг



Цитата:
Дядя Миша писал:

погоди-погоди-погоди, 1000 шадовмап и каждая 4096х4096?
Так никакой видеопамяти нехватит. Тысяча это много, ста штук достаточно.

Говорю же, рендерится итеративно, то есть по одной шадовмапе за раз. Отрендерил шадовмапу, посчитал с ней освещение, отрендерил другую, посчитал с ней освещение, добавил к предыдущему и так далее. Ста штук недостаточно, будет видно 100 теней от какого-нибудь столба или дерева.
Цитата:
Дядя Миша писал:
У меня сейчас face_t занимает 96 байт. На этой карте с лесом общая память под уникальные фейсы - 800 мегабайт. А у тебя значит займёт больше двух гигабайт видеопамяти. Здесь звучит музыка из ералаша. Пара-пара-пам.

96 байт на фейс, а дерево сколько еще будет занимать? Я могу ужаться до 70 байтов на треугольник с учетом дерева. Ну это в лучшем случае, конечно.
Цитата:
Дядя Миша писал:
В OpenGL нет настоящего инстансинга, только фейки.

https://learnopengl.com/Advanced-OpenGL/Instancing вот это не настоящий инстансинг? Они там 100к астероидов рисуют.
Цитата:
Дядя Миша писал:

Строго говоря, если уж GPU-лайтмаппер перешёл на использование рейтрейсинга, какой тогда смысл пытаться имитировать растеризацию?
Надо делать на CUDA, разве нет?

КУДА это вендор лок, а у нас тут кроссплатформа. Да и по тесту Хачисуки рейтрейсер на GLSL сопоставим по производительности с вариантом на КУДЕ.
Почему имитация растеризации? Лучи не летят параллельно на манер шадовмапы, от каждого текселя лучи летят рандомно.

Сообщить модератору | | IP: Записан
Сообщение: 199516

Старое сообщение 30-12-2020 14:45
- За что?
 Дядя Миша
racing for fish

Дата регистрации: Oct 2005
Проживает: Кубань
Сообщений: 32188
Нанёс повреждений: 392 ед.

Рейтинг



Цитата:
ncuxonaT писал:
а дерево сколько еще будет занимать?

дерево у меня максимум было 150 мегабайт.

Цитата:
ncuxonaT писал:
Они там 100к астероидов рисуют.

ну ты покликай режимы, там довольно занятно.

Цитата:
ncuxonaT писал:
Почему имитация растеризации?

я говорю, раз уже всё равно рейтрейсер используем.

Цитата:
ncuxonaT писал:
будет видно 100 теней от какого-нибудь столба или дерева.

А ты с какой яркостью рендеришь?

Добавлено 30-12-2020 в 22:46:

Гм. продолжение обсчёта лайтмап пришлось прикрутить экстренно, после того как лайтмаппер внезапно вылетел с нехваткой памяти. Я конечно не знаю, почему он вылетел, но вариантов там немного. Один, если быть точным. Благо прогрессивный механизм сохранения лайтмап - это уже половина дела. Добавил пару условий и всё заработало.
Надо еще будет анализатор сделать, чтобы понять чего хочет юзер - полный новый обсчёт или досчёт.

__________________
My Projects: download page

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

Цитата:

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

Сообщить модератору | | IP: Записан
Сообщение: 199522

Старое сообщение 30-12-2020 19:46
-
ncuxonaT
каков стол, таков и стул

Группа: Опытный
Дата регистрации: Oct 2009
Проживает: город/село/деревня
Сообщений: 1626
Возраст: 33

Рейтинг



Цитата:
Дядя Миша писал:
ну ты покликай режимы, там довольно занятно.

А как какать кликать? Не вижу там готового демо. Ты из исходников собирал?

Что ты подразумеваешь под имитацией растеризации?

Цитата:
Дядя Миша писал:
А ты с какой яркостью рендеришь?

Пусть будет с яркостью 1. Я не понимаю, при чем здесь яркость. Давай посмотрим, сколько нужно шагов/шадовмап, чтобы свет на арканосе сошелся до чего-то более-менее приемлемого:
https://i.imgur.com/cbRKAkD.jpghttps://i.imgur.com/NDWMpcY.jpghttps://i.imgur.com/PS6V2qK.jpghttps://i.imgur.com/tMq7wGp.jpghttps://i.imgur.com/D50GR5j.jpghttps://i.imgur.com/9bhl3Im.jpghttps://i.imgur.com/s6i1bPn.jpg

Сообщить модератору | | IP: Записан
Сообщение: 199524

Старое сообщение 30-12-2020 21:03
- За что?
 Дядя Миша
racing for fish

Дата регистрации: Oct 2005
Проживает: Кубань
Сообщений: 32188
Нанёс повреждений: 392 ед.

Рейтинг



Цитата:
ncuxonaT писал:
А как какать кликать? Не вижу там готового демо. Ты из исходников собирал?

Странно. Я видел какую-то готовую демку инстансинга с астероидами.

Цитата:
ncuxonaT писал:
Что ты подразумеваешь под имитацией растеризации?

ну то что видеокарта работает в режиме рендеринга.

Цитата:
ncuxonaT писал:
Я не понимаю, при чем здесь яркость.

Один главный источник направления + лайты по полусфере. Ну это для солнца.

Добавлено 31-12-2020 в 13:20:

Сделал разбиение лайтмапы для больших поверхностей типа террейна на куски, при условии, что какой-то кусок превышает максимальный размер страницы (1024 х 1024 пикселя). В сталкере, напомню, макс размер атласа для террейна 2048х2048. Для той же ЧЭАС это адски мало, там тени размытые их толком не видно. Впрочем такое разбиение провоцирует швы, но поскольку раньше это была одна целая лайтгруппа, то они малозаметны на самом деле. Причина появления этих швов тривиальна - люксели сдвигаются относительно друг друга при конвертации в локальное пространство страницы лайтмапы. Но победить это не так-то просто.
Кстати, вот в самом сталкере координаты лайтмапы хранятся в fixed point.
Я вот и думаю, может быть это как поможет отцентровать люксели.

__________________
My Projects: download page

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

Цитата:

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

Сообщить модератору | | IP: Записан
Сообщение: 199526

Старое сообщение 31-12-2020 10:20
-
 Дядя Миша
racing for fish

Дата регистрации: Oct 2005
Проживает: Кубань
Сообщений: 32188
Нанёс повреждений: 392 ед.

Рейтинг



Добил полное сохранение стейта лайтмаппера и сделал его умным.
Теперь он сам определяет, что от него хотят - продолжить освещение с текущей страницы или заново всё переосветить. KD-три тоже сохранил, очень уж долго оно рассчитывается на некоторых картах.
Но вообще я вот что заметил - то что считает мой лайтмаппер обычно не считает никто. Я уже молчу про то, что на той же лост-альфе большинство объектов отправлено на повертексное освещение. Но там и скейл подкручен. И естественно MU-модели имеют только повертексное. В результате, там где у меня 150 страниц 1024х1024, в лостальфе - всего-навсего шесть. Конечно это не значит, что надо непременно идти таким долгим путём. Но в рамках тестирования предельной нагрузки на компиляторы - это вполне себе ок. Уж если он такое выдерживает, то и ваши эксперименты тоже выдержит. А я не думаю, что у кого-то хватит терпения делать такие гигантские карты, как в лост-альфе.
Еще бы метрошные карты проверить, но я чёт так и не нашёл конвертора.

__________________
My Projects: download page

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

Цитата:

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

Сообщить модератору | | IP: Записан
Сообщение: 199557

Старое сообщение 02-01-2021 11:59
-
 Дядя Миша
racing for fish

Дата регистрации: Oct 2005
Проживает: Кубань
Сообщений: 32188
Нанёс повреждений: 392 ед.

Рейтинг



Ну штож, пора бы уже сделать колоизацию для триангловых моделей.
Без колоизации можно только летать ноклипом или бродить по скайбоксу.
Какие варианты тут есть?

Ну например, можно подключить физикс. Правда его в некоторых местах неудобно сопрягать с игровым кодом. Аналогично с Ньютоном.
С физ.движками вообще расклад такой - придётся выбросить оригинальную трассу. С одной стороны - не могу сказать, чтобы я был особенно против, но меня пугает один момент, с которым обычно сталкиваешься, пытаясь использовать сторонние библиотеки - на определённом наборе данных это начинает или дико тормозить или глючить или вообще вылетает. Вы вероятно не в курсе, но в ксаш-моде есть парочка хаков на этот счёт. Я уже не помню, то ли новодекс, то ли уже физикс вылетали при попытке запечь геометрию одной из халфовских карт. А сорцев на тот момент и не было.
Но вылет-то ладно, если есть сорцы, поправимо. А если тупить начнёт?

Сперва, как и говорил уже когда-то, попробую нагенерить брашей из каждого полигончика, предварительно их симплифицировав. Метод тупой, не особо оптимальный, но можно будет построить им дополнительное дерево. У такого подхода есть один плюс - пересечение AABB, с таким вот брашем из треугольника, считать в десятки раз быстрее, нежели честную коллизию Tri vs AABB. Но за это придётся заплатить увеличенным кол-вом данных. Там у нас, строго говоря, пусть даже неиндексированный треугольник - это три вертекса, 36 байт.
Если из него генерить браш - это минимум шесть сторон, если нам повизёт и он окажется лежать на одной из аксиальных осей. Шесть сторон - это шесть плоскостей. Одна плоскость - 16 байт. 96 минимально. Но. Нам еще нужны бевелы. Без них толку не будет. А вот бевелов может быть довольно-таки много. До 30 штук, в среднем - те же шесть. Правда есть один лайфхак. Если треугольник неаксиальный, нам вовсе необязательно непременно добивать его полноценного браша - достаточно одних бевелов. Так что в теории их может быть не шесть, а меньше. К тому же, учитывая, что мы имеем дело именно с брашами, нам вовсе необязательно превращать в них треугольники. Можно сперва бъеднить все треугольники в конвексные фигуры, по максимуму. Сколько бы их там ни было - это всё равно будет одна плоскость. Так что в некоторых случаях выигрыш просто очевиден. Для ландшафта, например. Другой конечно вопрос - насколько всё это будет оптимально. Ну вот и проверим.

__________________
My Projects: download page

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

Цитата:

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

Сообщить модератору | | IP: Записан
Сообщение: 199804

Старое сообщение 13-01-2021 09:45
-
Тема: (Опционально)
Ваш ответ:



Переводчик транслита


[проверить длину сообщения]
Опции: Автоматическое формирование ссылок: автоматически добавлять [url] и [/url] вокруг интернет адресов.
Уведомление по E-Mail: отправить вам уведомление, если кто-то ответил в тему (только для зарегистрированных пользователей).
Отключить смайлики в сообщении: не преобразовывать текстовые смайлики в картинки.
Показать подпись: добавить вашу подпись в конец сообщения (только зарегистрированные пользователи могут иметь подписи).

Временная зона GMT. Текущее время 11:56. Новая тема    Ответить
Страницы (240): « Первая ... « 127 128 129 130 [131] 132 133 134 135 » ... Последняя »   Предыдущая тема   Следующая тема
HLFX.Ru Forum HLFX.Ru Forum > Разработка игр > Наши проекты > XashNT: блог разработчика
Часть I
Версия для печати | Отправить тему по E-Mail | Подписаться на эту тему

Быстрый переход:
Оцените эту тему:

Правила Форума:
Вы not можете создавать новые темы
Вы not можете отвечать в темы
Вы not можете прикреплять вложения
Вы not можете редактировать ваши сообщения
HTML Код ВЫКЛ
vB Код ВКЛ
Смайлики ВКЛ
[IMG] Код ВКЛ
 

< Обратная связь - HLFX.ru >

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