CitizenCon 2947: графические технологии

CitizenCon 2947: графические технологии

Разработка графических технологий

Эта презентация посвящена всем тем технологиям, которые помогают разработчикам достичь невероятного уровня качества графики. Также она позволит мельком взглянуть на некоторые планы на будущее с точки зрения интеграции новых технологий. Как уже известно, CIG использует в качестве движка для игры Amazon Lumberyard, но выдвигает к нему некоторые особые требования и вносит туда собственные доработки.

Али Браун, директор подразделения компьютерной графики в Великобритании, в своем докладе подробно расскажет о:

  • Процессах, которые выполняются при построении и выводе на экран одного кадра Star Citizen;
  • Движке Lumberyard и тех его элементах, которые им приходится модифицировать и дополнять;
  • Некоторых графических особенностях, которые недавно были внесены в 3.0;
  • Дорожной карте работ по графике;
  • Параллельной обработке данных на ЦП;
  • Планах разработки графических технологий на среднюю и дальнюю перспективу.

Ali_presentation.jpg

В конце доклада Али ответит на вопросы из зала.

Вступительный ролик показываем нам, из чего состоит кадр в Star Citizen, и что нужно сделать, чтобы построить его. Давайте разберем этот процесс с начала и до самого конца.

Поскольку у  нас теперь есть процедурные планеты, мы не можем просто взять и запечь все источники освещения для всех локаций. Так что первое, что мы делаем в самом начале кадра, это запекаем пробу в той части локации, где вы стоите. Это может быть луна, планета или даже часть космического пространства. На картинке показан рендер локального окружения с шести различных углов зрения. Затем нам нужно обработать, размыть и сжать результаты – все выполняется на лету. Это сложный процесс, поэтому мы разделяем одну текстуру на 20 кадров. Получается, каждые 20 кадров мы обновляем локализированное освещение, чтобы показать вам отражения кораблей или ближайших объектов.

probe_capture.jpg

Затем нужно создать тени. На рисунке изображен пул теней. Выглядит странно, но на самом деле это текстуры с разрешением 8K, в которые компонуются все тени. Здесь шесть крупных теней и целая куча мелких. Эта технология стала одной из тех, что мы расширили и доработали в Lumberyard, поскольку нам требовалась широкая вариативность качества наших теней. Порой нам требуются тени с разрешением 4K для синематиков, особенно для SQ42. А бывает, что нужно отобразить одновременно 30-40 теней на Levski, и тогда разрешение приходится снижать.

shadow_maps.jpg

Итак, первый этап при построении кадра заключается в оптимизации и визуализации всех объектов, которые, по нашему мнению, будут блокировать какие-то другие элементы сцены. Мы находим крупные объекты, обладающие небольшим числом вершин и полигонов и расположенные близко к камере, и при помощи дешевого шейдера рендерим их в первую очередь. Затем мы отправляем данные обратно на ЦП, чтобы выполнить отсечение невидимых объектов в многопоточном режиме. В результате при просчете следующего кадра на графический конвейер попадут только те объекты, которые окажутся видны. Лучшая оптимизация – это когда вообще не надо выполнять никакую работу. Отсечение также используется и на ГП для сокрытия всех поверхностей, которые заслоняются другими объектами.

После этого мы начинаем визуализацию материалов. На скриншоте показана лишь небольшая часть набора текстур, но всего мы можем накладывать до 15-20 текстур на один материал. Вы видите альбедо (цвет), карту нормалей, карту сглаживания, карту смешивания и карту высот. Обычно весь этот набор текстур накладывается дважды на один материал, но некоторые материалы имеют еще четыре слоя, а планета может иметь до 12 слоев. На самом деле мы не рендерим цвет, а создаем так называемый G-буфер для которого применяем Z-буферизацию. Мы выписываем информацию о материале, например, о нормалях, которые определяют, в какую сторону повернута поверхность.

textures.jpg

Сам рендер происходит в несколько стадий: сначала идет планетарная геометрия, к ней добавляются объекты-потомки, затем статические объекты, и в конце динамические объекты, персонажи и декали. Последовательность очень важна для корректного размещения элементов. Например, декали должны применяться к статической, а не к динамической геометрии, поскольку у них разные системы ограничений.

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

smoothness.jpg

Для материалов также применяется маскирование, которое позволяет использовать для лица персонажа и поверхности планеты свои особые эффекты, и вводится еще множество различных настроек. Они могут варьироваться в зависимости от типа материала. Например, материал на лице персонажа указывает нам, какую степень подповерхностного рассеивания следует использовать для имитации кожи. Мы записываем параметры в буфер и используем его для сортировки различных данных, которые могут потребоваться при визуализации материалов.

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

motion_vectors.jpg

Наконец, последняя текстура показывает подсвеченные места в кадре (например, подсветку шлема или огни от фар).

Далее наступает стадия применения пост-эффектов, и первый ее этап – определение атмосферы. Карта, которую вы видите на снимке, довольно абстрактная, но ее цвет является результатом предварительного расчета, который поможет в дальнейшей проработке атмосферы.

atmosphere.jpg

Второй этап – тени. Карта теней применяется к экранной проекции изображения, причем мы рендерим пять разных карт для солнца: от самой близкой до самой дальней. Детализация, соответственно, понижается с расстоянием.

Третий этап – скомпоновать все остальные точечные источники освещения в сцене. Они отбрасывают тени, которых может быть до 12 штук на пиксел.

Затем обрабатывается окклюзия (// затемнение отдельных участков сцены, прим. перев.). Представьте, что каждый пиксел представляет собой маленький конус, торчащий из поверхности. Мы стараемся определить, в какую сторону он повернется, учитывая, что там окклюзия должна быть наименьшей. Например, конус в центре стола будет смотреть вверх, тогда как конус у угла повернется по диагонали к центру. Поскольку расчет окклюзии для каждого пиксела отнял бы очень много ресурсов, мы сочетаем и комбинируем пикселы для получения корректного результата. Далее для устранения артефактов визуализации мы применяем сглаживание.

occlusion.jpg

Следующая карта отображает ширину конуса. В примере со столом по центру у нас будет 180° окклюзии, тогда как по краям лишь 90°, а в изломах и трещинах и того меньше.

Наступает этап освещения. Первой накладывается карта отражений в экранном пространстве координат. Мы проходим по экранному пространству, пытаясь найти места, где могут присутствовать отражения. На тестовом изображении отражающих поверхностей немного: зеркало под ногами персонажа, которое находится за кадром, и верхушка корабля. Однако мы не можем особо полагаться на этот метод, поскольку он не учитывает объекты за пределами экрана.

reflections.jpg

Наконец, один гигантский шейдер матового освещения поверхности объединяет все предыдущие карты, и картинка становится похожей на скриншот из игры. Шейдер был взят из Lumberyard и немного доработан. Мы добавили такие эффекты, как местные источники света, прямоугольные источники света и некоторые другие технологии, которые изначально отсутствовали в Lumberyard.

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

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

opaque.jpg

Однако цвета здесь тоже выглядят несколько неестественно, поскольку изображение до сих пор находится в цветовом пространстве HDR, где белый очень яркий, а черный невероятно темный. Позднее кадр будет переведен в пространство низкого динамического диапазона, но сперва нужно учесть все эффекты полупрозрачности, и первый из них – это туман.

На картинке показана базовая имплементация тумана из движка Lumberyard. Это очень мощный эффект. Хотя его визуализация выглядит странно, она показывает вид сверху вниз на один из "разрезов" тумана. Здесь используется воксельная симуляция на фиксированном расстоянии от камеры. Сейчас вы можете видеть своеобразные кубики на рисунке, но с перспективы камеры вы их не заметите. Затем добавляется освещение тумана, и сквозь него начинают проступать тени. После этого мы применяем его к нашему кадру.

fog.jpg

После тумана добавляются и другие объекты с эффектом прозрачности: кольца планеты, частицы, визор на стекле шлема. Затем наступает вторая фаза применения пост-эффектов.

Вначале в дело вступает система оптики. Мы реализовали ее в прошлом году и очень этим гордимся. Это важная система, ведь у нас игра в сеттинге научной фантастики, и вокруг полно огней и вспышек. Находясь на поверхности луны, у которой нет атмосферы, вы заметите огромный контраст между подсвеченной землей и непроглядной чернотой космоса. И мы хотим корректно имитировать этот контраст, сохранив при этом полный динамический диапазон. Поэтому первым делом мы строим карты mip-уровней, которые представляют собой те же самые изображения, но уменьшенного разрешения. Они нужны для сохранения производительности. Идея в том, что если мы захотим применить крупный эффект, вроде размытия, вытягивания изображения или вспышки от солнца, мы используем для него одну из mip-карт низкого разрешения.

mipmap.jpg

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

Следующий этап – добавить линзовые эффекты. Они основаны на физике искажений света линзой, которых у нас четыре различных типа. Мы аппроксимируем или симулируем результат, а художник может выбрать тот вариант, который ему нужен. Наше солнце принимает странную форму: у него появляются разноцветные свечения и хроматические абберации. Мы затемняем его, добавляем размытие для смягчения эффекта и аппроксимации артефактов линз. В зависимости от желания художника эти операции повторяются много раз для линз различных форм и размеров, и потом мы начинаем собирать их воедино в одну гигантскую вспышку. Главное преимущество этой системы в том, что она полностью процедурная и основывается на том изображении, которые мы отрендерили ранее. То есть, какое бы изображение мы не взяли, она сгенерирует для него такие линзовые эффекты, какие были бы у реального объектива камеры. Вам даже не нужен настоящий источник света – достаточно отраженного освещения или вспышки от огня, взрыва или лазера – все они могут генерировать линзовые эффекты. И еще очень важно, что художникам не нужно вручную определять каждый эффект, а арт-директора могут изменять вид игры при помощи простой регулировки параметров линзовых эффектов.

Следом идет применение размытия. Многие игры сейчас используют его, но тут этот эффект основывается на физических параметрах. После него выполняется цветокоррекция, которая позволяет художникам преобразовать цвета в желаемую палитру.

И еще одна оптическая технология – это наша новая система экспонирования. Она все еще дорабатывается, при том что планеты и луны задействуют ее предельные возможности. Мы генерируем гистограмму всей сцены и анализируем ее яркость. Из-за экстремального контраста мы заходим дальше обычной аппроксимации видимой картинки и симулируем два различных механизма. Первый– это реакция зрачка, который может изменяться в размерах от 4 до 8мм и очень быстро переходить от светлой сцене к темной. Однако его возможности ограничены, и он не сможет корректно отреагировать на экстремальное изменение яркости (например, при выходе из темной комнаты на свет). Вот для чего нужен второй механизм симуляции, который обеспечивает гораздо более длительное экспонирование и обладает гораздо более широким радиусом, но занимает больше времени на переход. В итоге нам удается снизить время адаптации к свету с реальных 40 секунд до, приблизительно, 20 секунд.

exposure.jpg

Собираем все оптические эффекты вместе и получаем гораздо более приятно выглядящую сцену.

Но и это еще не все. Теперь надо подчистить изображение и применить сглаживание. Технология SMAA уже была в Lumberyard и Cry Engine ранее. Она хорошо выискивает все зазубренные грани, разбивает их по группам в зависимости от типа (представлены различными цветами на картинке), а затем пытается заполнить пробелы путем использования умного размытия так, как будто вы проводите рендер в более высоком разрешении.

smaa.jpg

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

Технически временное сглаживание анализирует помимо текущего кадра еще и три предыдущих. Мы слегка смещаем изображение, чтобы алгоритм в каждом кадре мог определить детали, которые необходимо сгладить, но невооруженным глазом это заметить невозможно. В итоге сэмплы из соседних кадров смешиваются в одном пикселе. Проблема тут в том, что в этих четырех кадрах могут присутствовать различные движущиеся объекты, вроде кораблей и планет, а также полупрозрачные элементы пользовательского интерфейса. Из за них учитывать движения сглаживаемых объектов в четырех кадрах становится сложно. Недавно мы внесли изменение в алгоритм, которое, как мы надеемся, поможет решить проблему, но все равно вы сможете увидеть работу временного сглаживания уже в 3.0.

final_optics.jpg

 

Над следующим списком изменений, которые уже внесены в 3.0.0, команда по графике из Великобритании работала совместно с инженерами движка из Франкфурта:

1) Система P4K

Это новая система доставки данных, которая значительно сокращает время сборки нового билда. Суть ее работы в том, что мы объединяем все данные в один колоссальных размеров файл, но система доставки проникает туда и находит внутри индивидуальные элементы, которые нужно изменить. Затем она переносит только часть данных вместо того, чтобы копировать весь файл целиком. В результате мы можем разворачивать новые билды за секунды вместо десятков минут, как было раньше. Вдобавок мы изменили алгоритм сжатия и добавили специализированный поток стриминга с SSD, который позволил передавать за раз сразу несколько файлов. Начиная с 3.0, вы заметите огромную разницу в процессе загрузки и установки обновлений.

2) Улучшение производительности сервера

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

3) Вращение планет

Реализация вращения тоже была непростой задачей. Например, как я уже упомянул ранее, при применении алгоритма временного сглаживания вы не ожидаете, что пол у вас под ногами начнет двигаться. Но теперь все перемещается со скоростью тысячу миль в час, поэтому вы сможете наблюдать изменение условий освещения со временем. Конечно, время у нас течет быстрее, чем в реальности, так что вам не придется ждать 24 часа, чтобы увидеть восход и закат.

4) Рендер в текстуру

Про него уже рассказывалось в одном из выпусков "Вокруг Вселенной". На картинке приведен пример использования этой технологии. Она нужна для отображения голограмм и экранов с пользовательским интерфейсом и позволяет нам встраивать контент из другой локации или из двухмерного набора графики прямо в игровой мир.

already_in_30.jpg

5) Временное сглаживание TSAA

Про него уже было рассказано.

6) Улучшения прямой окклюзии в экранном пространстве (SSDO)

На скриншоте показана ее новая версия:

ssdo.jpg

Вы видите больше контраста и более глубокие тени на щеках, в районе ноздрей и вокруг глаз персонажа. В новой версии гораздо больше деталей.

7) Новые кинематографические кривые тональной компрессии

Они отвечают за цветокоррекцию и служат для перевода изображения в цветовое пространство с низким динамическим диапазоном. Результат цветокоррекции в старой версии был недостаточно ярким и живым, он не бросался в глаза. Цвета в новой версии значительно более выраженные, и они соотносятся со стандартной кривой тональной компрессии, используемой в индустрии.

aces.jpg

8) Первый из новых шейдеров материалов

Мы начали работу над новым набором шейдеров материалов. Мы пытаемся сделать их более физически-корректными, но также стараемся реализовать больше таких шейдеров, которые будут имитировать грязь, поношенность и различные внешние повреждения на предметах. Первым по списку стало физически-корректное стекло, которое вы можете видеть на кабине Gladius. Это стекло имитирует преломление света, и нашим художникам не терпится приступить к работе с ним. С новым шейдером мы можем создавать эффекты цветного, грязного и даже разбитого стекла – Крис и художники давно просили реализовать нечто подобное. После релиза 3.0 мы продолжим работу над ними, и в конечном итоге все материалы получат обновления.

glass_shader.jpg

 

Итак, переходим к планам на ближайшую перспективу:

  1. Улучшенные волосы;
  2. Окклюзия и затенение ландшафта;
  3. Шейдеры материалов, на вид которых будет влиять игровой процесс;
  4. Газовые облака (также известные как "космический туман");
  5. Новый эффект для щитов, использующий обрабатываемые на ГП частицы;
  6. Улучшения глубины резкости;
  7. Улучшения цветовой обработки;
  8. Новая реализация размытия в движении;
  9. Поддержка сложных шейдерных моделей.

near_term.jpg

 

Следующий слайд посвящен параллельной обработке данных на ЦП.

Не секрет, что сложность современных игр продолжает расти, и они предъявляют все большие требования к процессору. Star Citizen тут не является исключением. Его сложный программный код, рендеринг и все используемые технологии тоже сильно нагружают процессор.

Многопоточная обработка очень важна для хорошей работы игры. Мы активно используем ее, особенно последнее время, для получения максимума производительности. Ее реализацией заведует команда из Франкфурта и главный программист движка Крис Полти. Для улучшения производительности мы используем две системы: обновление пакетов данных и обработку фоновых процессов.

Обработчик пакетов данных используется для обновления групп схожих объектов, распределенных по нескольким ядрам ЦП. Например, когда мы хотим вызвать тысячу объектов.

  • Особенно полезен при объединении с нашей системой сущностей компонентов.
  • Позволяет легко распараллеливать большую часть игрового кода, что существенно повышает производительность.
  • Система в основном используется для выполнения работы, зависящей от кадра на экране. Например, при отсечении невидимых объектов.

batch_updater.jpg

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

  • Система разработана с прицелом на объекты, чьи расчеты выполняются одним процессом.
  • Идея в том, чтобы запускать систему фоновых процессов всякий раз, когда обработчик пакетов данных остается без работы, чтобы ЦП не простаивал в бездействии.

Теперь стоит рассказать про сами обработчики фоновых процессов, о которых ранее Крис уже упоминал.

Они прочно связаны с низкоуровневой системой ввода/вывода. Обработчики считывают файлы сразу множеством (при использовании SSD или Optane) или по одному (с HDD) параллельными блоками, используя для этого асинхронный ввод/вывод. Когда блок файла заканчивается, свободный обработчик просыпается и проводит расшифровку и декомпрессию вышеупомянутого блока (даже если тот еще не загружен в память целиком). Приятный момент в том, что из-за большого числа параллельных файлов мы можем одновременно обрабатывать несколько блоков.

 

Теперь перейдем к планам на среднесрочную и долгосрочную перспективу:

  • Поддержка стриминга контейнеров объектов (куда входят отдельные части уровня, корабли, локации, помещения и т.п.) на низком уровне / на стороне системы;
  • Улучшенные планетарные эффекты (тени, облака, дороги и др.);
  • Улучшенные космические эффекты (солнце, звезды, кольца планет и др.);
  • Динамическое глобальное освещение (для внутренних помещений);
  • Группирование физических потоков в пакеты данных (для мнопоточной обработки);
  • Группирование потоков рендеринга;
  • Поддержка Vulkan на стороне сервера – позволит улучшить производительность при вызове на отрисовку большого числа объектов.

mid_long_term.jpg

Ответы на вопросы из зала

  • Первый вопрос от Брайана: Что, по твоему мнению, станет самым сложным и уникальным испытанием при дальнейшей разработке тех технологий, о которых было сказано выше?

Наверное, это масштабы, особенно по сравнению с тем, над чем мы работали раньше. Первый аспект тут – это физический размер (например, солнечная система с планетами). Очень сложно заставить корректно работать множество эффектов при таких гигантских размерах мира, когда еще вдобавок вращаются планеты. Также тяжело загружать данные и управлять ими. Еще один элемент – это рендеринг. Обычно он основан на предположениях, т.е. вы прикидываете, сколько должно быть кадров в секунду в той или иной сцене. Но для такого огромного открытого мира строить гипотезы очень сложно.  Второй аспект масштаба – это, очевидно, сам игровой процесс. Вы не можете быть окончательно уверены, что все ошибки исправлены, и все элементы будут выглядеть именно так, как положено. Мир динамически меняется, постоянно появляется какой-то неожиданный геймплей. Объект мог быть здесь минуту назад, но теперь он уничтожен. Нам приходится проявлять значительно более творческий подход и придумывать, как можно заставить игру выглядеть хорошо и работать быстро.

Брайан: еще постоянно приходится взаимодействовать с другими отделами. При таком широком масштабе требуется учитывать очень много нюансов в процессе создания каких-то вещей.

  • Возможно ли при помощи технологии рендера в текстуру реализовать внутренний проецируемый мостик на Polaris или сделать второй мостик на Idris (как в Star Trek)?

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

  • Я удивлен тем количеством PBR (физически-корректного рендеринга), которое сейчас добавляется в игру. Он потребляет довольно много ресурсов. Общаетесь ли вы с AMD и Nvidia для дальнейшей разработки технологии PBR?

В случае с PBR приходится изучать много онлайн-презентаций с SIGGRAPH или GDC – там можно почерпнуть много информации о реализации технологии. Но когда речь заходит о производительности, мы вынуждены связываться с независимыми поставщиками аппаратного обеспечения, вроде AMD и Nvidia, потому что такие вещи, как, например, шейдер непрозрачности, очень непросто заставить работать быстро. Сложно сбалансировать его работу на разных архитектурах, поэтому нужно тесно сотрудничать с производителями.

  • Занимаетесь ли вы исследованиями и разработкой самостоятельно или берете наработки у AMD и Nvidia?

Мы не берем разработки напрямую, мы изучаем доклады их инженеров на GDC и других конференциях. Конечно, много чего мы разрабатываем и внутри студии, например, оптические технологии. В случае же с пространственным освещением мы изучали работы других игровых студий. Нет какого-то одного источника, мы добываем информацию везде, где можем ее найти.

  • В дополнение к вопросу про технологию рендера в текстуру. На бронекостюме исследователя RSI мы видели камеру на плече. Можно ли будет, например, отправить команду в экспедицию и смотреть на происходящее с их позиции через интерфейс в кабине корабля? То есть, вы сказали, что технически это возможно, но будет ли это практично?

Я не могу ответить односложно: да или нет. Я не дизайнер, поэтому не знаю. Иногда нам просто нужно провести серию тестов производительности на разных графических картах, чтобы это выяснить. Как правило, у нас есть перечень, где указано, какие действия, скорее всего, окажутся возможны, а какие нет. Но обычно, если я нахожусь в комнате, где мало окон или нет окон вообще, я могу безболезненно проецировать вид с другой камеры, потому что у меня есть запас по бюджету производительности. На открытом же пространстве, когда вы видите другие объекты, планеты и астероиды, бюджет не позволит вывести проекцию еще одной картинки, где также будут видны объекты, планеты и астероиды. Все будет зависеть от того, где вы находитесь и на что смотрите.

  • Вы упомянули про большую нагрузку на ЦП. Какой процессор вы бы рекомендовали для игры: с 8 или 12 потоками?

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

  • Большинство игр, в которые я играл, использовали имитацию зеркал. Реально ли реализовать настоящее зеркало, не порушив при этом производительность?

Да, мы можем сделать зеркало. Тем не менее, придется дополнительно поработать, потому что зеркало не похоже на камеру – оно переворачивает изображение, и этот переворот придется просчитывать на этапе рендеринга. Технически это возможно, и мы хотели бы это сделать, но тут опять вмешивается вопрос производительности. Если вы захотите посмотреть в зеркало, стоя на мостике Idris, в нем отразится весь корабль... Где-то в ванной может быть, да.

Admin administrator