Войти
ПрограммированиеФорумОбщее

Разработка под VR (2 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3 425 Следующая »
#15
6:28, 20 янв. 2021

romanshuvalov
> Кто уже? На чём ведёте разработку, какие успехи?

Ну я программирую для ВР. Года четыре уже. Сначала сделал фришную аппликацию для Oculus Rift, на нативном API (по некоторым причинам использовать движки не представлялось возможным). Прошел весь процесс верификации. Потом на основе полученного опыта написал вторую аппликацию, уже коммерческую. К этому моменту Окулус купил Фейсбук и зарегистрировать игру в Oculus Store стало намного сложнее. Такое чувство что им новые разработки уже не сильно нужны. Пока я с ними бодался решил портировать все на Open VR. Думал на это уйдет месяца три, но все оказалось проще - уже через неделю в основном все заработало. Потом правда пришлось повозиться с настройкой разных контроллеров, но теперь все работает на всех трех платформах. У Стим процесс верификации намного проще, на все ушло недели 2-3. К тому моменту Окулус наконец дал добро и сейчас у меня программа представлена на двух площадках - Oculus Store и Steam. Продается, причем на Стиме раза в 3 больше чем на Окулусе. Сейчас начинаю продумывать новый проект.

Если интересно, могу рассказать всякие нюансы привязки к разным платформам и дать примеры кода. Сам я начинал с примеров из АПИ. Поскольку пишу на DX12 то брал примеры для этой платформы. Вообще начинать проще с Окулуса, там понятнее и заработает быстрее. Потом и OpenVR легче пойдет. Вообще если использовать движки то наверно все можно проще сделать, там поддержка ВР уже включена, но тут я не помогу ибо пишу все по старинке - с нуля и врукопашную.

#16
7:33, 20 янв. 2021

san
> Вообще если использовать движки то наверно все можно проще сделать
Движки слишком медленные для VR. Помню у юнити была рекомендация до 100к треугольников, когда я выводил под млн треугольников)

#17
(Правка: 8:15) 8:00, 20 янв. 2021

/A\
> Движки слишком медленные для VR.
Кто тебе такое сказал? Большинство игр в ВР написаны на Юнити/Анриал. Ничего, справляются. В моем случае движки неприменимы не из-за скорости их работы или моего снобизма, а из-за нестандартной архитектуры самого приложения, когда нужно вычислять крайне тяжёлые шейдера и одновременно обеспечивать 90 фпс. Приходится лезть на низкий уровень и задействовать паралельную работу разных очередей. Большинство игр такого не требуют.

Основная особенность программирования для ВР состоит в постоянном и гарантированном обеспечении скорости рендера картинки в 5 мс (10 мс для обоих глаз). Если в игре для плоского экрана вполне допустимо периодическое падение производительности до 20-30 фпс, то для ВР это невозможный криминал. Но тормозит обычно не движок а возможности железа. Тут нужно искать компромис между сложностью сцены и количеством продаж, поскольку не у всех есть 3090. 

Кстсти у Окулус есть раздражающее требование обеспечить работу аппликации (без проседаний во всех режимах) на GTX 970. Это мне стоило кучу времени и нервов. Но удалось в конце концов пройти и этот фильтр. У Стима такого ограничения нет.

#18
8:20, 20 янв. 2021

san
> Приходится лезть на низкий уровень и задействовать паралельную работу разных очередей.
Раньше без этого обходились, а на мобилках такого еще нет.

> Если в игре для плоского экрана вполне допустимо периодическое падение производительности до 20-30 фпс, то для ВР это криминал.
Если нет резких движений, то встроенная репроекция хорошо сглаживает и 30фпс.

> Большинство игр в ВР написаны на Юнити/Анриал. Ничего, справляются.
Вот кроме битсейбра (который на юнити вроде бы) все остальные уменьшают разрешение, чтоб выдать нормальный фпс, хотя геометрия примитивная, либо жутко тормозят. В общем ВР не для инди.

#19
9:31, 20 янв. 2021

san
> у меня программа представлена на двух площадках - Oculus Store и Steam
Ссылку можно и дать, на нашем форуме за ссылки на свои работы не банят :)

> Если интересно, могу рассказать всякие нюансы привязки к разным платформам
Буду изучать мобильный Окулус, но это потом. Сейчас SteamVR (OpenVR), с ним вроде всё понятно, вот только ДЛЛшка выдаёт Access Violation.

> Поскольку пишу на DX12 то брал примеры для этой платформы.
Этот? https://github.com/ValveSoftware/openvr/tree/master/samples/hellovr_dx12

> пишу все по старинке - с нуля и врукопашную.
У меня тоже всё самописное.

> Кстсти у Окулус есть раздражающее требование обеспечить работу аппликации (без проседаний во всех режимах) на GTX 970
А десктопный магазин Окулуса еще существует? Я слышал, что его вроде как собираются прикрыть и все силы бросить только на мобильные приложения для автономных шлемов Quest.

/A\
> встроенная репроекция хорошо сглаживает и 30фпс.
Это только для крайних случаев, лучше на это не полагаться. То есть если внезапно появилось несколько тяжелых объектов, игрок повернулся к ним и игра не успела снизить разрешение и опоздала к кадру - ок, не страшно. Но делать приложение которое опаздывает вообще всегда и считает это нормой - непорядок. Вот хорошая презентация на эту тему, ей уже 4 года, но все еще актуальна: https://www.youtube.com/watch?v=eIlb688pUu4

#20
9:47, 20 янв. 2021

romanshuvalov
А mingw принципиален?
Ничего не имею против него (тоже пользуюсь), но все таки mingw - это амбициозный хакерский проект, а не нативное средство.

Ты собираешь свой проект из линукс и поэтому не можешь использовать VS?

#21
(Правка: 9:58) 9:55, 20 янв. 2021

cyberpunk2077
> Ты собираешь свой проект из линукс и поэтому не можешь использовать VS?
Да. Вернее, прямо сейчас нет, я в винде, но планирую настроить всё в линуксе, чтобы не было надобности загружать винду. (Правда, из-за виара это пока пока невозможно.)

upd.: Ставлю Visual Studio Community, скомпилирую хелловорлд хотя бы, чтобы знать, виноват Mingw или не виноват.

#22
10:05, 20 янв. 2021

romanshuvalov
> Да
Один момент проясни. Ты ведь не пользуешься wine, а используешь нативный линуксовый мингв?

#23
10:08, 20 янв. 2021

cyberpunk2077
Да, собираюсь использовать нативный мингв. (Поставил, протестировал хелловорлд, но донастроить под свои нужды пока еще не успел, приостановил затею из-за виара.)

#24
10:40, 20 янв. 2021

Поставил VS, собрал тот же пример из готового .sln файла, всё заработало, никаких проблем. Что будет дальше, пока не знаю. Думаю, напишу враппер на С и создам ДЛЛшку средствами VS. А линковаться к ней можно будет уже динамически чем угодно, в моём случае при помощи mingw.

#25
(Правка: 11:40) 11:40, 20 янв. 2021

romanshuvalov
> напишу враппер на С
так С интерфейс там уже есть
https://github.com/ValveSoftware/openvr/blob/master/headers/openvr_capi.h

#26
11:59, 20 янв. 2021

/A\
> так С интерфейс там уже есть
Он странный, автоматически сгенерированный, а функция инициализации вообще обёрнута в #if 0. Как и все остальные. Наверное, предполагается, что я скопирую объявление себе, получу ссылку на реализацию через GetProcAddress, вот только что даст это вызов неясно, документации нет. Вероятно, вернётся указатель на

VR_IVRSystem_FnTable
но это догадки.

san
Кстати, а почему ты пишешь про 5 мс на каждый глаз? Ты рендеришь последовательно? Есть же расширение GL_OVR_multiview (в DX12 не знаю, должно быть похожее), позволяющее рисовать в два глаза одновременно. Это, конечно, не в 2 раза быстрее, но вершинный шейдер будет выполняться параллельно и DrawCall'ов вдвое меньше. Поэтому считать имеет смысл время рендера для обоих глаз одновременно (10 мс) и это время не будет равно сумме длительности рендера в каждый глаз по отдельности.

#27
12:21, 20 янв. 2021

romanshuvalov
Вот у меня пример реализации на С интерфейсе
https://github.com/azhirnov/FrameGraph/blob/dev/extensions/framew… nVRDevice.cpp

#28
12:36, 20 янв. 2021

/A\
Спасибо, поизучаю.

Вся магия, как вижу, вот тут:

_vrSystem = BitCast<IVRSystemTable>( _ovr.GetGenericInterface( ("FnTable:"s << IVRSystem_Version).c_str(), OUT &err ));
Выглядит не очень по-сишному :) Но в Си, как я понял, достаточно просто вместо кастов привести тип через (VR_IVRSystem_FnTable*).

#29
(Правка: 15:06) 14:38, 20 янв. 2021

romanshuvalov
Вот ссылка на Стим (на Окулусе все аналогично) - https://store.steampowered.com/app/1318030/Fractal_Alchemist/

>но планирую настроить всё в линуксе, чтобы не было надобности загружать винду.

Я не понял, у тебя какой хедсет?
И второе - как ты инициализировал OpenVR на Линуксе? Я не знал что есть версия библиотеки для этой платформы.

Разработку для ВР приходится делать постоянно одевая хедсет, невозможно делать это без девайса. Запуск программы начинается с инициализации АПИ и там первым делом проверяется наличие и тип хедсета.

>А десктопный магазин Окулуса еще существует? Я слышал, что его вроде как собираются прикрыть и все силы бросить только на мобильные приложения для автономных шлемов Quest.
Работает и долго будет работать. Квест может запускать приложения для Рифт используя виртуальный десктоп.

>Кстати, а почему ты пишешь про 5 мс на каждый глаз? Ты рендеришь последовательно?
А как можно рендерить параллельно? Ты ведь не сам картинку выводишь, это процесс SteamVR делает. Сначала строится картинка (текстура) для левого глаза, потом для правого. Они передаются API последовательно, двумя колами, там происходит постобработка и собственно вывод. На все про все - 11 мс. В случае Valve Index - 8 мс. (у того 120 Гц)
Ну и 1 мс для страховки. На Рифте я использовал суперсемплинг, но на новых хедсетах с разрешением 2К х 2К на глаз это стало практически невозможно - карты не успевают. Но на таком разрешении и суперсемплинг не нужен.

Страницы: 1 2 3 425 Следующая »
ПрограммированиеФорумОбщее