Программирование 3D и VR графики.

Программирование, Хакинг, Безопасность, Софт, Железо, а также всё связанное с компьютерами
Аватара пользователя
Андрей
Архитектор
Сообщения: 3799
Зарегистрирован: 06 май 2015, 14:10
Откуда: Чехов
Благодарил (а): 394 раза
Поблагодарили: 246 раз

Re: Программирование 3D и VR графики.

Сообщение Андрей » 05 окт 2018, 11:07

VR, ответы на вопросы, которые вы забыли задать. Факты кратко.

https://overclockers.ru/blog/Cool-n-Qui ... byli_zadat
Конец жизни – это начало жизни где-то,
Ничто не появляется из ниоткуда, даже планеты.
И мы летим вперёд, доверившись Божественным вёслам,
Не бойся будущего, не жалей о прошлом.

BDK
Сообщения: 2808
Зарегистрирован: 17 май 2015, 23:27
Откуда: Беларусь
Благодарил (а): 110 раз
Поблагодарили: 310 раз

Re: Программирование 3D и VR графики.

Сообщение BDK » 05 окт 2018, 15:15

Про разрешение не согласен - мне вполне достаточно. Во всяком случае это не является какой-то проблемой которая постоянно бы обращала на себя внимание - ну да при первом опыте бросается в глаза что меньше чем на уже привычных фулл хд мониторах, но потом быстро об этом забываешь - на самом деле в первые квейк и Дюк нюкем играли на меньшем разрешении и чувствовали себя нормально. В общем моё мнение - разрешения вполне достаточно для вполне комфортного погружения в VR. Хотя дальнейший рост разрешения конечно же приветствуется.

Про непереносимость, опять же мое личное мнение - у меня не возникло никаких проблем. Ну поначалу был некоторый период адаптации но позже вообще перестал замечать хоть какой-то малейший дискомфорт от VR. Могу играть в VR часами, вообще без каких либо последствий (если конечно найду столько времени на игры)

Насчёт того что нет пока игр - здесь согласен полностью. Но меня интересует скорей как разработчика этих самых игр - нету значит сделаем. Вернее не столько игр сколько вообще контент - предполагаю делать сам для себя . Мне это интересней чем тупо играть в игры. Для меня это способ погулять в другом мире - абстрагироваться от реального мира.

Мне например был бы интересен симулятор прогулки по лесу. То есть обычные игры типа стрелялки или стратегии в VR наверное нет смысла переносить. VR для другого - основная суть именно погружение в виртуальный мир, то есть игры скорей атмосферного типа - большие пространства и миры. И кстати - ограниченные локации в VR воспринимаются очень плохо - если на мониторе ещё куда ни шло то в VR буквально давит теснота и ограниченность малых локаций - VR нужен исключительно для больших пространств и миров, что требует соответственных графических движков. Или даже не так, я не совсем верно выразился - на самом деле например подземелья с темными узкими пещерами и тоннелями в VR воспринимаются очень круто, но сама сеть пещер должна быть обширной а так же с возможностью выхода на открытые пространства - то есть должно быть полное впечатление большого "реального" мира. Малые локации которые полностью обходишь за несколько минут в VR не годятся - как только обошел всю локацию и понял что никаких других мест кроме тех что обошел больше нет - тут же теряется ощущение "реального " мира. То есть я думаю VR исключительно для игр с большими мирами. Обычные типы игр годятся плохо.

Я кстати как раз разрабатываю движок для больших миров с процедурным наполнением (потому что иначе ни в какую память не поместится, особенно если речь о смартфоне).

BDK
Сообщения: 2808
Зарегистрирован: 17 май 2015, 23:27
Откуда: Беларусь
Благодарил (а): 110 раз
Поблагодарили: 310 раз

Re: Программирование 3D и VR графики.

Сообщение BDK » 05 окт 2018, 15:56

Я вот понял такую вещь - VR в основном даёт воздействие в виде "пространственных" впечатлений, а чисто графические и цветовые аспекты как в традиционной игровой графике отходят на второй план - то есть на самом деле графика в VR не так важна - больше важна геометрия, детали геометрии. Но например на фотореализме и освещении можно сэкономить - это не играет в VR такой большой роли как в обычной 3D графике. Ну во всяком случае это моё такое субъективное мнение. Даже простенькая в графическом смысле игра даёт весь спектр впечатлений от погружения, но вот если сам мир убогий как пространственная локация - это портит всё впечатление.

Это подтверждается сравнением опытов на смартфоне и на крутой Htc vive. Даже не только я но и другие отметили что впечатления очень схожие. Хотя графика на компе конечно не в пример более мощная чем на смартфоне. Но в VR именно чисто графические аспекты как-то нивелируются и не дают сильного вклада в общее впечатление.

По субъективным впечатлениям и дорогущая htc vive за 900 баксов и дешёвая виртуальная реальность на базе смартфона дают схожие впечатления.

BDK
Сообщения: 2808
Зарегистрирован: 17 май 2015, 23:27
Откуда: Беларусь
Благодарил (а): 110 раз
Поблагодарили: 310 раз

Re: Программирование 3D и VR графики.

Сообщение BDK » 12 янв 2019, 11:09

У меня созрел собственный графический движок на базе трассировки лучей. Вообще начал я еще около года назад. Но примерно тогда же мне на глаза попался Unity, и взвешивая что лучше - использовать Unity или развивать свой - я тогда решил что проще будет начать с Unity. И примерно на год я стал фанатом Unity.

Однако поработав в Unity я столкнулся с крушением многих иллюзий насчет его крутости. В частности оказалось не так просто сделать в Unity отображение больших ландшафтов с хорошо детализированными сценами на больших пространствах. Всё начинает нещадно тормозить уже на относительно небольших сценах а оптимизация сцен в Unity это те еще танцы с бубном.

И в итоге я вернулся к своему движку. Достал те исходники из пыльного архива, запустил и был восхищен! И удивлен, как так вышло что такую классную вещь я забросил на целый год!

Короче сейчас я сделал радикальный разворот в своей стратегии и решил всё таки развивать свой движок а не использовать Unity. А Unity спасибо - они мне подсказали много ценных идей насчет маркетинга и продвижения графического движка - я собираюсь кое что перенять у них - то есть хочу выпустить свой движок в люди, с созданием сообщества и обменом контентом (скрипты, сцены, проекты и т.д. и т.п.)


Так вот, начал я свой движок еще около года назад.
Тогда был написан алгоритм трассировки лучей для GPU и всё заработало вполне шустро - в окошке 1024x512 частота кадров порядка 500 FPS (местами до 700). Частота кадров падает пропорционально закрашиваемой площади - то есть если увеличить окошко она снизится. Это отличает от классических движков где разрешение на FPS влияет слабо. Но в моем другая фишка, на мой взгляд более ценная - размер и сложность сцены на FPS влияет слабо. Можно рисовать гигантские пространства - например ландшафтные сцены, с лесами и полями до горизонтов и городами и т.д. и т.п. И всё это в огромной детализации - при этом имея почти те же 500 FPS в таком окошке.

Основное ноу-хау заключается в том как мне удалось всего в 2Гб памяти видеокарты вмещать такие гигантские сцены с хорошей детализацией (используется определенное "сжатие" можно так сказать если не уточнять).

Еще одно ценное свойство моего движка - полная модифицируемость сцен в реальном времени. Не нужно подготавливать сцены в предвариетельном долгом процессе, можно рисовать сцену и сразу видеть её отображение в полном качестве - без всяких пререндеров карт освещения, оптимизаций сцены и т.д. и т.п.

Насчет освещения - используется модель освещения вычисляемого прямо в процессе рендера - то есть никакие заранее отрендеренные карты освещения не используются. Это очень важный момент поскольку карты освещения в классических движках занимают очень много места в памяти и их подготовка занимает многие часы и сутки вычислений. В моем же движке карты освещений отсутствуют в принципе, то есть занимаемое ими место равно нулю и затрачиваемое время на их создание равно нулю :)

Вместо этого освещение вычисляется прямо на лету в процессе рендера, разумеется полностью динамическое.

Но конечно надо понимать что фотореалистичное освещение потребовало бы слишком уж массивных вычислений при рендеринге поэтому пришлось отказаться от полной трассирровки всех отражений и попытки создания полностью фотореалистичного освещения. Вместо этого я пришел к более упрощенной модели освещения, очень схожей со классическими подходами, использованием шейдеров и т.д. и т.п. Но есть и существенные отличия от классического подхода. Перечислю их:

1. Отражения.
В моем движке они делаются легко и просто - для этого не нужно как-то специально подготавливать сцену, отражения никак не сказываются на вычислительных затратах - хоть все поверхности в сцене сделать отражающими. Всё отражается динамически, в реальном времени - без всяких созданных заранее карт отражения.

2.Преломления.
В классических движках это вообще никак не реализовано. В моем же это так же элементарно как и отражения - то есть допустим стеклянная ваза будет не просто полупрозрачной но и свет проходящий через неё преломится с учетом точной физической модели - то есть картинка позади вазы соответствующим образом исказится - как это и происходит в реальности. Или допустим вода в бассейне - когда в реальности смотришь то дно бассейна кажется ближе а волны его искажают и искривляют. В классических движках ничего подобного мы не увидим, а вот мой отображает эту ситуацию без проблем.

3.Динамические тени от всех источников света.
В классических движках обычно используется динамическая прорисовка теней от единственного глобального источника света. Все остальные тени статически пререндерены в карты теней. В моем движке все тени динамические, заранее пререндереных нет в принципе.

4.Глобальное освещение.
Это всё что связано с переотражениями света от множества поверхностей что дает мягкие тени, в отличие от четких теней которые получаются от прямого освещения источником света. В моем движке частично реализованы методы дающие приближенный просчет глобального освещения. Конечно это не то же самое как честный и полный расчет глобального освещения и это не фотореалистичный результат. Но полный расчет глобального освещения всё еще слишком тяжелая задача для современных вычислительных ресурсов имеющихся в распоряжении среднестатистического геймера. Поэтому отказаться от полного расчета глобального освещения в пользу более упрощенной схемы это вынужденная мера чтобы получить приемлемую производительность рендера. Тем не менее это выглядит не хуже чем в классических движках пререндеренные карты освещения. В основном выглядит не хуже чем освещение в том же Unity, Unreal Engine и подобных. То есть в общем и целом глобальное освещение смотрится на уровне с другими движками при том что вычисляется в реальном времени и не требует пререндеренных сцен и связанных с этим затратами памяти. А так же всё это является полностью динамическим - то есть изменение сцены тут же ведет к изменению всего освещения - то есть допустим если комната освещена светом из окна и напротив окна станет какой нибудь персонаж закрывая окно своими широкими плечами - комната погрузится в полумрак, как это и должно быть в реальности. И т.д. и т.п.


Вернуться в «КОМПЬЮТЕРЫ»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 0 гостей