Podcast "ITMO Research_": hur man närmar sig synkroniseringen av AR-innehåll med en show i skalan av en hel stadion

Detta är den första delen av textutskriften av den andra intervjun för vårt program (Apple Podcasts, Yandex.Music). Problem Gäst - Andrey Karsakov (kapc3d), Ph.D., seniorforskare vid Nationellt centrum för kognitiv forskning, docent vid fakulteten för digitala transformationer.

Sedan 2012 har Andrey arbetat i forskargruppen Visualization and Computer Graphics. Engagerad i stora tillämpade projekt på statlig och internationell nivå. I den här delen av samtalet berättar vi om hans erfarenhet av AR-stöd för offentliga evenemang.

Podcast "ITMO Research_": hur man närmar sig synkroniseringen av AR-innehåll med en show i skalan av en hel stadion
Photo Shoot Detta är Engineering RAEng (Unsplash.com)

Projektets sammanhang och mål

Tidskod (av ljudversioner) — 00:41

dmitrykabanov: Jag skulle vilja börja med European Games-projektet. Det är multikomponent, flera lag deltog i förberedelserna, och att tillhandahålla förstärkt verklighet för en publik på tusentals direkt under ett evenemang på stadion är en ganska allvarlig uppgift. När det gäller ditt engagemang, var det mjukvaran först?

kapc3d: Ja, vi gjorde programmeringsdelen och gav support under showen. Det var nödvändigt att spåra, övervaka och lansera allt i realtid, och även arbeta med tv-gruppen. Om vi ​​betraktar det här projektet som en helhet, då kan vi prata om öppnings- och avslutningsceremonierna Europeiska spel i Minsk, samt om öppningsceremonin av mästerskapet Worldskills i Kazan. Det var samma arbetsschema, men olika händelser. Det var två månader mellan dem. Vi förberedde projektet tillsammans med killarna från företaget Sechenov.com.

Vi träffade dem av en slump Vetenskapsfest, som ägde rum hösten 2018. Våra masterstudenter visade upp sitt kursprojekt på temat VR. Killarna kom fram till oss och frågade vad vi gjorde i vårt laboratorium. Det såg ut ungefär så här:

— Du jobbar med VR, men kan du jobba med augmented reality?

- Nåväl, typ, ja.

– Det finns en sådan uppgift, med sådana inledande anteckningar. Kan du göra det?

De repade sina kålrots lite, det verkar inte vara något orealistiskt:

– Låt oss försöka studera allt först, och sedan hitta en lösning.

Dmitriy: Ger de bara mediastöd?

Andrew: De gör en full stack. Ur lednings- och organisationssynpunkt är de helt involverade i regi, iscensättning, val av kulisser, logistik och annan teknisk support. Men de ville göra något speciellt för Europaspelen. Dessa specialeffekter, liksom mixed reality, har gjorts för tv ganska länge, men de är inte de mest budgetvänliga när det gäller tekniskt genomförande. Därför letade killarna efter alternativa alternativ.

Dmitriy: Låt oss diskutera problemet mer detaljerat. Vad bestod den av?

Andrew: Det finns en händelse. Det varar en och en halv timme. Vi måste se till att publiken som ser det live och de som sitter på stadion kan se augmented reality-effekterna i full synkronisering med liveshowen när det gäller tid och plats på sajten.

Det fanns ett antal tekniska begränsningar. Det var omöjligt att göra tidssynkronisering via Internet, eftersom det fanns rädsla för överbelastning på nätverket med fulla läktare och utsikterna att statschefer skulle delta i evenemanget, vilket kunde störa mobilnäten.

Andrey Karsakov, foto från material från ITMO University
Podcast "ITMO Research_": hur man närmar sig synkroniseringen av AR-innehåll med en show i skalan av en hel stadionVi hade två nyckelkomponenter i det här projektet - den personliga upplevelsen som människor kan få genom mobila enheter, och vad som går in i tv-sändningen och informationsskärmarna på själva stadion.

Om en person plötsligt tittar på avsnitt av förstärkt verklighet via en mobil enhet och samtidigt kommer upp på skärmen, borde han se samma bild.

Vi behövde två praktiskt taget olika system för att vara helt synkroniserade i tid. Men det speciella med sådana shower är att det är komplexa händelser där ett stort antal tekniska tjänster är inblandade och alla operationer utförs enligt tidskoder. Tidskod är ett specifikt ögonblick i tiden då något börjar: ljus, ljud, människor som går, scenblad som öppnar sig och så vidare. Vi var tvungna att anpassa oss till det här systemet så att allt skulle starta i rätt tid. En annan funktion var att scenerna och avsnitten med förstärkt verklighet var manusrelaterade.

Dmitriy: Men bestämde du dig för att överge användningen av tidskoder på grund av de höga riskerna för force majeure, eller beräknade du först några effektegenskaper och insåg att belastningen på hela systemet skulle bli ganska hög?

Andrew: Om du gör en synkroniseringstjänst för en sådan publik, så är det inte särskilt svårt. I vilket fall som helst kommer förfrågningar inte att misslyckas över en natt. Ja, belastningen är hög, men det är ingen nödsituation. Frågan är om det är värt att lägga resurser och tid på detta om nätet plötsligt slocknar. Vi var inte säkra på att detta inte skulle hända. Till slut fungerade allt, med avbrott på grund av belastningen, men det fungerade, och vi synkroniserade enligt tidskoden enligt ett annat schema. Detta var en av de globala utmaningarna.

Implementeringssvårigheter ur UX-synpunkt

Tidskod (av ljudversioner) — 10:42

Andrew: Vi var också tvungna att ta hänsyn till att arenan inte är en klassisk konsertlokal och synkronisera systemen över hela utrymmet för mobila enheter. Så för ett tag sedan blev jag viral förstärkt verklighetshistoria på Eminem-konserter, då var det ett fall med Loboda.

Photo Shoot Robert hejdå (Unsplash.com)
Podcast "ITMO Research_": hur man närmar sig synkroniseringen av AR-innehåll med en show i skalan av en hel stadionMen det här är alltid en upplevelse framför dig - hela publiken står framför scenen, synkroniseringen är ganska enkel. När det gäller en stadion måste du förstå vilken sida av cirkeln du befinner dig på, den relativa positionen, så att arenan passar in i det utrymme som finns i den virtuella miljön. Det var en sur utmaning. Man försökte lösa det på olika sätt, och resultatet blev ett fall nära det som genomfördes av Loboda, men inte i alla avseenden.

Vi låter användaren bestämma var han är. Vi gjorde markeringar för stadion, där folk valde en sektor, en rad, en plats. Allt detta med fyra "klick". Därefter var vi tvungna att bestämma riktningen till scenen. För att göra detta visade vi en siluett av hur scenen ungefär borde se ut ur ett anpassat perspektiv. Han kombinerade det, knackade och det var allt - scenen satte sig. Vi försökte förenkla denna process så mycket som möjligt. Ändå är 90 % av tittarna som ville se programmet inte de personer som har erfarenhet av att kommunicera med förstärkt verklighet.

Dmitriy: Fanns det en separat ansökan för detta projekt?

Andrew: Ja, en applikation för iOS och Android, som vi skickade till butiken. Det fanns en separat reklamkampanj för det. Det har tidigare beskrivits i detalj hur man laddar ner och så vidare.

Dmitriy: Du måste förstå att det inte finns någon plats för en person att fysiskt testa och lära sig hur man använder en sådan applikation. Därför blev uppgiften att "utbilda" publiken mer komplicerad.

Andrew: Jaja. Med UX fångade vi många stötar, eftersom användaren vill få upplevelsen med tre klick: nedladdat, installerat, lanserat - det fungerade. Många människor är för lata för att följa komplexa tutorials, läsa tutorials och så vidare. Och vi försökte inte förklara allt för användaren så mycket som möjligt i handledningen: ett fönster öppnas här, tillgång till kameran här, annars fungerar det inte, och så vidare. Oavsett hur många förklaringar du skriver, hur detaljerat du än tuggar, oavsett vilka gifs du lägger in, så läser folk det inte.

I Minsk samlade vi en stor pool av feedback om denna del och har redan ändrat mycket för applikationen i Kazan. Vi lade in där inte bara de fonogrammen och de tidskoderna som motsvarar en specifik episod av augmented reality, utan vi tog alla fonogram och tidskoder i sin helhet. Så applikationen hörde vad som hände vid lanseringen och - om en person loggade in vid fel ögonblick - gav den ut informationen: "Kamrat, jag är ledsen, ditt AR-avsnitt kommer om 15 minuter."

Lite om arkitekturen och förhållningssättet till synkronisering

Tidskod (av ljudversioner) — 16:37

Dmitriy: Bestämde du dig för att synkronisera med ljud?

Andrew: Ja, det hände av en slump. Vi tittade igenom alternativ och stötte på ett företag Cifrasoft från Izhevsk. De gör en inte särskilt sofistikerad, men järnarbetande SDK, som låter dig synkronisera ljudet med timingen. Systemet var positionerat för att fungera med TV, när du kan visa något i en applikation baserat på ljudet av en villkorlig annons eller ge en interaktiv upplevelse baserad på filmspåret.

Dmitriy: Men det är en sak - du sitter i ditt vardagsrum och en annan sak - en stadion med tusentals människor. Hur gick det för dig med kvaliteten på ljudinspelningen och dess efterföljande igenkänning?

Andrew: Det fanns många rädslor och tvivel, men i de flesta fall kändes allt väl igen. De bygger signaturer på ljudspåret med sina listiga algoritmer – resultatet väger mindre än den ursprungliga ljudfilen. När mikrofonen lyssnar på det omgivande ljudet försöker den hitta dessa funktioner och känna igen spåret baserat på dem. Under bra förhållanden är synkroniseringsnoggrannheten 0,1-0,2 sekunder. Detta var mer än tillräckligt. Under dåliga förhållanden var avvikelsen upp till 0,5 sekunder.

Mycket beror på enheten. Vi arbetade med en stor flotta av enheter. För iPhones finns det bara 10 modeller. De fungerade bra när det gäller kvalitet och andra funktioner. Men med androider är djurparken som min mamma. Inte överallt visade det sig att ljudsynkroniseringen fungerade. Det fanns fall då det var omöjligt att höra olika spår på olika enheter på grund av vissa egenheter. Någonstans försvinner de låga frekvenserna, någonstans börjar de höga frekvenserna väsa. Men om enheten hade en normaliserare på mikrofonen fungerade synkroniseringen alltid.

Dmitriy: Berätta gärna om arkitekturen - vad användes i projektet?

Andrew: Vi gjorde applikationen i Unity - det enklaste alternativet när det gäller flera plattformar och att arbeta med grafik. Använd AR Foundation. Vi sa direkt att vi inte ville komplicera systemet, så vi begränsade oss till en flotta av enheter som stöder ARKit och ARCore för att hinna testa allt. Vi gjorde ett plugin för DigitalSoft SDK, det finns på vår GitHub. Vi skapade ett innehållshanteringssystem så att skript skulle köras enligt tidslinjen.

Vi pysslade lite med partikelsystemet, eftersom användaren kan komma in när som helst i ett visst avsnitt, och vi behöver honom att se allt från det ögonblick han synkroniserade. Vi mixtrade med ett system som gör att scenarier kan spelas upp tydligt i tid, så att XNUMXD-upplevelsen kan rullas fram och tillbaka, som i en film. Även om det fungerar direkt med klassiska animationer, var vi tvungna att mixtra med partikelsystem. Vid något tillfälle börjar de leka, och om du befinner dig någonstans före spawnpunkten har de ännu inte fötts, även om det verkar som att de borde vara det. Men det här problemet är faktiskt ganska lätt att lösa.

För den mobila delen är arkitekturen ganska enkel. För tv-sändningar är allt mer komplicerat. Vi hade hårdvarubegränsningar. Kunden ställde ett villkor: "Här har vi en sådan och en hårdvarupark, grovt sett måste allt fungera på den." Vi fokuserade direkt på att vi skulle arbeta med relativt budgetkort för videoinspelning. Men budgeten betyder inte att de är dåliga.

Det fanns restriktioner på hårdvara, på videoinspelningskort och på arbetsförhållanden – hur vi skulle ta emot bilden. Fånga kort - Blackmagic Design, fungerade enligt Internal keying-schemat - det är när en videoram kommer till dig från kameran. Kortet har ett eget bearbetningschip, där även en ram sätts in, som ska läggas ovanpå den inkommande. Kortet blandar ihop dem - vi rör inte vid något annat där och påverkar inte ramen från videokameran. Hon spottar ut resultatet till kontrollrummet via videoutgången. Det här är en bra metod för att lägga över titlar och andra liknande saker, men den är inte särskilt lämplig för mixed reality-effekter eftersom det finns många restriktioner för renderingspipeline.

Dmitriy: När det gäller realtidsberäkning, objektbindning eller något annat?

Andrew: När det gäller kvalitet och att uppnå önskade effekter. För vi vet inte vad vi lägger bilden ovanpå. Vi skickar helt enkelt färg- och transparensinformation ovanpå originalströmmen. Vissa effekter som brytningar, korrekt transparens och ytterligare skuggor kan inte uppnås med detta schema. För att göra detta måste du rendera allt tillsammans. Det finns till exempel inget sätt att skapa effekten av luftförvrängning från en brand eller het asfalt. Detsamma gäller överföringen av transparenseffekten med hänsyn tagen till brytningsindex. Vi gjorde först innehåll baserat på dessa begränsningar och försökte använda lämpliga effekter.

Visa det här inlägget på Instagram

Avslutning av de andra europeiska spelen i Minsk.

Ett inlägg delat av Alena Lanskaya (@alyonalanskaya) den 30 juni 2019 kl. 3:19 PDT

Dmitriy: Hade du redan ditt eget innehåll i det första projektet för Europaspelen?

Andrew: Nej, huvudstadiet av innehållsutveckling gjordes av killarna från Sechenov.com. Deras grafiker ritade grundinnehållet med animationer och annat. Och vi integrerade allt i motorn, lade till ytterligare effekter, anpassade det så att allt fungerade korrekt.

Om vi ​​pratar om pipeline, så för tv-sändningar samlade vi allt på Unreal Engine 4. Av en slump började de just i det ögonblicket boosta sina verktyg för blandad verklighet. Det visade sig att allt inte är så enkelt. Redan nu är alla verktyg råa, vi var tvungna att avsluta mycket för hand. I Minsk arbetade vi med en specialbyggd motor, det vill säga vi skrev om några saker inuti motorn så att vi till exempel kunde rita skuggor ovanpå riktiga föremål. Den version av motorn som var aktuell vid den tiden hade inte funktioner som gjorde att detta kunde göras med hjälp av standardverktyg. Av denna anledning gjorde våra killar sin egen skräddarsydda montering för att tillhandahålla allt som var absolut nödvändigt.

Andra nyanser och anpassning till WorldSkills i Kazan

Tidskod (av ljudversioner) — 31:37

Dmitriy: Men allt detta på ganska kort tid?

Andrew: Tidsfristerna var snäva Kazan projekt, enligt Minsk - normalt. Ungefär ett halvår för utveckling, men med hänsyn till att sex personer var inblandade. Samtidigt gjorde vi den mobila delen och utvecklade verktyg för tv-produktion. Det fanns inte bara en bildutgång. Till exempel ett spårningssystem med optik, för detta fick man skapa sina egna verktyg.

Dmitriy: Fanns det någon anpassning från ett projekt till ett annat? På en och en halv månad var det nödvändigt att dra nytta av utvecklingen och överföra projektet med nytt innehåll till en ny sida?

Andrew: Ja, det var i en och en halv månad. Vi hade planerat en två veckor lång semester för hela laget efter Minsk-projektet. Men direkt efter stängning kommer killarna från Sechenov.com fram och säger: "Ja, låt oss göra Kazan då." Vi hann ändå vila lite, men gick över till det här projektet ganska snabbt. Vi har slutfört en del tekniskt arbete. Den mesta tiden ägnades åt innehåll, för för WorldSkills gjorde vi det helt och hållet, vi koordinerade det bara med produktionsteamet. Det fanns bara ett manus från deras sida. Men det var enklare - det behövdes inget extra iterationer. När du skapar innehåll själv ser du direkt hur det fungerar i motorn, och du kan snabbt redigera och koordinera.


När det gäller den mobila delen tog vi hänsyn till alla finesser som vi hade i Minsk. Vi gjorde en ny applikationsdesign, designade om arkitekturen lite, lade till tutorials, men försökte göra det så kort och tydligt som möjligt. Vi minskade antalet användarsteg från att starta applikationen till att se innehållet. En och en halv månad räckte för att slutföra ett adekvat projekt. På en och en halv vecka nådde vi platsen. Det var lättare att arbeta där eftersom all kontroll över projektet var i händerna på arrangörerna, det fanns inget behov av att samordna med andra kommittéer. Det var enklare och lättare att arbeta i Kazan och det var helt normalt att det blev mindre tid.

Dmitriy: Men bestämde du dig för att lämna synsättet på synkronisering som det var, baserat på ljud?

Andrew: Ja, vi lämnade det genom ljud. Det fungerade bra. Som de säger, om det fungerar, rör det inte. Vi tog helt enkelt hänsyn till nyanserna i kvaliteten på ljudspåret. När de gjorde introt fanns det ett träningsavsnitt för folk att prova innan showen började. Det var förvånande att när det i ögonblicket av banan spelas på arenan det stormiga applåder, "live", låter systemet dig synkronisera bra med denna bana, men om inspelade applåder i detta ögonblick blandas med banan, då spåret fångas inte längre. Sådana nyanser togs i beaktande, och allt synkroniserades ganska bra när det gäller ljud.

PS I den andra delen av numret pratar vi om vetenskaplig datavisualisering, processmodellering i andra projekt, spelutveckling och masterprogrammet "Teknik för utveckling av datorspel" Vi kommer att publicera en fortsättning i nästa artikel. Du kan lyssna och stötta oss här:

PPS Under tiden, på den engelska versionen av Habr: en närmare titt på ITMO University.

Källa: will.com

Lägg en kommentar