Технический отличаются максимально, спамеры используют дозвон круглые сутки, операторы отдельно такие звонки через свои API разрешают. Просто так организовать дозвон через IP нельзя, оператор заблочит если ему денюжку не заплатили за такую услугу. Более того, такие звонки часто идут с одноразовых номеров, перезванивать на которые запрещено и генерятся они из пула оператора, и всегда идут от ip-провайдера. То есть если номер официально зарегистрирован за компанией, никакого труда, отличить его от спамера - не составляет.
Мне МТС сказали надо самому подключать услугу блокировки. Поэтому и сорвались, что пул тех кто не подключил - сужается и пытаются заспамить пока есть возможность.
Общение по электронной почте имеет статус официального юридического обмена, тоже самое, что и письма по физической почте отправлять. Намного надёжнее и в суде приравнено.
Отличный закон, он блокирует ip телефонию с одноразовыми номерами с заблокированным обратным вызовом - то есть только спамерские номера. Официальные номера зарегистрированные на организацию под блокировку не попадают. Вы проблему из пальца высасываете. Хотите получать звонки с одноразовых номеров, пожалуйста, услуга опциональная.
Они на самом деле есть, но я оставил эту информацию для раздела про шейдеры, мне просто было нужно заострить внимания на фокусах и в расследовательском формате потом уже пояснить, где на самом деле всё спрятано. Про одни текстуры можно статью написать, но она выйдет техничной и скучной, в формате справочника. У локаций есть даже множители для того же 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. Вы же не ждали на презентации пустой шейдер, который ничего не делает?
Технический отличаются максимально, спамеры используют дозвон круглые сутки, операторы отдельно такие звонки через свои API разрешают. Просто так организовать дозвон через IP нельзя, оператор заблочит если ему денюжку не заплатили за такую услугу. Более того, такие звонки часто идут с одноразовых номеров, перезванивать на которые запрещено и генерятся они из пула оператора, и всегда идут от ip-провайдера. То есть если номер официально зарегистрирован за компанией, никакого труда, отличить его от спамера - не составляет.
Мне МТС сказали надо самому подключать услугу блокировки. Поэтому и сорвались, что пул тех кто не подключил - сужается и пытаются заспамить пока есть возможность.
Общение по электронной почте имеет статус официального юридического обмена, тоже самое, что и письма по физической почте отправлять. Намного надёжнее и в суде приравнено.
Отличный закон, он блокирует ip телефонию с одноразовыми номерами с заблокированным обратным вызовом - то есть только спамерские номера. Официальные номера зарегистрированные на организацию под блокировку не попадают. Вы проблему из пальца высасываете. Хотите получать звонки с одноразовых номеров, пожалуйста, услуга опциональная.
Они на самом деле есть, но я оставил эту информацию для раздела про шейдеры, мне просто было нужно заострить внимания на фокусах и в расследовательском формате потом уже пояснить, где на самом деле всё спрятано. Про одни текстуры можно статью написать, но она выйдет техничной и скучной, в формате справочника. У локаций есть даже множители для того же 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