Віртуальна реальність нерухомості: кейс

Один з наших випускників програми «Менеджмент ігрових інтернет-проектів» працює в команді, яка реалізує проекти у віртуальній реальності. Безпосередньо зараз вони працюють над віртуальним шоурумом.

VR дає можливість забудовнику представити свій асортимент в реальному масштабі з фотореалістичним зображенням, максимально повним відчуттям простору, а також необхідним йому інтерактивом. Сама можливість поглянути на майбутній проект, як на реальний, повною мірою відчути його масштаб і при цьому отримати дивовижні «фішки», наприклад, переміщуватися на далекі відстані, змінювати візуальні і фізичні властивості навколишнього середовища — все це відкриває нові горизонти презентації нерухомості. Під катом ви знайдете розповідь нашого випускника про те, як це все робилося з технічної точки зору.



Початок: Revit VS Unreal
Моделювання квартири спочатку ми виконали в Revit, виходячи із специфіки проекту. Безпосередньо перенесення в Unreal давав моторошну геометрію: «расклеенную» і з незрозумілою топологією. Ми спробували кілька варіантів форматів, плагінів експорту, щоб отримати придатну модель в 3d max'е. Дива не сталося: у перегородки простої прямокутної форми було по 2-3 не склеєних вершини в точці, оверлапы полігонів, зайві ребра, розгорнуті нормалі; у об'єктів з криволінійною поверхнею була щільна сітка. Виправлення геометрії іноді займала стільки часу, що простіше було зробити заново. Тому ми переробили стіновий каркас і меблі в 3d max і використовували ревитовскую геометрію як референс.

Контент продакшн: Час VS гроші
Відразу стало зрозуміло, що силами двох з половиною людина зробити наповнення об'єкта в терміни не вийде. Ми звернулися до стоків 3ddd, Turbosquid і до Unreal marketplace. У підсумку ми отримували моделі з непридатними UV-розгортками, з великою кількістю трикутників і з недолугої топологією, хоча в описі маркетів сказано, що моделі гейм-реді і без оверлапов. Тому довелося правити і спрощувати топологію, заново робити розгортки і допрацьовувати текстури.

У середині проекту звернулися в Unreal marketplace, але і там не все гладко: деякі моделі надто лоу-полі, хоча на превью цього не було видно; складні матеріали там, де цього не потрібно, неправильні UV-розгортки, кілька каналів UV.

У якийсь момент lightmass відмовився прораховувати лайтмапы без пояснення відмови. Ми почали перевірку пропсов, їх левел виявилося 500 штук. Спочатку пішли методом виключення: зробили копію левела, видаляли пропсы і пробували посилати на рендер. Перебравши половину пропсов, знайшовся неправильний, це було рушник в туалеті; повернувшись на рівень, виправили пропс, але лайтмасс раніше відмовлявся вважати. Виявилося, що 80% пропсов з Unreal marketplace мають неправильну розгортку і кілька UV — каналів. Після виправлення пропсов проблема зникла. Щоб уникнути подібного в майбутньому, написали блюпринт для перевірки пропсов на наявність багів з UV.

Код: Blueprint VS C++
90% роботи реалізовано блюпринтами, без знання мов програмування, маючи лише загальні основи. Головне завдання — реалізувати взаємодію з дверима, дверцятами шаф, ящиками так, щоб рішення можна було просто перенести на різні конфігурації дверей. Конфігурацій вийшло 5: відкривання справа-наліво, зліва-направо, зверху-вниз, від себе, на себе.

Від класичного варіанту відкриття «підійшов, натиснув „Е“, двері відчинилися» — відмовилися відразу, вирішили VR зробити відкривання рукою за допомогою контролера.



На перший погляд, просте завдання, але доводилося враховувати колізії з іншими об'єктами, зміщення осі обертання при відкриванні, бік відкриття, також зробити відкривання без «прилипання» двері до контролера при натисканні тригера.



В процесі роботи ми зробили ще боулінг і скример в шафі, для відволікання від розглядання інтер'єрів.

Оптимізація: Картинка VS фпс
Оптимізація — досить болісний процес. Прагнення до реалістичного зображення, вироблене роками в кіно, викликає біль, коли доводиться на догоду fps знижувати якість тіней SSAO, розмір карт відбиттів, спрощувати шейдери, розмір текстур і. т. д.

Робота починалася у версії 4.13, тоді ще не було форвард-шейдинга. З появою в 4.14 давав 20-30 fps приросту, але позбавляв SSAO, HDR Lighting, що в свою чергу різко змінювало картину і вело до переробки проекту. На даний момент ми вирішили цього не робити, залишили для наступного проекту.

Плейтесты: UX VS Users
Плейтесты проходили на різних вікових і гендерних категоріях. В більшості, люди без VR досвіду, швидко освоювалися і неодмінно намагалися відкрити і помацати предмети. Ми спеціально не робили підсвічування активних об'єктів для більшої реалістичності.

З'ясувалося, що недосвідчений користувач плутає 2 кнопки: телепорт і дію. На цьому рівні ми першим ділом показували, як переміщатися в просторі, а потім — як взаємодіяти з предметами, але користувачі продовжували натискати на телепорт і для переміщення в точку, і для відкривання дверей. Ми зробили підказки для кнопок, але ситуація не змінилася. Тому перенесли дії і телепортацію на тригер, зробили однокнопковий варіант управління і залишили тільки один контролер.

Ще ми помітили, що користувачі не відразу розуміють, як користуватися «вудкою»: вони витягали руки паралельно підлозі, натискали на телепорт, «відлітали» в інший кінець рівня і губилися. Тому ми поміняли «вудку» на варіант: при натисканні на тригер, на підлозі з'являється іконка переміщення, поворотом голови, умовно — поглядом, користувач вибирає точку, в яку він хоче переміститися, потім відпускає тригер і переміщається в потрібну точку.

Про відчуття в VR: деякі користувачі намагаються відкрити двері, стоячи від неї в метрі. Нам доводиться пояснювати, що двері відкривається, як у житті: треба до неї підійти, взятися за ручку і потягнути. Також неодмінно все переступають пороги і бояться пройти крізь стіну. Самі в процесі розробки неодноразово ловили себе на бажанні спертися на віртуальний диван або стіл.

Управління ззовні: Unreal.js VS Socket.io
Щоб дати менеджеру можливість вести процес продажів і допомагати людям, які не звикли до нового світу, ми розробили веб-додаток, що дозволяє робити акцент на будинки та об'єкти інфраструктури району, переміщати користувача між рівнями і по точках всередині рівня, а також підібрати квартиру по параметрах і динамічно візуалізувати відповідні пропозиції.

Для того, щоб мінімізувати затримки в спілкуванні з Unreal хотілося використовувати протокол WebSocket. Першим попався на очі плагін Unreal.js, що дозволяє писати на Javascript і містить реалізацію WebSocketServer'а. Зробили прототип для версії 4.13 з цим плагіном, все відмінно запрацювало. Вийшов Unreal 4.14, через кілька днів оновлений плагін, у списку змін два пункти:

  1. сумісний з 4.14 (!!!)
  2. «выпилен» WebSocketServer (???)
Мабуть, тільки нам подобалася ця реалізація. Стали шукати заміну, знайшли socketio-client-ue4, від відомого в співтоваристві getnamo. Все б добре, але на той момент підтримувалася тільки версія 4.13 і приймати в Blueprint можна було тільки рядки. Почали писати бібліотеку для парсингу JSON, але незабаром Getnamo знову дуже порадував, зробивши цю роботу за нас у новому релізі, за що йому величезне спасибі!

У підсумку, вийшло краще, ніж хотілося. Написали окремий сервер, синхронізуючий всі запущені Unreal — і веб-додатки в реальному часі, що, наприклад, дозволяє при бронюванні певної квартири одним користувачем відразу ж вилучити з вибірки для всіх інших.

Зроблений демо-проект виправдав свої очікування і не залишив байдужих, як серед недосвідчених користувачів, так і професіоналів. Багато хто навіть нарікали на те, що не було можливості скористатися подібним сервісом, коли самі купували квартири. Єдине, що поки не вистачає для релізу — це наявність сміливого і амбітного забудовника!

Ось як все це виглядає:



Можете самі спробувати наживо і поспілкуватися з командою розробників. Віртуальний шоурум буде показаний на Лекційному дні в ВШБИ 11 лютого. Записатися тут.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.