Ждём Ваших отзывов о материале.

Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
За статью можно проголосовать на странице материала.

Напоминаем о том, что на сообщения новых участников распространяется действие системы премодерации сообщений.

О нарушениях можно сообщить модератору, нажав синюю кнопку #77 справа над спорным сообщением.

Второй вариант выглядит реалистичней.

Сча загуглил, соня вроде ожидает продажи на уровне 2,6 млн в течении года. В общем чего ожидать не знает никто

Вангую: повторит судьбу кинект. Продадут шлемов много. Поначалу даже будет достаточно примитивных игр с графикой как на ps1 (или почти как на ps2, если поменять мыловарню на pro-версию). За год всем надоест, и потихоньку все умрет.

В минимальных требованиях к Oculus нынче значится GTX 960. А что там в консолях - встроенный аналог 7850.

H_Rush только играть не во что на окулюсе.

Это они глядя на свою "популярность" решили, что вместо 90 кадров можно рендерить 45, а между ними достраивать промежуточные.
Только тот, кто это придумал, забыл о том, почему вообще надо 90 кадров. Дело то не в плавности картинки, а задержке ввода, т.е. цель не в 90 кадрах, это только следствие. А задержка тут будет даже выше по сравнению с обычными 45 кадрами, т.к. к моменту рисования промежуточного кадра нужно уже иметь готовым реальный следующий (иначе с чем усреднять?). Таким образом появление реального (отрендеренного) следующего кадра откладывается во времени минимум на 11 ms (1000/90) + время на пострение промежуточного недокадра. Таким вот нехитрым образом 45 кадров с дорисовкой до 90 по задержке ввода плавно превращаются в аналог честных 20fps. Буду сильно удивлен, если там никого не вырвет с новой чудо-фичей.

4e_alex Вы плохо ознакомились с принципом работы ATW и ASW. При работе ASW, задержка положения шлема будет на уровне 90 фпс, но задержка перемещения объектов в виртуальном мире будет на уровне 45 фпс, это будет примерно похоже на мультиплеерную игру с 90 фпс, но тикрейтом сервера 45. И не надо сравнивать 90 фпс на мониторе и 90 фпс в шлеме. В шлеме эти 90 фпс будут с более низкой задержкой по двум причинам. Во первых, за 2 мс до отправки изображения в шлем, геометрия картинки меняется исходя из текущего положения шлема. Во вторых, VR игры используют другой метод редеринга, который уменьшает лаг. 144 фпс на мониторе будут иметь гораздо больший лаг чем 90 фпс в шлеме.

Vansground

Не надо вот этих фантазий. Задержка видимой картинки будет намного выше, чем при честных 45fps, т.к. как минимум на половину времени кадра (отсюда и 1000/90) надо ВСЕ кадры сдвигать назад по времени.
Избежать этого (и вернуть лаг до уровня 45fps, что нефига не оптимально и просто ставит под сомнение смысл всех потуг) можно только, если вовсе даже и не строить средний кадр на основе двух, а изобрести машину времени или угадывать следующий кадр по истории предыдущих. Во втором случае будет просто офигенный эффект, если пользователь начнет мотать камерой хаотично.

Нет, это будет похоже на говно.

Бред. Кто заново весь кадр строит по новой геометрии за эти 2ms? Встроенный в шлем Titan X Pascal SLI?
Никто. Пользователь видит старую картинку, инпут лаг все там же - давно пробил крышу.

Все отличия со стороны драйвера - это принудительное снижение количества предварительно заготовленных на CPU кадров до 1 (впрочем, это меняется прямо в панели управления, и при желании включатся вообще на все игры). Какими уловками пользуется игра - это уже черный ящик. В любом случае у современных игр собственный лаг движка обычно очень низкий. А на создателей VR-игрулек не могло снизойти озарение, принципиально недоступное всем остальным.

Фантазируете здесь вы. ASW не строит средний кадр на основе двух. Сначала ознакомьтесь что такое ASW и ATW, прежде чем писать этот бред.

На слайдах из презентахи именно так показано.
А вот тут вообще не объясняется алгоритм построения "synthetic frame"

Если для него не нужен следующий кадр, то как он его строит по-твоему?

Добавлено спустя 13 минут 44 секунды:
http://techreport.com/news/30766/asynch ... ulus-rifts

Явное указание на необходимость наличия двух кадров, а значит их надо сдвигать по времени на половину времени кадра при 45fps, иначе "синтетический кадр" и следующий за ним реальный будут попадать в один момент времени, и на экране будут те же самые 45fps.

А давайте Вы не будете все мешать в кучу. ATW вообще тут никаким боком не относится, он всего-лишь лечит недостатки vsync.

В ATW режиме берется последний отрендеренный кадр и за 2 мс до отправки картинки в шлем меняется геометрия картинки исходя из текущего положения шлема. Вот здесь https://youtu.be/WvtEXMlQQtI?t=689 показано варпнутое изображение с разных ракурсов шлема. Варпнутая картинка может иметь артефакты изображения в случае быстрых перемещений шлема. В реальности таких жестких артефактов как на видео на 11:33 не будет, чтобы сдвинуть шлем на такое расстояние за 11 мс нужно быть супермэном.
В ASW режиме проделывается тоже самое, только из одного кадра делается не 1, а 2 варпа.

Не надо все в кучу мешать. ATW, который появился еще полгода назад, никак не связан с нынешним снижением требований. ATW по большому счету пост-процессингом видоизменяет картинку последнего кадра под новое положение шлема (что-то типа эффекта параллакс-обоев на iphone). О полноценной перестройке геометрии и тем более кадра речи не идет, драйвер работает с 2D-картинкой старого кадра на входе. Тут действительно можно добиться чуть большей видимой плавности при нулевом изменении input lag. К увеличению числа кадров ATW не приводит.
Причиной же снижения требований в 2 раза является анонс ASW.
ASW - отдельная фича с совершенно другим принципом работы. Она берет 2 кадра и строит между ними разницу. ATW компенсирует только дополнительный поворот головы/шлема, который случился за время рендеринга кадра, в то время как ASW компенсирует еще и разницу, возникшую от перемещения в пространстве. Опять же силами пост-процессинга 2D-картинки. Презентаха и большинство источников сходятся на мнении, что исходным материалом служит 2 кадра. Если это так, то ВСЕ кадры надо сдвигать по времени назад на 11ms, значительно увеличивая input lag. Если это не так (нужен только последний кадр), то это чистой воды магия, которая при любом хаотичном движении взад-вперед даст сбой. А инпут лаг все равно не снизит, он так и будет на уровне 45fps.