Új hozzászólás Aktív témák

• #1 lufikutya újonc

  Új Válasz 2021-12-31 17:24:01 #1

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  lufikutya

  újonc

  Vállalkozásunk korántsem volt kezdő, amikor nekifogtunk egy kiterjesztett valóság app fejlesztésének. Bár a projekt minden szegmensével kapcsolatban volt már releváns tapasztalatunk, az AR élmény létrehozása jóval több erőforrást emésztett fel, mint vártuk, illetve gyakran kényszerültünk az eredeti koncepciótól majdhogynem idegen kompromisszumra. Az alábbiakban összegzem, milyen tapasztalatokat gyűjtöttünk. A kiterjesztett valóság alkalmazásokkal foglalkozó vállalkozásokon kívül a tapasztalataink hasznosnak bizonyulhatnak egyéb szoftverfejlesztéssel foglalkozó szervezetek számára is.

  Fejlesztési, vállalkozási, módszertani tapasztalatok
  
  Gyakran felmerül a kérdés, hogy házon belül történjen a fejlesztés vagy kész keretrendszert használjunk? Ez ebben az esetben nem lehetett alternatíva a dolog komplexitása miatt. A profibb AR keretrendszerek mögött ma már cégóriások állnak, szinte végtelen anyagi lehetőségekkel, de még a független, nyílt forráskódú keretrendszerek esetében is óriási előnyt jelent a közösség támogatása (hiszen a közösség tagjai folyamatosan javítják, fejlesztik a szoftvert, így a vállalkozásnak “csak” a tartalom előállítására kell koncentrálnia, minden más zökkenőmentesen működik. Legalábbis így képzeli el az ember. Mindezek ellenére óva intenék bárkit, aki ezen a ponton saját AR keretrendszer fejlesztését fontolgatná. Nagyon nehezen elképzelhető hogy ez életképes elképzelés lenne 2021-ben.

  Az appunk ötletének kikristályosodásakor a piacon a legalkalmasabb AR keretrendszernek a német fejlesztésű Metaio tűnt. Egy minimál “proof of concept” azaz próba alkalmazás elkészítése után lelkesen utaztunk ki Münchenbe az InsideAR 2014 konferenciára, ahol elképedve láttuk az akkori technológiai színvonalon elképzelhető legjobb AR élményt.

  A konferencia során az összes releváns workshopon részt vettünk, így a hiányzó információkra rá tudtunk kérdezni, és mindennel kapcsolatban pozitív volt a visszajelzés, láttuk, hogy az általunk elképzelt program működni fog, illetve valós tapasztalatokat hallhattunk a trackerek különböző környezetekben való alkalmazhatóságáról, gyakorlati problémákról (trackerek felismerése különböző időjárási viszonyok között, kihelyezett trackerek kopása, megrongálása, hatóságokkal való együttműködés az engedélyezésre, stb.)

  Két út állt előttünk látszólag: az egyik, hogy saját költségen kifejlesztünk egy nagyon limitált képességekkel rendelkező prototípust, amellyel be tudjuk mutatni befektetők számára az Aureában rejlő potenciált, vagy pályázunk támogatásra, és nekifutunk a teljes app megvalósításának, házon belül. Az utóbbi mellett döntöttünk, és ez sajnos visszatekintve egyértelműen rossz döntés volt.

  Az előbb említett, limitált protipussal a vállalkozó megszilárdíthatja a helyzetét a piacon, elsőséget szerezhet. Az ötletgazdák által leggyakrabban mantrázott “ellopják az ötletet” forgatókönyv a mai startup-októl hemzsegő világban is sokkal kevesebbszer történik meg, mert már nem annyira az ötlet, inkább az implementáció számít.
  Pályázati tapasztalatok

  A pályázat benyújtása és az érdemi döntés között eltelt körülbelül két év.

  Ez a körülmény mindenben nehezítette a projekt megvalósítását. A benyújtott támogatási igényhez képest nagyon kevés a vállalkozó mozgástere.

  A munkaerőpiaci helyzet, a bérek, költségek, a technológiai feltételek is rengeteget változtak ezen idő alatt. A kezdeti helyzeti előnyünket, elsőségünket elveszítettük. Még a projekt nevét is meg kellett változtatnunk, mert időközben több szoftver is megjelent ezen a néven.

  Az akkori helyzetet értékelve, mai fejjel már nem vállalkoznék az alkalmazás megvalósítására a két évvel korábban provizionált költségvetéssel. Ezt más vállalkozásoknak is megfontolandó tanácsként írom: még ha a projekt támogatást is nyer, a közben esetleg megváltozott piaci feltételek miatt a projekt megkezdése előtt újra kell értékelni a megvalósíthatóságot, potenciális profitabilitást, és néha -bármennyire is fájó- a jó döntés az, ha nem vágunk bele a vállalkozásba, csak azért, mert már sok munkánk van benne. A közgazdasági szakkifejezéssel élve, elsüllyedt költségekkel és az ezekkel kapcsolatos viszonyrendszerrel rengeteg tanulmány foglalkozik, ezekkel minden vállalkozónak meg kellene ismernie, inkább előbb, mint utóbb.
  
  Keretrendszer tapasztalatok

  A metaio framework-kel volt tapasztalatunk, ebbe fektettünk energiát, az ő konferenciájukra utaztunk ki, az ő termékükre alapoztunk.
  Időközben az Apple Inc. felvásárolta a Metaio-t és a szoftver licenszelését leállították (később az ő termékeik valamilyen formában az Apple AR kit-ben reinkarnálódtak, de mi ebből nem profitáltunk.)

  A React native-vel már volt pozitív tapasztalatunk más fejlesztés kapcsán, továbbá a vezető fejlesztőnk is ebben mozgott a legkényelmesebben, illetve a későbbi karbantartás, frontend fejlesztők bevonhatósága, egyetlen kódbázis Androidra és iOS-re, ezek az érvek álltak az egyik oldalon, és ezek meggyőzőek voltak. A teljesítmény a modern készülékeken a natív alkalmazásokéhoz hasonló, nehéz észrevenni a különbséget. Az átlagos felhasználók körében népszerű, 2-3 éves készülékeken azonban azt tapasztaltuk, hogy a teljesítmény drasztikusan csökken, használhatatlanná válik. Beszereztünk régebbi generációs tesztkészülékeket és a vizuális elemek optimalizálásával elfogadható eredményt értünk el. A React Native nyílt forráskódú szoftver, de a közösségi támogatás kissé rapszodikus: bizonyos hibákat pár nap alatt javítanak, míg másokat hónapok alatt sem.

  AR keretrendszernek végül a Wikitude-ra esett a választás a (túl) sok alternatíva közül. Komoly referenciákkal és nagy cégek támogatásával, az összes számunkra fontos szolgáltatással. Hamar túlestünk a Hello World-ön és a Proof of Concept-en. Az adminisztrációs panel és a jogosultságok delegálása alfiókok részére (ami a felhasználók által generált tartalom kezelése miatt igen fontos) sajnos nem kompromisszummentes.

  Az alkalmazás háttér rendszerét a Google Firebase szolgáltatja.

  Integrációs tapasztalatok

  Alapvetően a keretrendszer nem támogatta, hogy az AR kamera nézet fölé (a Z orderben) egyéb GUI elemeket helyezzünk el (gombok stb). Ennek megoldására, írni kellett egy Bridge réteget, ami biztosítja a lehetőséget, hogy a Wikitude keretrendszer használatakor ne veszítsük el a fókuszt az azt használó alkalmazástól.

  Ezen felül a 3D objektumokat optimalizálni kellett és kontrollálni, hogy mikor és mi jelenjen meg a kamera nézetben. Ez főleg a komplexebb, sok polygonos objektumok miatt volt fontos, hogy a régebbi, gyengébb mobil eszközökön is élvezhető legyen az alkalmazás.

  A Google Firebase integrációja teljesen problémamentes és gyakorlatilag a teljes adattárolási kérdéskört (felhasználók és tartalmak is) lefedi, skálázható szolgáltatással és ésszerű árazással. Használata rengeteg munkát spórolt meg a fejlesztők számára.
  
  Wikitude AR framework tapasztalatok

  Általánosságban elmondható, hogy a mobil eszközökön elérhető AR élmény a Wikitude keretrendszer használatával leginkább a kétdimenziós tartalmak perspektivikus megjelenítésére alkalmas, de a mi esetünkben ez gyakran elég.

  Számtalan kísérletet tettünk a háromdimenziós modellek realisztikus megjelenítésére, de az eredmény általában elmaradt a várakozásoktól. Mint fent említettem, eleve az alacsony poligonszámú modelleket tudjuk csak használni, így a modern grafikájú játékokhoz szokott felhasználó ellenérzését váltja már ki a kezdetekkor. A 6 év feletti, videojátékos gyermek pont emiatt utasítja el, az ennél fiatalabb korosztály számára véleményünk szerint nem etikus semmilyen alkalmazást fejleszteni, így ennek az elfogadását/elutasítását nem vizsgáltuk meg.

  A valóságos élményhez hozzátartozik az objektumok által vetett árnyék realisztikus megjelenítése, de ez jelenleg csak a LIDAR-ral felszerelt készülékek esetén elképzelhető.

  Az ún. inclusion-problémát (a kiterjesztett valóságban megjelenített objektum ne takarjon ki a kamerához közelebb található tárgyakat) nem tudja kezelni - erre egyedül az iPhone 12-es és újabb típusú készülékek képesek és csak az Apple keretrendszerét használva.

  A 3D objektumok napszaknak, időjárási viszonyoknak és fényviszonyoknak megfelelő megjelenítése valós időben a mai technológiai színvonalon nem egyszerű, pontosabban csak korlátozott körben, kontrollált viszonyok között valósítható meg (pl. egy fix bevilágítással rendelkező múzeumi térben)

  A markerek felismerése szintén korlátozott, 3D markerek felismerése gyakorlatilag nem működik a Wikitude-ban, azonban meglepően kedvező eredményeket értünk el a tárgyak 2D fotóit használva markerként.

  A Wikitude folyamatosan fejleszt, így a fent leírtak várhatóan egy éven belül, de akár hamarabb is kedvező irányba változhatnak.

Új hozzászólás Aktív témák