Показать все 3825 сообщений этой темы на одной странице
|
Страницы (255): « Первая ... « 90 91 92 93 [94] 95 96 97 98 » ... Последняя » Показать все 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)
thambs думаю через него пропускается луч из взгляда игрока, соответственно как ты собираешься просматривать в обе стороны?
__________________
-Brain is dead-
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Crystallize
Нормаль это не ориентация.
Здоров ли ты сегодня?__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отрицательный браш в кварке - это просто браш с приоритетом. Т.е. CSG всегда знает что вычитается из чего.
Я говорил что можно глубину модифицировать.__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Продолжим. Здесь пожалуй уместно сделать небольшое историческое отступление. Так любопытно получилось, что в первом дууме и в третьем - по одному компиляторы и принципы построения уровня в чём-то схожи. Там - секторы, тут арии. И там и там они могут быть какой угодно формы, неконвексные. Это же свойство активно используется для распространения звуковых волн в игре. Правда на этом сходство как бы и кончается.
В первом дууме секторы - это геометрия с одинаковой высотой пола и потолка. Любой алгоритм ведь строится на допущениях, как только они перестают отвечать нашим требованиям - всё рушится. Естествено что в квейке мы уже не могли разделять пространство на секторы с разной высотой пола, можете себе представить сколько было бы секторов в таком случае. В принципе надо признать, что PVS, он изначально делался именно под уровни первого квейка и именно в контексте этих зловещих колидоров он работал оптимально. Уже в ку2 с этим начались проблемы, в ку3 пришлось довольно многое поменять, а в д3 и вовсе отказаться от такого подхода. Итак, в д3 фактически произошёл возврат к секторам, но на качественно новом уровне. Сектор\ария это выделенный пользователем кусок уровня, который рисуется за один раз. Ничего страшного при этом не происходит - невидимые части отсекаются на видеокарте. С одной стороны такой подход может резко влиять на фпс при смене секторов (вспомним недавние жалобы на Волатилу, что открытие дверей резко роняет фпс), с другой стороны - это целиком и полностью контролируется пользователем, в отличие от тех же хинтбрашей, которые лишь подсказки доброй воли. Т.е. пользователь может поделить уровень на куски таким образом, чтобы каждый новый кусок попавший в видимость не слишком сильно ронял фпс. Опять таки на открытом пространстве не придётся ждать бесполезную работу по обсчёту видимости.
Как же устроены эти арии? В сущности они уже были во втором квейке, да. Но! Всё это время они использовались как надстройка над обычным PVS. Сам виз их игнорировал кстати. Это был просто еще один слой абстракции - такой толстый-претолстый пвс, который мог выключить разом из видимости целую область. По команде от закрытой двери. Но обычный PVS работал классическим образом - всё так же отсекая по одному-два полигончика где-нибудь там. То есть херово работал, если честно. Виз очень сильно завязан на разбиение деревом, а дерево строится не учитывая вообще никакой виз, его больше волнует конвексность пространства. Можно сортировать плоскости по аксиальности, делать эти разрубы каждые 1024 юнита, но факт остается фактом - добавление нового маленького брашика, может полностью перебалансировать вашу систему виз. Но из-за высокой дискретности разбиения пространства это в сущности мало кто замечал. Чтобы добится большей предиктабельности вот как раз и ввели эти хинты. Только они все равно не гарантируют ничего по сути. Фактически они работают как виз порталы с негарантированным результатом. Может станет лучше, а может и не станет. Вообщем на сегодняшний день это действительно несеръезно. Но повторюсь, PVS как концепция дико удобен, от него очень нехочется отказываться.
Чтоже было сделано в D3. Простая и в то же время гениальная вещь. Как я говорил, у нас было три слоя абстракции - сперва видимость считалась по лифам. Потом по кластерам и наконец по ариям. В ку1 были только лифы. В ку2 добавились кластеры для игнорирования детайл-брашей (но при этом детайл-брашы не были детальными - они не текли (т.е. из них можно было делать уровень), они разбивали другие браши) и арии для выключения дверей. В ку3 концепцию еще более углубили - теперь ареапорталы стали такими же брашами и появилась возможность их расставлять для блокирования видимости. Ну или хотя бы просто для группировки объектах в разных ариях. Но не было сделано самого главного - видимые сурфейсы никак не были привязаны к этим самым ариям. Связь была очень условная, особено в ку3 где полигоны могли одновременно принадлежать нескольким лифам, а лифы в свою очередь - разным ариям. То есть не было вот этой чёткости, когда мы могли рисовать одну арию и точно знать, что всё, что к ней относится - больше ни к чему не принадлежит. Что же для этого надо сделать? Ну очевидно покромсать геометрию по кромкам самой арии? А как это сделать, ария это больше виртуальное понятие - номер в ноде. Плюс у нас геометрия и так уже покромсана BSP-деревом.
И вот тут начинается самое любопытное. Во первых, дерево, где ноды принадлежат разным ариям позволяет очень точно раскромсать уровень на арии ПРОИЗВОЛЬНОЙ ФОРМЫ. Причём эта самая форма задается лишь расставленными порталами. Не надо, как в иных движках заключать её в браши-объемы, достаточно лишь ограничить порталами. К тому же FloodAreas отследит, было ли реальное разделение на несколько арий, ну если вы к примеру поставили ареапортал в чистом поле. Но важный момент - геометрия кромсается вся, не только брашы, но и патчи и тримодели. Впрочем это можно запретить (в том же D3 флаг discrete например для автоспрайтов или зеркал). После того как всё покромсано соответствующими нодами - начинается самое любопытное. Геометрия начинает склеиваться обратно в большие батчи по типу материала.
Таким образом, каждая ария у нас представляет некоторый аналог студиомодели с точки зрения отрисовки - удалены лишние треугольники, всё стрипифицировано и сгруппировано по материалам, а поскольку в одной арии возможно не так уж и много материалов, то и соответственно батчей тоже немного. Правда сам механизм определения видимости чуть тяжелее, чем классический кушный. Но это компенсируется лёгкостью отрисовки. Есть и еще один неочевидный плюс такого подхода. Теперь при помощи таких порталов очень легко задавать туманные области. Ограничиваем вход-выход, их может быть сколько угодно. Если это небольшое углубление - ставим портал, вот вам и вода с туманчегом. Ну или просто вода. Сам виз в его классическом представлении тоже остается, но строится он уже на учете пользовательских ареапорталов и арий. А поскольку их смешное кол-во (в тоже д3 в среднем штук 40-50), считается такой виз от силы 5-10 милисекунд. Становится возможным включить его прямо внутри BSP (а в д3 оно вообще при загрузки карты считалось каждый раз, но это глупость конечно).
Вообщем это весьма перспективный и не утративший своей актуальности подход. Он ведь позволяет эффективно рассчитать и течение света сквозь порталы в реалтайме. И решить эту проклятую проблему с солнцем, которую кстати не решили в сталкере и не факт что решили в метро. Вот возьмем сталкеровский НИИ Агпропром. Там есть такой спуск потземлю. В оригинале его сделали отдельным уровне. В LostAlpha сделали частью общей карты, но когда ты спускаешься вниз, то прямо видно как гаснет солнце. Очевидно они не смогли эффективно отделить верх от низа. С системой порталов это вообще не представляет никакой проблемы. На входе в подземелье ставим один портал, на выходе - другой. Между порталами - шахта с лестницей. Дальше солнце просто определяет видимость - оно может осветить условно арию 0 (аутдор), немного арию 1 (шахту с лестницей) ну и собственно всё - до подземелья лучи уже не добивают. К тому же мы можем эффективно оптимизировать и аутдоры тоже, причём в автоматическом режиме - здесь нам на помощь приходит то самое авторазбиение на квадраты в BSP. Лепим эти арии, каждые 1024 юнита. Ну и дальше ограничиваем видимость либо туманом либо классически по фрустуму.
(продолжение следует)
Добавлено 09-05-2020 в 15:34:
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Дядя Миша
Останецца две утилиты для коптиляции?
__________________
http://www.moddb.com/mods/monorail-quest
thambs типа того. Но насчёт лайтмаппера я пока не знаю, он вероятно будет необязательным. Сделать его надо просто для референса, чтобы сравнивать запечённое освещение с реалтаймом.
Добавлено 09-05-2020 в 18:48:
Вообще BSP компилятор будет очень эпичным. Вероятно ни в одном движке больше не будет такого тяжёлого препроцессинга геометрии как у меня.
CSG по брашам, CSG по сурфейсам, разрезание по дереву, разрезание по ариям, склеивание всего обратно с выкидыванием лишних ребёр, глобальный т-джунк. Но при всём при этом, вероятность выпадения полигонов будет минимальной или вовсе отсутствовать.
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Crystallize лайтбейкеру плевать на формат, он может хоть чёрту лайтмапу посчитать. Если конвертировать чёрта в obj.
Давайте всё же в порядке очерёдности. Сейчас надо получить максимальный прирост производительности даже без PVS. У меня прогресс шёл следующим образом:
1. Новый движок с халфовским форматом (3%..5%) просто из-за отсутствия всякого мусора совместимости и видоизменённому игровому циклу.
2. Построение оптимизирующего виз-три для халфовского формата (10%..%400) к производительности.
3. переход на кутришный формат (200%..%600) к производительности.
Теперь вот финальная стадия оптимизации. Ну посмотрим. Старые форматы никуда не делись, будет с чем сравнивать.
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Опробовал дуумтришные оптимизации-триаунгуляции. Ну что можно сказать?
Навскидку - очень неплохо. На том же сипульчере 180 тысяч полигонов собралось в 2500 сурфейсов. Фпс даже безо всякого виза - порядка 250.
И это при том, что там сейчас переходной период, я вообще себе смутно представляю что там рендерится, а что отсекается, я просто отправил эти батчи как MST_TRIANGLE. С другой стороны нельзя прямо сказать, что этот код показывает чудеса оптимизации. Ну что-то там удаляет конечно, факт.
Но всё равно имхо многовато треугольников остается. Зато здесь т-джунктион с хэшем - быстро работает. Сипульчер компилился 5-минут.
Вообще там код с явными ляпами, к примеру идёт прямое сравнение флоатов. Из-за чего постоянно лезут тучи варнингов. Заменил на эпсилоны - почти все ошибки исчезли. Странно это всё, как они с таким кодом вообще свой дуум собирали. Ну да ладно, смысл есть, а это главное.
Конечно там еще весьма много возни предстоит, как это всё запеределать и увязать с текущим форматом.
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
А нельзя делать прямое сравнение флоатов, если они получены явным образом? Ну то есть не в результате математических операций.
| Временная зона GMT. Текущее время 06:10. | Страницы (255): « Первая ... « 90 91 92 93 [94] 95 96 97 98 » ... Последняя » Показать все 3825 сообщений этой темы на одной странице |
На основе vBulletin версии 2.3.0
Авторское право © Jelsoft Enterprises Limited 2000 - 2002.
Дизайн и программирование: Crystice Softworks © 2005 - 2024