XashNT renderer: статика vs динамика
Поскольку XashNT - это мой последний проект, создаваемый на прежних условиях, да и то благодаря двум обстоятельствам (желанию освоить современные техники рендерера и дать пользователям связки Xash3D+XashXT более-менее современные возможности), то хотелось бы особенно отвеетственно подойти к выбору рендерера и его возможностям.
Темы про материалы все помнят, как долго я колебался и размышлял. Теперь предстоит решить еще один не менее важный вопрос, после чего можно приступать, непосредственно к написанию рендерера. Пока Элбер доделывал Параною, я тут тоже даром времени не терял и внимательно изучал возможности современных движков, на графику которых принято ориентироваться, как на эталонную на текущий момент. Разумеется, как и всегда, я не ставлю перед собой цель "сделать, чтобы было похоже на ХХХ". Если технологии и навыки позволяют, то вполне логично сделать лучше и быстрее, во всяком случае попытаться, учитывая чужие наработки и ошибки. И естественно лучше всего это делать, еще до написания рендерера, а не переписывать потом всё по 10 раз. Теперь я кратенько распишу про особенности рендеринга известных движков, те любопытные обстоятельства, которые мне удалось выяснить за всё это время. Если вы в своё время плотно работали с этими движками и вам есть что добавить, рассказать про ограничения и возможности - велкам в тред.
Итак:
CryEngine 2: Для меня было самым настоящим открытием тот факт, что в первом срузисе используется forward rendering. На тематических форумах можно встретить любопытное утверждение, что SubSurface Scattering для forward-рендеринга смотрится намного лучше post-реализации во втором срузисе. Это легко объяснимо тем фактом, что при прямом рендеринге мы располагаем куда большим объемом информации о геометрии. Но в целом ничего удивительного в этом нет - 90% игры происходит на открытом воздухе с одним-единственным источником освещения - солнцем\луной. А глобальную иллюминацию иммитирует SSAO в паре с SubSurface Scattering. Ну и есть еще дополнительная фишка, Dynamic AO Terrain, которая затеняет участки под ёлками-пальмами. Так или иначе, но многим картинка первого срузиса нравится больше, чем картинка второго.
СryEngine 3: А здесь я узнал, что после его выхода, Капланян покинул студию. Сам он ушел или его ушли, теперь уже не разберешь. Но для меня даннный факт по значимости примерно экивалентен уходу Ромеры из ID. Только во втором случае мы потеряли лишь в качестве контента для демонстрации новых движков, потому что после первой кваки ничего столь же атмосферного ID так и не смогла родить. А в случае с крайтеком, компания, которая вознамерилась продолжать славное дело ID, продавая движки, фактически потеряла главного генератора идей и разработчика новых технологий. Видимо этим отчасти и объясняется тот факт, что в CryEngine 4 никаких особых прорывов не наблюдается.
SSLR прорывом можно назвать лишь с натяжкой, к тому же технология была внедрена еще в CryEngine 3 более поздних версий. Ну да бог с ним.
Касательно технических подробностей, важнейшим нововведением в CryEngine 3 является LPV - Light Propagation Volume. Это одна из технологий для симуляции непрямого освещения, или как любит говорить ФиЭктро - реалтайм радиосити (хотя назвать эту аппроксимацию радиосити, лично у меня язык не поворачивается). Идея LPV заключается в следующем. Вокруг игрока имеется набор вложенных сеток. Самая маленькая - самая густая, самая большая - разреженная.
Сетки строятся налету, таким образом отпадает необходимость в предвычислениях. В эту сетку попадают виртуальные непрямые лайты, по классическим алгоритмам, которые использовались еще со времен оффлайн-рассчётов. hlrad, грубо говоря делает примерно тоже самое - рассчитывает места где свет должен отразиться от стен и лепит туда маленькие лампочки. Это альтернатива честному рейтрейсингу.
В CryEngine 3 подобные рассчёты доступны в реальном времени, естественно с массой оговорок - лампочки жестко привязаны к ячейкам сетки, отражения могут происходить только в шести аксиальных направлениях (стороны куба), сетка имеет конечную точность, рассчёт осущствляется только для параллельного источника (солнца). Но зато полная динамика без предвычислений.
Frosbite 2: Специально изучением его возможностей я не занимался, уяснил только ключевые моменты: лайтпробы считаются в оффлайне, они являют собой статичную сетку (иррегулярную?), но зато общее качество освещения выше, чем при использовании LPV, что вообщем-то неудивительно, поскольку предрасчёты всегда дают более качественный результат, в противном случае алгоритм просто хоронят. Но зато динамические объекты в Frostbite не вносят вклада в переотражения, что возможно имеет значение для больших динамических объектов.
Unreal 4: самый консервативный движок, насколько я понял, уже после того момента как эпики по каким-то соображениям отказались от технологии Enlighten. Теперь у них отраженный свет запекается в хитрую лайтмапу, а прямой считается налету. Насколько я понял, там полным-полно ограничений, от которых плюются наши более въедливые товарищи, но несмотря на частичную статику освещения, UE4 выдает наиболее приятную картинку из всех, что вообщем неудивительно, поскольку лайтмапы почти всегда выглядят лучше динамически посчитанного света. К слову сказать тот же Enlighten использует проекционные лайтмапы, с предрасчётов геометрии низкой детализации на геометрию высокой, но я особо не погружался в эту технологию.
Ну и после того как вы переварите вышенаписанное, я вас плавно подвожу к основному вопросу этой темы: в какой пропорции нам разбавить статику динамикой, чтобы и картинка была приятной глазу и смену времени суток организовать. Это моя личная позиция, и как выяснилось, в вышеупомянутых движках она тоже разделена в той или иной степени. Т.е. солнце у нас так или иначе выдает почти честную динамику с непрямым освещением, а всё остальное - как придется.
Если вы девелопите под связку Xash3D+XashXT и имеете что сказать по поводу соотношения динамики и статики на уровне - велкам в тред.
Если вы не имеете отношения к ксашу, но при этом изучили массу современных движков и знаете все недостатки и достоинства их рендереров и вам хочется об этом написать - велкам в тред.
Если у вас есть какое-то свое собственное видение, пускай и нигде не реализованное, но вам отчего-то кажется, что оно вполне реализуемое - велкам в тред.
Я так полагаю, дискуссия будет достаточно объемной и информативной.
А по итогам уже сформируем модель будущего рендерера и я приступлю к его реализации.
Поскольку XashNT - это мой последний проект, создаваемый на прежних условиях, да и то благодаря двум обстоятельствам (желанию освоить современные техники рендерера и дать пользователям связки Xash3D+XashXT более-менее современные возможности), то хотелось бы особенно отвеетственно подойти к выбору рендерера и его возможностям.
Темы про материалы все помнят, как долго я колебался и размышлял. Теперь предстоит решить еще один не менее важный вопрос, после чего можно приступать, непосредственно к написанию рендерера. Пока Элбер доделывал Параною, я тут тоже даром времени не терял и внимательно изучал возможности современных движков, на графику которых принято ориентироваться, как на эталонную на текущий момент. Разумеется, как и всегда, я не ставлю перед собой цель "сделать, чтобы было похоже на ХХХ". Если технологии и навыки позволяют, то вполне логично сделать лучше и быстрее, во всяком случае попытаться, учитывая чужие наработки и ошибки. И естественно лучше всего это делать, еще до написания рендерера, а не переписывать потом всё по 10 раз. Теперь я кратенько распишу про особенности рендеринга известных движков, те любопытные обстоятельства, которые мне удалось выяснить за всё это время. Если вы в своё время плотно работали с этими движками и вам есть что добавить, рассказать про ограничения и возможности - велкам в тред.
Итак:
CryEngine 2: Для меня было самым настоящим открытием тот факт, что в первом срузисе используется forward rendering. На тематических форумах можно встретить любопытное утверждение, что SubSurface Scattering для forward-рендеринга смотрится намного лучше post-реализации во втором срузисе. Это легко объяснимо тем фактом, что при прямом рендеринге мы располагаем куда большим объемом информации о геометрии. Но в целом ничего удивительного в этом нет - 90% игры происходит на открытом воздухе с одним-единственным источником освещения - солнцем\луной. А глобальную иллюминацию иммитирует SSAO в паре с SubSurface Scattering. Ну и есть еще дополнительная фишка, Dynamic AO Terrain, которая затеняет участки под ёлками-пальмами. Так или иначе, но многим картинка первого срузиса нравится больше, чем картинка второго.
СryEngine 3: А здесь я узнал, что после его выхода, Капланян покинул студию. Сам он ушел или его ушли, теперь уже не разберешь. Но для меня даннный факт по значимости примерно экивалентен уходу Ромеры из ID. Только во втором случае мы потеряли лишь в качестве контента для демонстрации новых движков, потому что после первой кваки ничего столь же атмосферного ID так и не смогла родить. А в случае с крайтеком, компания, которая вознамерилась продолжать славное дело ID, продавая движки, фактически потеряла главного генератора идей и разработчика новых технологий. Видимо этим отчасти и объясняется тот факт, что в CryEngine 4 никаких особых прорывов не наблюдается.
SSLR прорывом можно назвать лишь с натяжкой, к тому же технология была внедрена еще в CryEngine 3 более поздних версий. Ну да бог с ним.
Касательно технических подробностей, важнейшим нововведением в CryEngine 3 является LPV - Light Propagation Volume. Это одна из технологий для симуляции непрямого освещения, или как любит говорить ФиЭктро - реалтайм радиосити (хотя назвать эту аппроксимацию радиосити, лично у меня язык не поворачивается). Идея LPV заключается в следующем. Вокруг игрока имеется набор вложенных сеток. Самая маленькая - самая густая, самая большая - разреженная.
Сетки строятся налету, таким образом отпадает необходимость в предвычислениях. В эту сетку попадают виртуальные непрямые лайты, по классическим алгоритмам, которые использовались еще со времен оффлайн-рассчётов. hlrad, грубо говоря делает примерно тоже самое - рассчитывает места где свет должен отразиться от стен и лепит туда маленькие лампочки. Это альтернатива честному рейтрейсингу.
В CryEngine 3 подобные рассчёты доступны в реальном времени, естественно с массой оговорок - лампочки жестко привязаны к ячейкам сетки, отражения могут происходить только в шести аксиальных направлениях (стороны куба), сетка имеет конечную точность, рассчёт осущствляется только для параллельного источника (солнца). Но зато полная динамика без предвычислений.
Frosbite 2: Специально изучением его возможностей я не занимался, уяснил только ключевые моменты: лайтпробы считаются в оффлайне, они являют собой статичную сетку (иррегулярную?), но зато общее качество освещения выше, чем при использовании LPV, что вообщем-то неудивительно, поскольку предрасчёты всегда дают более качественный результат, в противном случае алгоритм просто хоронят. Но зато динамические объекты в Frostbite не вносят вклада в переотражения, что возможно имеет значение для больших динамических объектов.
Unreal 4: самый консервативный движок, насколько я понял, уже после того момента как эпики по каким-то соображениям отказались от технологии Enlighten. Теперь у них отраженный свет запекается в хитрую лайтмапу, а прямой считается налету. Насколько я понял, там полным-полно ограничений, от которых плюются наши более въедливые товарищи, но несмотря на частичную статику освещения, UE4 выдает наиболее приятную картинку из всех, что вообщем неудивительно, поскольку лайтмапы почти всегда выглядят лучше динамически посчитанного света. К слову сказать тот же Enlighten использует проекционные лайтмапы, с предрасчётов геометрии низкой детализации на геометрию высокой, но я особо не погружался в эту технологию.
Ну и после того как вы переварите вышенаписанное, я вас плавно подвожу к основному вопросу этой темы: в какой пропорции нам разбавить статику динамикой, чтобы и картинка была приятной глазу и смену времени суток организовать. Это моя личная позиция, и как выяснилось, в вышеупомянутых движках она тоже разделена в той или иной степени. Т.е. солнце у нас так или иначе выдает почти честную динамику с непрямым освещением, а всё остальное - как придется.
Если вы девелопите под связку Xash3D+XashXT и имеете что сказать по поводу соотношения динамики и статики на уровне - велкам в тред.
Если вы не имеете отношения к ксашу, но при этом изучили массу современных движков и знаете все недостатки и достоинства их рендереров и вам хочется об этом написать - велкам в тред.
Если у вас есть какое-то свое собственное видение, пускай и нигде не реализованное, но вам отчего-то кажется, что оно вполне реализуемое - велкам в тред.
Я так полагаю, дискуссия будет достаточно объемной и информативной.
А по итогам уже сформируем модель будущего рендерера и я приступлю к его реализации.
