Итак, для начала небольшое лирическое отступление.
А именно - в этой серии я буду потихоньку писать обо всём, что знаю из
области игростроя. В этой части напишу про порталы, а что будет в
следующей и когда она появится - пока неизвестно даже мне. Если вы
обнаружите ошибки и неточности - система комментариев всегда к вашим
услугам. Возможно, писать буду слегка непоследовательно - но думаю, что
это простительно. В основном в этих статьях будет информация, не
касающаяся изготовления карт и модификаций непосредственно, но
находящаяся "на грани".
Техно #1: Portals
Итак, начнём. Если вы рисовали карту для более-менее современной игры,
причём большую карту, то будущие её потребители вас наверняка просили
её максимально оптимизировать. Собственно, механизм порталов как раз и
служит этой благой цели наравне со многими другими. Но о других не в
этот раз - всё же остановимся на порталах. Что такое портал в переводе
на русский (перевод получился довольно вольным) - это просто дверной
проём. А значит вся эта история как-то будет связана с дверями. Ну да
ладно, ближек делу.
Пора вспомнить о том, какую вообще цель приследуют эти самые порталы. А
цель проста - ускорить вывод картинки, собственно карты, на экран.
Желательно до сверхзвуковой. Но собственно за счёт чего возможен хоть
какой-то прирост производительности. Ведь процессор (в том числе и
видеокарты) работает на фиксированной тактовой частоте. И всё же карта
из четырёх стен рисуется быстрее ультрасложного завода по изготовлению
зомби. Очевидно, вся разница в количестве объектов. Ну а теперь корень
зла: любой объект рисуется значительно быстрее если его вообще не
рисовать на экране. И даже не делать никаких попыток отправить его на
экран. А лучше даже не загружать его в память - тогда ещё и память
сэкономим... А ещё лучше вообще не включать игру... ну это я уже
перестарался.
Итак, внимание - вывод из всего вышенаписаного: всё, что можно не
рисовать, очень желательно как раз таки не рисовать. С другой стороны,
совсем не рисовать движок игры не может - чёрный экран никого не
обрадует. И даже больше - движок не может не рисовать объекты,
находящиеся в поле зрения камеры. Иначе его признают глюкотроном
года... Но рисовать невидимые объекты в принципе не возбраняется (но
если ваша игра будет рисовать ВСЁ - её будут помнить долго...) Вот тут
и находится краеугольный камень всей 3d графики - как наиболее быстрым
способом отделять мух от котлет, то есть видимые объекты от невидимых.
А теперь - как это всё касается порталов. Во первых существует особый
класс так называемых "портальных" движков. К слову сказать, Серьёзный
Сэм относится именно к ним. И ведь он очень даже неплохо обрабатывает
как пространства, так и помещения. Ну а теперь тайна его могущества -
большую часть работы по расчёту видимости объектов делает ни кто иной,
как... ...дизайнер уровня. Надеюсь, культурного шока ни у кого не
случилось. Итак, как же он это делает. Просто вся хитрость в том, что
уровни сэма рисуются блоками. И у каждого блока набор своей геометрии.
Получается, что L-образный коридор в сэме состоит из двух секций: | и _
(это если его оптимизировали). Каждая секция рисуется отдельно (не
паникуем, в редакторе всё сведено в общем чертеже), причём у каждой
секции есть "хвосты", взятые из соседних секторов. Рисуется только та
секция, в которой непосредственно находится игрок. А хвосты нужны для
того, чтобы при переходе между секциями карты всё происходило гладко.
Кстати, это даёт разработчикам забавную возможность вытворять всякие
чудеса с пространством (в духе Воланда) на своих картах. В самом
серьёзном сэме это можно наблюдать на многих картах, если
приглядываться.
Ну ладно, с сэмом покончили, но это не единственный вариант. В
частности некий Крамарк придумал (возможно и не он, но приписано именно
ему) алгоритм BSP-tree. О его сути в другой раз, история длинная. Но
этот алгоритм даёт возможность:
а) Описать всю карту набором выпуклых объёмов.
б) Почти "бесплатное" в плане загрузки процессора обнаружение столкновений с картой.
в) Возможность рисовать все объекты от наиболее удалённых к наиболее
близким и наоборот. Причём без z-буффера и прочих наворотов. Всё
происходит само почти магическим образом.
г) Возможность играть в большинство хороших и не очень FPS (First
Person Shooter). Вероятно, начиная с Doom2. И гарантировано - с Q1.
Кстати, Duke3d к этим играм не относится - там движок ближе к
сэмовскому. Именно по этой причине там были возможны выверты типа
"сектор над сектором" и можно было двигать сектора.
Итак, приглядимся к этому творчеству ID'а повнимательнее. В принципе
BSP - алгоритм довольно удачный. Но у него, как и у всего прочего, есть
свои минусы. Пункт первый - примерно 95% геометрии карты жёстко
зафиксировано и не может быть изменено вообще никаким образом. Ну
только если текстуру поменять можно... да и такой радости не сделали. В
результате всё, что движется, взрывается и ломается, перешло в
отдельный класс, на который не распространяются минусы BSP. Равно как и
плюсы. В результате полигональная модель столкновений с уровнем была
ещё в Q1, а такую же для монстров приделали только в третьем думе. И то
не бескровно. Но уже пора бы переходить от лирики обратно к физике, то
есть порталам. А порталы тут при том, что их очень удобно совмещать с
пунктом а) плюсов BSP.
Представим, что после компиляции вашу карту описывает уже не набор
брашей, а набор выпуклых объёмов - этакие антибрашы с текстурой на
внутренней стороне. Для тех, кто рисовал в радианте или Qoole будет
понятнее, если сказать так: рисуем карту наизнанку - так, чтобы комнаты
были брашами, а пустые места располагались там, где раньше были стены.
Выбираем этот наборчик кубиков, помещаем в здоровенную
кубищу(бесконечную во все стороны) и делаем CSG subtract. И получаем,
собственно, карту в её нормальном виде. В общем в виде таких изнаночных
брашей ваша карта и дремлет в bsp файлах. Собственно, начиная с первого
квэйка, уже появилась автоматическая портальная система. Как она
работала: поскольку геометрия уровня от нас не убежит, при компиляции
для каждого антибраша (кластера в терминологии разработчиков этой
гравицапы) вычислялась карта видимости, то есть список - какие из
кластеров видно из этого, а какие - нет. Так же благодаря этой системе
с карты своевременно удаляются все принципиально невидимые стены (Те,
что снаружи, например. Или те поверхности, которые попали внутрь стены)
Всё это уже само по себе даёт серьёзный прирост скорости. И именно по
этой причине карта с утечками (leaks) работает гораздо тормознее, чем
карта без оных. Во втором квэйке появился дополнительный инструмент
hintbrush и собственно герой дня - портал, но с очень урезаным
функционалом.
hintbrush позволял уточнять границы ваших комнат. До его появления они
строились по принципу "главное, чтобы включалось". И именно по этой
причине в первом квэйке возникали проблемы вокруг достаточно мелких
деталей. В основном это выражалось в непропорциональном увеличении
времени на компиляцию карты (карта с мелкими детальками могла
компилироваться несколько часов на P4 900). Плюс неудачное расположение
кластеров потом вызывало лаги в игре. Хинтбраш позволял создавать свои
кластеры - он просто разрезал тот кластер, в котором находится. Ну и
ещё ими можно было заэкранировать мелкие кластеры вокруг деталей, чтобы
они не разбредались по всему уровню. (Попробуйте сделать такой брашик,
чтобы с его помощью можно было вырезать из больших брашей ёлочки,
например. А потом такой, чтобы по пять ёлочек сразу...) Но это опять же
в некотором род отступление от темы. А портал, который там называли
areaportal, работал по такому принципу: пока он не будет активирован
триггером - вся часть уровня, которая отделена им от игрока не рисуется
и даже не обрабатывается движком. После активации триггером портал
"открывался" и всё становилось нормальным. К сожалению этот портал
нельзя было закрыть, он так и оставался открытым.
Дальше появились порталы, встраиваемые в двери. Дверь открыта - и
уровень за ней обрабатывается, дверь закрылась - и та часть, которую
она отделяет больше не рисуется. Именно по этой причине порталы нельзя
ставить в прозрачные двери. Когда дверь закроется за ней вместо карты
будет пустое место. Ну и чуть позже (хотя может и одновременно)
появились автоматические порталы, которыми можно делить карту не только
по дверям, но по любому необходимому месту. В частности в третьем думе
портал автоматически распознаёт свой тип - если он касается двери, то
работает как дверной. А если нет - то как автоматический. А
автоматический портал работает довольно таки просто: он открыт пока
его видно на экране и закрыт, как только пропадает из виду.
Осталось сформулировать общие правила расстановик порталов:
Ознакомьтесь с правилами установки порталов в конкретно взятой игре. Разница может быть значительной.
Ставьте порталы во все непрозрачные объекты (двери и прочее).
Не ставьте порталы в прозрачные объекты, способные управлять порталом (стеклянная дверь, например).
И тем более не закрывайте порталы просто так. Если вы конечно не рисуете уровень, съедаемый лангольерами.
Несколько автоматических порталов в длинном узком коридоре не пойдут ему на пользу. Хватит одного в начале и одного в конце.
Тестируёте автоматические порталы если игра предоставляет такую
возможность. Удалите те порталы, которые вам не удаётся "закрыть", как
бы вы на них не смотрели.
На стыке коридор-комната лучше портал не ставить. Его следует
заглубить в коридор так, чтобы он был невидим из большей части комнаты.
В длинных коридорах удачным решением может оказаться пара порталов:
один на стыке с комнатой, а другой - в глубине коридора. Тогда даже при
открытом портале рисоваться будет только часть коридора.
Чем меньше порталов - тем лучше. Но только при обеспечении одинаковой оптимизации.
Не делайте порталов, которые обеими сторонами смотрят в один и тот же сектор. Пример - кольцевой коридор с одним порталом.
Пересечения порталов в общем случае нежелательны, но это зависит от игры.
Порталами можно сокращать глубокие ямы и высокие потолки. Всё равно игрок смотрит приимущественно вперёд.
Выясните, на что порталы не действуют.
Если в одном закутке собралось много порталов - скорее всего
половина там и не нужна вовсе. Желательно, чтобы закрытие каждого
портала приводило к отключению достаточно большого куска уровня. Ну по
крайней мере не тупичка из пяти стен.
