RSS
Меню сайта

Категории каталога
Doom3 [11]
Статьи о разработке карт к Doom3
Общее [7]
Статьи про общие моменты маппинга

Наш опрос
Навигация в "Файлах"
Всего ответов: 20

Copyright C4TNT© 2008

Главная » Статьи » Маппинг » Общее

Техно #1
Итак, для начала небольшое лирическое отступление.

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

Техно #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, работал по такому принципу: пока он не будет активирован триггером - вся часть уровня, которая отделена им от игрока не рисуется и даже не обрабатывается движком. После активации триггером портал "открывался" и всё становилось нормальным. К сожалению этот портал нельзя было закрыть, он так и оставался открытым.

Дальше появились порталы, встраиваемые в двери. Дверь открыта - и уровень за ней обрабатывается, дверь закрылась - и та часть, которую она отделяет больше не рисуется. Именно по этой причине порталы нельзя ставить в прозрачные двери. Когда дверь закроется за ней вместо карты будет пустое место. Ну и чуть позже (хотя может и одновременно) появились автоматические порталы, которыми можно делить карту не только по дверям, но по любому необходимому месту. В частности в третьем думе портал автоматически распознаёт свой тип - если он касается двери, то работает как дверной. А если нет -  то как автоматический. А автоматический портал работает довольно таки просто:  он открыт пока его видно на экране и закрыт, как только пропадает из виду.

Осталось сформулировать общие правила расстановик порталов:

  1. Ознакомьтесь с правилами установки порталов в конкретно взятой игре. Разница может быть значительной.
  2. Ставьте порталы во все непрозрачные объекты (двери и прочее).
  3. Не ставьте порталы в прозрачные объекты, способные управлять порталом (стеклянная дверь, например).
  4. И тем более не закрывайте порталы просто так. Если вы конечно не рисуете уровень, съедаемый лангольерами.
  5. Несколько автоматических порталов в длинном узком коридоре не пойдут ему на пользу. Хватит одного в начале и одного в конце.
  6. Тестируёте автоматические порталы если игра предоставляет такую возможность. Удалите те порталы, которые вам не удаётся "закрыть", как бы вы на них не смотрели.
  7. На стыке коридор-комната лучше портал не ставить. Его следует заглубить в коридор так, чтобы он был невидим из большей части комнаты. В длинных коридорах удачным решением может оказаться пара порталов: один на стыке с комнатой, а другой - в глубине коридора. Тогда даже при открытом портале рисоваться будет только часть коридора.
  8. Чем меньше порталов - тем лучше. Но только при обеспечении одинаковой оптимизации.
  9. Не делайте порталов, которые обеими сторонами смотрят в один и тот же сектор. Пример - кольцевой коридор с одним порталом.
  10. Пересечения порталов в общем случае нежелательны, но это зависит от игры.
  11. Порталами можно сокращать глубокие ямы и высокие потолки. Всё равно игрок смотрит приимущественно вперёд.
  12. Выясните, на что порталы не действуют.
  13. Если в одном закутке собралось много порталов - скорее всего половина там и не нужна вовсе. Желательно, чтобы закрытие каждого портала приводило к отключению достаточно большого куска уровня. Ну по крайней мере не тупичка из пяти стен.
Категория: Общее | Добавил: c4tnt (10.01.2009)
Просмотров: 578 | Комментарии: 1 | Рейтинг: 0.0/0
Всего комментариев: 1
1  
Кстати, полезнейшая статья!

Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]
Вход:

Поиск

Ссылки


Статистика

Онлайн всего: 1
Гостей: 1
Пользователей: 0


Работаем на керосине