Они на самом деле есть, но я оставил эту информацию для раздела про шейдеры, мне просто было нужно заострить внимания на фокусах и в расследовательском формате потом уже пояснить, где на самом деле всё спрятано. Про одни текстуры можно статью написать, но она выйдет техничной и скучной, в формате справочника. У локаций есть даже множители для того же Specular. Шейдеры, в нашем случае, наиболее информативны и будет в разы интереснее. Для меня самый большой вопрос, почему объекты в Скайриме выглядят очень похоже, даже если накатывать 4K текстуры.
Для этого сначала придётся пояснить, что такое EarlyZ, потом что такое сам Z-Prepass, потом особенности реализации в Скайриме, потом что они используют его неправильно. Это всё будет в следующей части. На данный момент, чтобы никого не путать, достаточно обобщения.
С чего бы ему быть дорогим?
Насколько я понял, он был вырезан на консолях (кроме скайбокса), так же рекомендации по оптимизации тех лет, прямо рекомендуют выключать всё, кроме неба. Раньше и планарные отражения использовали, это не значит, что это дёшево.
складывается впечатление, что SSAO, тени и буфер глубины создаются после основного прохода рендера
SSAO действительно создаётся на стадии пост-обработки, после основного рендера, так как для SSAO требуются итоговые нормали в экранном пространстве.
Это не так, стадия маркирования проходит через ссылки с построением графа. Так как объект доступен по ссылке, то все ссылки внутри тоже будут распознаны. Проход по управляемой кучи будет уже на стадии планирования, но нам она и не нужна.
Должен, GC берёт ссылки из полей корней, данные где расположены ссылки берутся из мета-информации, которую поставляет таблица методов. В искусственном объекте есть таблица методов с корректной мета-информацией, значит GC распознает ссылки, так же все отметки достижимости и закрепления хранятся в самом объекте, и тоже будут валидны. Но сам объект должен иметь внешние ссылки, чтобы GC его вообще видел или быть закреплённым. Однако, GC ещё занимается планированием кучи, и может посчитать, что объект находится в куче и ложно копировать его при уплотнении, поэтому всегда стоит использовать закрепление. В простом случае, можно использовать класс обёртку, который автоматический убирает закрепление при финализации объекта. Я не уверен, что GC обязательно попытается его скопировать, но он однозначно распознает ссылки внутри. Этот метод описан достаточно давно и сборка мусора не вызывает ни каких повреждений. Правда, все ситуации синтетические.
Лично мне интересно попробовать использовать этот метод для более тщательной разметки памяти.
Построение графа зависимостей подразумевает, что экземпляр может быть в других кучах или вообще залочен в неуправляемой памяти, поэтому все поля будут валидны и не собраны, более того, ссылка на сам объект будет учитываться в поколении. Однако, не факт, что будет вызван финализатор или IDispose, так как для них требуется сначала перепланировка кучи, поэтому следует использовать IDispose интерфейс во внешнем классе для связи с GC. И так же пинить сам объект, чтобы исключить ошибки планировщика кучи при попытке перераспределить память.
Какая хорошая техническая статья, на самом деле весь интероп огромная боль, а GC вообще необузданный монстр. Каждый раз при попытке хоть как-то контролировать освобождение памяти вылазит просто уйма нюансов и костылей в виде ObjectPooling. А здесь даже мимикрия под настоящий класс, ну просто красота.
Почему objectHeader находится по адресу -8? Зачем так сделано? Хз. Даже майкрософт говорили, что просто так исторически сложилось и никакого скрытого смысла здесь нет.
Смысл здесь логический, так как классы управляемые, objectHeader - это как раз обёртка, а по указателю что должно лежать? правильно мякотка, и никому кроме обработчика в частных случаях обёртка не нужна. Да и регулярно добавлять +8 к любому обращению к классу, который в жизни обработкой заниматься не будет - такое себе. В то время как та же таблица методов уже является частью реализации и жертвой постоянных обращений от всех владельцев ссылки.
Какой ещё гиперзвук у амеров не получился? Что там Китай быстрее освоил? США хотели себе атмосферные глайдеры, с гиперзвуком в 21 число маха. 5-7 махов, на которых летают ракеты РФ, у амеров были ещё на первых тестовых испытаниях. А в концепции, просто, гиперзвуковых ракет - они не верят, и забраковали их ещё при исследованиях в 80-х. Как показывает практика - не зря, потому как центральной идеей РФ была идея хоть как-то попытаться пробиться через глобальную систему ПРО стран НАТО. По итогу одиночные мобильные базовые версии установок, перехватывают все эти золотые ракеты. Что там говорить об эшелонированной обороне и разведке. Получились просто быстрые ракеты, только очень дорогие. По остальным параметрам эти ракеты ни чем не лучше стандартных. США не могут позволить себе так бессовестно пилить бюджет.
Отношение экземпляров к количеству полигонов - это условность, конкретно технологии, Nanite. Смысл, скорее, в итоговом количестве в 4 млрд. полигонов. По тестам Эпиков, современные видеокарты падают на количестве 300-350 млн. полигонов. Софтверный рендер обходит это ограничение. По итогу, вам всё же требуется закрасить, всего, 8 млн. пикселей для 4K монитора. В демонстрации, Эпики показывали как Нанит режет исходные триллионы до, всего 20 млн., вызываемых для отрисовки, полигонов на кадр.
Обо всём на свете и ни о чём конкретно. Я не касался всего рендера, я рассмотрел конкретную часть.
Для маленькие запполенение идет в ручную
Вы имеете ввиду, софтверный рендер?
Основное хадварное ускорение на gpu - zbuffer, там прям на чипе имеет большой кеш.
Для одного, только, Z-буфера вам потребуется 8 мб кэша на FullHD разрешении. У 3090 на борту 6 мб. В большинстве производительных карт от 2 до 4 мб кэша. Только начиная с последнего поколения видеокарт Nvidia у вас будет больше 8 мб для Z-буфера.
Поэтому ни какого "хардварного ускорения" нету.
Проблемы перерисовки ни как Z-буфером не решаются. Как я уже отмечал, для решения этой проблемы в наше время проводятся исследования, но ни какого решения ни в одном игровом движке, кроме, UE 5 с Нанитами - нету вовсе.
Его используют и для. MaterialID
Ничего там магического нет, это 500 строчек
Это уже магия. Использование MaterialID через буфер глубины - это хак, чтобы избежать повторного рендера в буфер трафарета. Z-буфер для этого не предназначен.
Соглашусь, по моим оценка, это буквально единственная серьёзная причина, почему многие остаются на Unity. Писать код на Шарпе значительно проще.
Но могу вас заверить, Unreal Engine использует много обёрток и даже собственный сборщик мусора, чтобы разгрузить программиста, попытки перейти на C++, будут для программиста намного проще.
Если очень грубо - это хитрый софтверный растеризатор с иерархией, который конечно же эксплуатирует mesh-shader'ы, если они доступны.
Не совсем, там используется и софтверный, написанный на Cuda и OpenCL, и одновременно классический конвейер. Результаты объединяются, архитектура Unreal Engine - позволяет проворачивать такой трюк. Но ни какой иерархии растеризации нет, вы вероятно перепутали с Иерархичным Буфером Глубины(HZB), который используется для кулинга или вы, вообще, о геометрии.
Нанит производит конвертацию модели, в этот момент можно и выставить качество конвертации. Возможно, я не правильно выразился - Нанит использует уровни детализации для кластеров, но не в привычном понимании, это скорее тесселяция, чем обычные лоды.
(все равно надо учитывать выравнивание, локальность)?
Нет, это полностью опционально, вы можете использовать mesh-шейдеры без мешлетов. Обычные меши так же подходят. Просто Nvidia демонстрирует, что вы имеете прямой доступ к геометрии и показывает свой подход. Это не обязательно, это просто пример от Nvidia. Вы же не ждали на презентации пустой шейдер, который ничего не делает?
Это хорошее замечание, я умышленно пренебрёг этим моментом, как по мне - это вводит больше непонимания и ложных параллелей. Мешлет - это локальный кусок меша, размером с блок видеокарты. То есть это выровненные данные. У мешлетов даже свойств нет, это просто массив. В то время как, Нанит использует именно иерархию и сложные взаимосвязи с компрессией и т.д. Мешлеты - это не часть меш-шейдеров вовсе, это подход Nvidia к выравниванию данных для оптимизации.
Entirely new system - скорее всего эмуляция mesh-shaders для API < DX12
Mesh-шейдер - это int Main(Polygon Args), я не совсем понимаю, как его можно эмулировать? Это даже в коде не отобразится, это просто декларация. У Mesh-шейдеров нет ни какого разбиения на структуру или иерархии. Голый меш-шейдер даже в теории не может рендерить что-то структурное.
Как я понял, вы сравниваете готовую технологию (с лодами, стримингом, куллингом, компрессией & etc.) и отдельные высказывания от мира Unity.
Нет, я сравнивал Нанит с тем, что ему приписывают. Его называют - кастомным меш-шейдером, но меш-шейдеры доступны любому разработчику, они подключаются в 5 строк кода, но они не делают ничего подобного, что делает Нанит. У вас просто эмпирический на выходе не будет Нанита. Как Нанит может быть меш-шейдером, если меш-шейдер не умеет делать то, что делает Нанит?
Я имел ввиду условный Люмен, там есть множество технологий те же Virtual Shadow Maps - очень прожорливые, они делаю работу с тенями очень простыми, снимая весь геморрой, но стоят они столько... Нанит имеет ограничения, на старых видеокартах - минимальная база, которая требуется для старта съедает прилично, и именно, на старых видеокартах, хотя новые, даже менее производительные - проблем не чувствуют совсем. Опять же, после короны, многие развитые страны быстро и массово обновились до железа последнего поколения, а как известно проблемы индейцев - шерифа не волнуют.
Суд с эпл был ещё до появления UE5, и даже тогда представленные данные, были ретроспективными с лагом в пару лет. Те данные на которые вы ссылаетесь - это показатели 2019 года. Все эти акции с Нанитами и Люменом - очень хорошо продали движок, а реальные отчисления с него, Эпики начали получать всего только год назад, когда проекты увидели релиз.
С такими бюджетами и уже наработанными технологиями, даже если они закроют разработку вообще, они ещё года 3 проедать заработанное будут. Как говорится too big to fail.
В теории, можно предпринять меры по увеличению отчислений, конкретно политика, которую выдвинули Юнити - ровно так же убийственна и для Анриала, после такого, они бы очень сильно убавили в росте. Хотя, он навряд ли бы кончился, учитывая клиентуру, конкретно, Анриала. Можно начать увольнять разработчиков, и повышать отчисления, убрать бесплатный доступ. Но даже когда у Анриала были все эти недостатки в прошлом, он всё ещё был прибыльным и развивался. Всегда будет дешевле купить, даже дорогой Анриал, чем писать свой движок, если вам нужно, что-то более-менее мощное. Анриал после такого, может, разве что, сдать позиции в пользу Юнити.
Просто напоминаю, гонка игровых движков существует относительно не так долго, когда-то она существовала на заре игровой индустрии в 90-х и начале 2000-х, и потом, во второй половине десятых, с появлением Юнити и только с 4 версии Анриала, движки начали вообще хоть куда-то двигаться. Поэтому в этой индустрии - не обязательно стараться как Анриал, но если кто-то старается, то он точно заберёт у вас клиентов. В этом по сути и заключалась стратегия Юнити. Ни кто не знал, что выкатят Эпики, вообще ни кто.
Алексей Макаренков уже рассказывал об это нюансе. Просто могу, сославшись на него, повторить, что как правило, разработчики стараются включать Lumen - аналог трассировки. Но большая часть проектов, либо ещё не ушла с предыдущей версии, либо не так давно перешла на текущую.
По поводу финансов - знаю куда больше. Подразделение разработки движка - очень прибыльное, настолько, что если фортнайт просто исчезнет, Epic и дальше сможет не только существовать, но и расти. С ними прям всё слишком хорошо. Одна только Microsoft имеет с ними эксклюзивный договор, и почти всё, что они делают - выпускается на анриале. Крупные студии - это молочная корова для эпиков. На данный момент с одних только отчислений за движок, эпики могут позволить финансирование всех своих текущих проектов, включая форточку. Поэтому форточка на самом деле приносит ещё больше денег, чем представлялось до этого.
Они на самом деле есть, но я оставил эту информацию для раздела про шейдеры, мне просто было нужно заострить внимания на фокусах и в расследовательском формате потом уже пояснить, где на самом деле всё спрятано. Про одни текстуры можно статью написать, но она выйдет техничной и скучной, в формате справочника. У локаций есть даже множители для того же Specular. Шейдеры, в нашем случае, наиболее информативны и будет в разы интереснее. Для меня самый большой вопрос, почему объекты в Скайриме выглядят очень похоже, даже если накатывать 4K текстуры.
Спасибо, за ваше мнение.
Для этого сначала придётся пояснить, что такое EarlyZ, потом что такое сам Z-Prepass, потом особенности реализации в Скайриме, потом что они используют его неправильно. Это всё будет в следующей части. На данный момент, чтобы никого не путать, достаточно обобщения.
Насколько я понял, он был вырезан на консолях (кроме скайбокса), так же рекомендации по оптимизации тех лет, прямо рекомендуют выключать всё, кроме неба. Раньше и планарные отражения использовали, это не значит, что это дёшево.
SSAO действительно создаётся на стадии пост-обработки, после основного рендера, так как для SSAO требуются итоговые нормали в экранном пространстве.
Поправил, для лучшего понимания
Это не так, стадия маркирования проходит через ссылки с построением графа. Так как объект доступен по ссылке, то все ссылки внутри тоже будут распознаны. Проход по управляемой кучи будет уже на стадии планирования, но нам она и не нужна.
Либо промо закончится, и бесплатной опять будет только 3.5
Должен, GC берёт ссылки из полей корней, данные где расположены ссылки берутся из мета-информации, которую поставляет таблица методов. В искусственном объекте есть таблица методов с корректной мета-информацией, значит GC распознает ссылки, так же все отметки достижимости и закрепления хранятся в самом объекте, и тоже будут валидны. Но сам объект должен иметь внешние ссылки, чтобы GC его вообще видел или быть закреплённым. Однако, GC ещё занимается планированием кучи, и может посчитать, что объект находится в куче и ложно копировать его при уплотнении, поэтому всегда стоит использовать закрепление. В простом случае, можно использовать класс обёртку, который автоматический убирает закрепление при финализации объекта. Я не уверен, что GC обязательно попытается его скопировать, но он однозначно распознает ссылки внутри. Этот метод описан достаточно давно и сборка мусора не вызывает ни каких повреждений. Правда, все ситуации синтетические.
Лично мне интересно попробовать использовать этот метод для более тщательной разметки памяти.
Построение графа зависимостей подразумевает, что экземпляр может быть в других кучах или вообще залочен в неуправляемой памяти, поэтому все поля будут валидны и не собраны, более того, ссылка на сам объект будет учитываться в поколении. Однако, не факт, что будет вызван финализатор или IDispose, так как для них требуется сначала перепланировка кучи, поэтому следует использовать IDispose интерфейс во внешнем классе для связи с GC. И так же пинить сам объект, чтобы исключить ошибки планировщика кучи при попытке перераспределить память.
Какая хорошая техническая статья, на самом деле весь интероп огромная боль, а GC вообще необузданный монстр. Каждый раз при попытке хоть как-то контролировать освобождение памяти вылазит просто уйма нюансов и костылей в виде ObjectPooling. А здесь даже мимикрия под настоящий класс, ну просто красота.
Смысл здесь логический, так как классы управляемые, objectHeader - это как раз обёртка, а по указателю что должно лежать? правильно мякотка, и никому кроме обработчика в частных случаях обёртка не нужна. Да и регулярно добавлять +8 к любому обращению к классу, который в жизни обработкой заниматься не будет - такое себе. В то время как та же таблица методов уже является частью реализации и жертвой постоянных обращений от всех владельцев ссылки.
Тег "криптография" к чему? слово прикольное? похоже на "криптовалюта"?
Какой ещё гиперзвук у амеров не получился? Что там Китай быстрее освоил? США хотели себе атмосферные глайдеры, с гиперзвуком в 21 число маха. 5-7 махов, на которых летают ракеты РФ, у амеров были ещё на первых тестовых испытаниях. А в концепции, просто, гиперзвуковых ракет - они не верят, и забраковали их ещё при исследованиях в 80-х. Как показывает практика - не зря, потому как центральной идеей РФ была идея хоть как-то попытаться пробиться через глобальную систему ПРО стран НАТО. По итогу одиночные мобильные базовые версии установок, перехватывают все эти золотые ракеты. Что там говорить об эшелонированной обороне и разведке. Получились просто быстрые ракеты, только очень дорогие. По остальным параметрам эти ракеты ни чем не лучше стандартных. США не могут позволить себе так бессовестно пилить бюджет.
Отношение экземпляров к количеству полигонов - это условность, конкретно технологии, Nanite. Смысл, скорее, в итоговом количестве в 4 млрд. полигонов. По тестам Эпиков, современные видеокарты падают на количестве 300-350 млн. полигонов. Софтверный рендер обходит это ограничение. По итогу, вам всё же требуется закрасить, всего, 8 млн. пикселей для 4K монитора. В демонстрации, Эпики показывали как Нанит режет исходные триллионы до, всего 20 млн., вызываемых для отрисовки, полигонов на кадр.
Обо всём на свете и ни о чём конкретно. Я не касался всего рендера, я рассмотрел конкретную часть.
Вы имеете ввиду, софтверный рендер?
Для одного, только, Z-буфера вам потребуется 8 мб кэша на FullHD разрешении. У 3090 на борту 6 мб. В большинстве производительных карт от 2 до 4 мб кэша. Только начиная с последнего поколения видеокарт Nvidia у вас будет больше 8 мб для Z-буфера.
Поэтому ни какого "хардварного ускорения" нету.
Проблемы перерисовки ни как Z-буфером не решаются. Как я уже отмечал, для решения этой проблемы в наше время проводятся исследования, но ни какого решения ни в одном игровом движке, кроме, UE 5 с Нанитами - нету вовсе.
Это уже магия. Использование MaterialID через буфер глубины - это хак, чтобы избежать повторного рендера в буфер трафарета. Z-буфер для этого не предназначен.
Соглашусь, по моим оценка, это буквально единственная серьёзная причина, почему многие остаются на Unity. Писать код на Шарпе значительно проще.
Но могу вас заверить, Unreal Engine использует много обёрток и даже собственный сборщик мусора, чтобы разгрузить программиста, попытки перейти на C++, будут для программиста намного проще.
Извините, не хотел вас подводить, я просто считал, что о нанитах сказано достаточно и без меня
Не совсем, там используется и софтверный, написанный на Cuda и OpenCL, и одновременно классический конвейер. Результаты объединяются, архитектура Unreal Engine - позволяет проворачивать такой трюк. Но ни какой иерархии растеризации нет, вы вероятно перепутали с Иерархичным Буфером Глубины(HZB), который используется для кулинга или вы, вообще, о геометрии.
Нанит производит конвертацию модели, в этот момент можно и выставить качество конвертации. Возможно, я не правильно выразился - Нанит использует уровни детализации для кластеров, но не в привычном понимании, это скорее тесселяция, чем обычные лоды.
Нет, это полностью опционально, вы можете использовать mesh-шейдеры без мешлетов. Обычные меши так же подходят. Просто Nvidia демонстрирует, что вы имеете прямой доступ к геометрии и показывает свой подход. Это не обязательно, это просто пример от Nvidia. Вы же не ждали на презентации пустой шейдер, который ничего не делает?
Это буквально то, что я слышал от других разработчиков, это то, что можно найти под видео. Про это делают видео, каналы миллионники: https://youtu.be/LlnTBmPJklU?t=124&si=7H6cAnFTyh83WxSr
Учитывая, что вы смотрите его на Ютуб, это абсолютно реально - видео.
Это хорошее замечание, я умышленно пренебрёг этим моментом, как по мне - это вводит больше непонимания и ложных параллелей. Мешлет - это локальный кусок меша, размером с блок видеокарты. То есть это выровненные данные. У мешлетов даже свойств нет, это просто массив. В то время как, Нанит использует именно иерархию и сложные взаимосвязи с компрессией и т.д. Мешлеты - это не часть меш-шейдеров вовсе, это подход Nvidia к выравниванию данных для оптимизации.
Mesh-шейдер - это int Main(Polygon Args), я не совсем понимаю, как его можно эмулировать? Это даже в коде не отобразится, это просто декларация. У Mesh-шейдеров нет ни какого разбиения на структуру или иерархии. Голый меш-шейдер даже в теории не может рендерить что-то структурное.
Нет, я сравнивал Нанит с тем, что ему приписывают. Его называют - кастомным меш-шейдером, но меш-шейдеры доступны любому разработчику, они подключаются в 5 строк кода, но они не делают ничего подобного, что делает Нанит. У вас просто эмпирический на выходе не будет Нанита. Как Нанит может быть меш-шейдером, если меш-шейдер не умеет делать то, что делает Нанит?
Я имел ввиду условный Люмен, там есть множество технологий те же Virtual Shadow Maps - очень прожорливые, они делаю работу с тенями очень простыми, снимая весь геморрой, но стоят они столько... Нанит имеет ограничения, на старых видеокартах - минимальная база, которая требуется для старта съедает прилично, и именно, на старых видеокартах, хотя новые, даже менее производительные - проблем не чувствуют совсем. Опять же, после короны, многие развитые страны быстро и массово обновились до железа последнего поколения, а как известно проблемы индейцев - шерифа не волнуют.
Суд с эпл был ещё до появления UE5, и даже тогда представленные данные, были ретроспективными с лагом в пару лет. Те данные на которые вы ссылаетесь - это показатели 2019 года. Все эти акции с Нанитами и Люменом - очень хорошо продали движок, а реальные отчисления с него, Эпики начали получать всего только год назад, когда проекты увидели релиз.
С такими бюджетами и уже наработанными технологиями, даже если они закроют разработку вообще, они ещё года 3 проедать заработанное будут. Как говорится too big to fail.
В теории, можно предпринять меры по увеличению отчислений, конкретно политика, которую выдвинули Юнити - ровно так же убийственна и для Анриала, после такого, они бы очень сильно убавили в росте. Хотя, он навряд ли бы кончился, учитывая клиентуру, конкретно, Анриала. Можно начать увольнять разработчиков, и повышать отчисления, убрать бесплатный доступ. Но даже когда у Анриала были все эти недостатки в прошлом, он всё ещё был прибыльным и развивался. Всегда будет дешевле купить, даже дорогой Анриал, чем писать свой движок, если вам нужно, что-то более-менее мощное. Анриал после такого, может, разве что, сдать позиции в пользу Юнити.
Просто напоминаю, гонка игровых движков существует относительно не так долго, когда-то она существовала на заре игровой индустрии в 90-х и начале 2000-х, и потом, во второй половине десятых, с появлением Юнити и только с 4 версии Анриала, движки начали вообще хоть куда-то двигаться. Поэтому в этой индустрии - не обязательно стараться как Анриал, но если кто-то старается, то он точно заберёт у вас клиентов. В этом по сути и заключалась стратегия Юнити. Ни кто не знал, что выкатят Эпики, вообще ни кто.
Алексей Макаренков уже рассказывал об это нюансе. Просто могу, сославшись на него, повторить, что как правило, разработчики стараются включать Lumen - аналог трассировки. Но большая часть проектов, либо ещё не ушла с предыдущей версии, либо не так давно перешла на текущую.
По поводу финансов - знаю куда больше. Подразделение разработки движка - очень прибыльное, настолько, что если фортнайт просто исчезнет, Epic и дальше сможет не только существовать, но и расти. С ними прям всё слишком хорошо. Одна только Microsoft имеет с ними эксклюзивный договор, и почти всё, что они делают - выпускается на анриале. Крупные студии - это молочная корова для эпиков. На данный момент с одних только отчислений за движок, эпики могут позволить финансирование всех своих текущих проектов, включая форточку. Поэтому форточка на самом деле приносит ещё больше денег, чем представлялось до этого.