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

[Андрей]

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

https://overclockers.ru/blog/Cool-n-Qui ... byli_zadat

[BDK]

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

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

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

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

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

[BDK]

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

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

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

[BDK]

У меня созрел собственный графический движок на базе трассировки лучей. Вообще начал я еще около года назад. Но примерно тогда же мне на глаза попался 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 и подобных. То есть в общем и целом глобальное освещение смотрится на уровне с другими движками при том что вычисляется в реальном времени и не требует пререндеренных сцен и связанных с этим затратами памяти. А так же всё это является полностью динамическим - то есть изменение сцены тут же ведет к изменению всего освещения - то есть допустим если комната освещена светом из окна и напротив окна станет какой нибудь персонаж закрывая окно своими широкими плечами - комната погрузится в полумрак, как это и должно быть в реальности. И т.д. и т.п.

[BDK]

Андрей, а как обстоят твои отношения с таким языком программирования как Java?

Я вот начал его осваивать. Переношу свой графический движок на Java. Использую среду разработки Android studio. И как наверное не трудно догадаться - это предназначено для программирования мобильных приложений. Уже попробовал прорисовку на своём смартфоне - отлично работает. Собственно я с самого начала и предполагал этот движок для применения на смартфоне - с очками виртуальной реальности. И теперь я очень близок к реализации этого.

Музыкальную программу я кстати тоже предполагал для смартфона и тоже позже займусь переносом её на Java и дальше буду вести именно в таком формате.

А Delphi я оставляю для себя как язык для предварительного прототипирования и отладки будущих программ и алгоритмов - поскольку он мне за много лет уже очень привычен и мне удобней на нем именно размышлять, экспериментировать и прототипировать, а потом уже переносить это на Java или любой другой язык. Сам процесс переноса занимает мизерное время по сравнению с общим временем разработки поэтому я для себя решил что это целесообразно.

[Андрей]

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

[BDK]

О как. Прикольно. А у нас почему-то очень много вакансий для java программистов. Вот я и надумал его изучать.

А что же тогда сейчас самое популярное вместо java?

https://www.kv.by/post/1049297-skolko-ostalos-zhit-java
https://toster.ru/q/204378
https://www.iphones.ru/iNotes/530137

Вообще Андрей меня в твоем сообщении напрягли два слова "браузер" и "апплет". Хотя я рассматривал язык java без всякого отношения и к тому и к другому. Меня эти вещи не интересуют и не интересовали. Меня интересует есть ли смысл использовать java как мультиплатформенный язык программирования с большим сообществом?

Я имею ввиду есть ли другой мультиплатформенный язык взамен java?

Насчет же того что java удаляют с компьютеров - это вообще не проблема. Сейчас нет никакой трудности откомпилировать java программу в exe-файл и запускать на любом компьютере где удалили java. Пользователь вообще не будет иметь понятия на чём написана твоя программа - для него это просто стандартный exe-файл.