Абсолютно идентичное первое восприятие при сравнении картинок возникло и у меня. Для многоцветных картинок, конечно, требуется разрешение хотя бы вдвое большее по X и Y чтобы хоть как-то контуры обозначить.
Например, берем вартандер. Садимся в самолет, играя в танковые бои (тоесть на картах для танков) и где-то с высоты 1-1.5км внизу все полигоны начинают скакать, углубления превращаются в плоскость, гладкие оъекты в острые и т.д. Танки при этом рисуются нормально, но они скрываются под этой «кашей» так что их становится не видно. Я очень сомневаюсь, что вартандеровские карты целиком имеют еще какой-то LOD кроме начального…
А я вот очень хочу чтобы в играх уже наконец-то начали использовать FP64, по крайней мере в вертексных шейдерах, потому что надоело видеть как удаленные объекты (меши) превращаются в кашу. И это не какая-то оптимизация отрисовки, это именно нехватка точности расчетов.
Про 4k и DLSS… Ну вот у меня монитор 28" и 4k… я практически везде в играх ставлю FXAA. Он так же фактически не влияет на производительность. Да и в 4k пиксели уже очень маленькие, что лесенки заметны лишь на каких-то совсем тонких объектах, типа провода, антенны и подобном. Зачем нужен ещё один режим скглаживания мне трудно понять. Если бы кто-то выложил 2 скриншота DLSS vs FXAA в 4k был бы признателен.
А вообще все эти пространства цветов 4:2:0, 4:4:4 и — это такой архаизм и тянется из глубин веков, что прям ужас. Напридумано их прям немеряно просто. Всё уже должно быть в честных 30-48 битах на пиксель — обычный RGB 10:10:10 progressive, а с заделом на будущее уж сразу 16:16:16… Каналы передачи данных уже давно готовы к этому, да и особой разницы в передаче сжатого сигнала полноценного rgb 10:10:10 и какого-нибудь yuv 4:2:0 прям существенного нет. Ведь единственное для чего их придумали это уменьшение объема передаваемых данных с потерей качества еще без сжатия.
Не проще ли вместо всевозможных hand-brake, отдельных h265 и 264 тестировать всё в ffmpeg, явно указывая -threads 20, 32, 64 по количеству реальных потоков? Или например -s 3840x2160 -c:v libx264 -crf 20 -pix_fmt yuv420p10le -threads 32… Иначе вообще не понятно сколько в итоге реально использовалось потоков. После того как хотя бы чуть-чуть освоишь параметры ffmpeg, уже просто никакие навесные (вечно глючащие гуи) просто не нужны. А там хочешь хоть общее время кодирования выводи, хоть fps кодирования.
Грубо говоря, если игра выдает 240 кадров и 240 раз в секунду опрашивает клавиатуру/мышь. То на экране то мы видим только 60 из этих кадров, это 1 из 4х кадров и 1 из 4х опросов устройств ввода, притом, что этот кадр абсолютно такой же как и кадр нарисованный с синхронизацией. И башня повернута на столько же градусов. Ну я не спорю могут быть какие-то погрешности, но не такие о которых вы говорите. Сам монитор так же может давать значительную задержку при отрисовке им кадра, как и видеокарта на выходе, но это уже железный вопрос, а не софтовый. И ВК не будет пихать в монитор 240 кадров, это будут все те же 60 кадров. Ни стандартные HDMI ни DP не способны передавать 240 кадров/сек, ни FHD, ни особенно 4k.
Хорошо, у нас есть заранее неправильно спроектированная игра с SDL-like вводом, это когда основной цикл игры выглядит так:
1. информация о вводе
2. отрисовка кадра и sleep
3. goto 1
При всем при этом отрисовка кадра игры синхронизируется не по sleep а по неким внутренним счетчикам, ну то есть на сколько градусов надо повернуть скажем башню, за кадр (важно). При этом каждый кадр с синхронизацией остается актуальный для каждого ввода.
Теперь тоже самое без синхронизации, имеется внутренний счетчик времени, кадров рисуется до одурения много и опросов ввода так же много, но актуальных кадров (которые мы видим на мониторе) ровно столько же, кажем 60, т.к. монитор больше не умеет, и угол поворота башни будет ровно таким же как без синхронизации. Просто в одном случае мы спали, в другом были заняты рисованием «невидимого кадра» от «ненужного» ввода. Так и в чем разница? Ну вводов больше, кадров больше, актуальных кадров и актуальных вводов ровно столько же.
Потрудитесь объяснить с технической точки зрения каким образом «v-sync значительно увеличивает задержку ввода». Ну то есть имеется некая sleep(10ms) после рисования очередного кадра, во время которой по прежнему обрабатывается ввод и вывод и вообще всё что можно, но только не рисуется картинка. Каким образом sleep влияет на задержку ввода?
Зачем рисовать больше кадров, чтобы часть из них «оставить на v-sync»??? Когда вместо рисования можно просто «поспать» ровно столько же времени сколько рисуется еще один кадр… Я тут чуть ладонью лоб не пробил… v-sync он на то и существует, чтобы рисовать столько же кадров, сколько умеет показывать отображающее устройство, читай монитор.
Вообще экран спекки можно представить и как линейное пространство 2048х24 пикселей. Ну или 256х3 знакоместа (которые в свою очередь 8х8 пикселей). Интересно, но этот DOWN_HL я почти до сих пор помню наизусть, т.к. это важнейшая часть рисования спрайтов, а особенно «указателя мышки» в любой программке для спекки. Ну и вторая важнейшая часть это от 65000 до 72000 тактов за которые надо успеть сделать всё… Как же я тогда мечтал о 7 или еще лучше о 14 МГц…
Кадр YouTube видеоролика 360 градусов надо натянуть на Cubemap, чтобы отрисовать fisheye картинку. Раньше, когда YouTube использовал equirectangular проекцию для видео 360, я без проблем конвертил ее во фрагментном шейдере сразу в fisheye. Сейчас они используют Equi-Angular Cubemap почти во всех роликах. Соответственно для того чтобы отобразить fisheye, я сначала преобразую каждую грань Equi-Angular Cubemap в грань обычного Cubemap, и только затем отрисовываю fisheye картинку. Это 6 + 1 вызовов на отрисовку. Соответственно было бы круто вообще в одном шейдере взять ютюбовский Equi-Angular Cubemap и загнать его с соответствующими преобразованиями сразу в обычную Cubemap текстуру. Про геометрический шейдер упомянул, поскольку наверное понадобится использовать Layer в шейдере для Cubemap текстуры.
Кто-нибудь ткните носом пожалуйста, как в один проход обернуть qubemap пусть даже в плоскую текстуру. Пусть даже каждая грань кубика будет в этой плоской текстуре. Понимаю, что надо юзать геометрический шейдер, но руки никак не доходят разобраться. С одной стороны вроде как GL — это древнейший и всевозможно описанный где только можно API, но с другой стороны когда начинаешь что-то искать — одна половина найденного уже depricated, одна под 2.0+ и малюсенький процент под 3.3+ и вообще мизер под 4+
Статья и перевод просто шикарны! Спасибо! Сам когда очень давно начинал в GL долго не мог понять, почему замер скорости участка кода рисования вместе в glFinish + SwapBuffers дает ~16ms вместо положенных ~60-100 микросекунд, если измерять без этих команд. Но, как оказывается, и эти 60-100 микросекунд — обман на самом деле.
Кстати у меня иногда проскакивает «статтер» и на правильном плавном видео, благо только 1 на весь ролик.
Ну оно в части deprecated так приблизительно и происходит. Только вместо deprecated пишут новый вариант как допустимый. Например, у всеми любимого кофе уже давненько допустим средний род. В словарях от 2012 года либо стоит как «м. и с.», либо «м. и с. (разг.)» Думается, что достаточно много времени пройдет, прежде чем кофе сделается среднего рода, т.к. тенденция к этому есть. Ведь никто уже не говорит кофей или кофий.
В данный момент оно и используется, но есть много НО… использование SDL (для меня это минус), отсутствие аппаратного воспроизведения на любой видеокарте, очень сильно отстает товарищ от самого ffmpeg по версионности, оно и понятно портировать вагон заголовочных файлов с C++ на Delphi — то ещё удовольствие. Проще действительно писать ядро на C++ не портируя вообще ничего, а гуй на Delphi. Пока обходимся 4096x4096@60fps h264 на процессоре, но в планах 8х8k hevc main, паскали такое умеют аппаратно, правда вроде только 30fps. Очень надеюсь, что тьюринги смогут и 60fps для 8x8k. Перебросить текстуры из DX в GL — не проблема. Пока декодер софтварный, а стриминг текстур, нужные преобразования и отображение — OpenGL (GLSL) (возможно будет Vulkan, и поддержка Linux). Хочется отвязаться от SDL и его потоков и написать простое, своё, без кучи лишних вреймворков и библиотек, ну кроме ffmpeg, разумеется.
Если интересно, это плеер для планетариев (одно- и много-проекторные системы)
Всё что здесь описано так же подходит и для других ЯП… Как раз есть задумка писать ядро видеоплеера с ffmpeg на С++ и работать с ним через интерфейсы в Delphi.
Согласен. «Крутизна» графики, что в юнити, что в анриале никак не привязаны к самому движку и зависят только от количества, качества и крутизны шейдеров. Разве что можно посмотреть только где проще и удобнее работать с самими материалами в самом редакторе и какой из них позволяет проще «воротить» графику не углубляясь в дебри программирования.
Ну собственно в Delphi это и сейчас никуда не делось. В UI треде желательно вообще быстренько обрабатывать только местные события. Но Delphi в упрощении этого добра уже шагнул далеко. Те же TTask, TParallel, TThread и прочее значительно упрощают жизнь. Ну а по поводу Unity… я не понимаю и не приемлю языки, которые не превращаются после компиляции в минимальный и быстрый машинный код, не содержащий никаких оверхедов. Такая неприязнь, наверное еще со времен, когда писал свой Scortched Earth на спектруме используя бейсик для механики+ассемблер для всех эффектов. Сейчас мне это очень напоминает Android NDK…
Про 4k и DLSS… Ну вот у меня монитор 28" и 4k… я практически везде в играх ставлю FXAA. Он так же фактически не влияет на производительность. Да и в 4k пиксели уже очень маленькие, что лесенки заметны лишь на каких-то совсем тонких объектах, типа провода, антенны и подобном. Зачем нужен ещё один режим скглаживания мне трудно понять. Если бы кто-то выложил 2 скриншота DLSS vs FXAA в 4k был бы признателен.
1. информация о вводе
2. отрисовка кадра и sleep
3. goto 1
При всем при этом отрисовка кадра игры синхронизируется не по sleep а по неким внутренним счетчикам, ну то есть на сколько градусов надо повернуть скажем башню, за кадр (важно). При этом каждый кадр с синхронизацией остается актуальный для каждого ввода.
Теперь тоже самое без синхронизации, имеется внутренний счетчик времени, кадров рисуется до одурения много и опросов ввода так же много, но актуальных кадров (которые мы видим на мониторе) ровно столько же, кажем 60, т.к. монитор больше не умеет, и угол поворота башни будет ровно таким же как без синхронизации. Просто в одном случае мы спали, в другом были заняты рисованием «невидимого кадра» от «ненужного» ввода. Так и в чем разница? Ну вводов больше, кадров больше, актуальных кадров и актуальных вводов ровно столько же.
Кстати у меня иногда проскакивает «статтер» и на правильном плавном видео, благо только 1 на весь ролик.
Если интересно, это плеер для планетариев (одно- и много-проекторные системы)