Dette er første del av tekstutskriften av det andre intervjuet for programmet vårt (, ). Problem gjest - (), Ph.D., seniorforsker ved Nasjonalt senter for kognitiv forskning, førsteamanuensis ved Fakultet for digitale transformasjoner.
Siden 2012 har Andrey jobbet i forskningsgruppen Visualization and Computer Graphics. Engasjert i store anvendte prosjekter på statlig og internasjonalt nivå. I denne delen av samtalen snakker vi om hans erfaring med AR-støtte til offentlige arrangementer.
Bilde (Unsplash.com)
Prosjektkontekst og mål
Tidskode (av ) — 00:41
: Jeg vil gjerne begynne med European Games-prosjektet. Det er multikomponent, flere lag deltok i forberedelsene, og å tilby utvidet virkelighet for et publikum på tusenvis rett under et arrangement på stadion er en ganske alvorlig oppgave. Når det gjelder ditt engasjement, var det programvare først?
: Ja, vi gjorde programmeringsdelen og ga støtte under showet. Det var nødvendig å spore, overvåke og lansere alt i sanntid, og også samarbeide med TV-gruppen. Hvis vi vurderer dette prosjektet som en helhet, så kan vi snakke om åpnings- og avslutningsseremoniene i Minsk, samt om åpningsseremonien til mesterskapet i Kazan. Det var samme arbeidsopplegg, men forskjellige arrangementer. Det var to måneder mellom dem. Vi utarbeidet prosjektet sammen med gutta fra selskapet .
Vi møtte dem ved en tilfeldighet , som fant sted høsten 2018. Våre masterstudenter viste frem sitt kursprosjekt om temaet VR. Gutta kom bort til oss og spurte hva vi gjorde i laboratoriet vårt. Det så omtrent slik ut:
— Du jobber med VR, men kan du jobbe med utvidet virkelighet?
- Vel, liksom, ja.
– Det er en slik oppgave, med slike innledende notater. Kan du gjøre det?
De klødde nepene litt, det ser ikke ut til å være noe urealistisk:
– La oss prøve å studere alt først, og så finne en løsning.
Dmitriy: Gir de kun mediestøtte?
Andrew: De lager en full stabel. Fra ledelsens og organisasjonens ståsted er de helt involvert i regi, iscenesettelse, valg av kulisser, logistikk og annen teknisk support. Men de ønsket å gjøre noe spesielt for de europeiske lekene. Disse spesialeffektene har, som mixed reality, blitt laget for TV ganske lenge, men de er ikke de mest budsjettvennlige når det gjelder teknisk implementering. Derfor så gutta etter alternative alternativer.
Dmitriy: La oss diskutere problemet mer detaljert. Hva bestod den av?
Andrew: Det er et arrangement. Det varer en og en halv time. Vi må sørge for at publikum som ser det live og de som sitter på stadion kan se augmented reality-effektene i full synkronisering med live-showet når det gjelder tid og plassering på siden.
Det var en rekke tekniske begrensninger. Det var umulig å gjøre tidssynkronisering via Internett, fordi det var frykt for overdreven belastning på nettverket med fulle tribuner og utsiktene til at statsoverhoder skulle delta på arrangementet, noe som kunne blokkere mobilnettene.
Andrey Karsakov, bilde fra
Vi hadde to nøkkelkomponenter til dette prosjektet - den personlige opplevelsen som folk kan få gjennom mobile enheter, og det som går inn i TV-sendingen og informasjonsskjermene på selve stadion.
Hvis en person plutselig ser på episoder av utvidet virkelighet gjennom en mobilenhet og samtidig kommer på skjermen, bør han se det samme bildet.
Vi trengte to praktisk talt forskjellige systemer for å bli fullstendig synkronisert i tid. Men det særegne med slike show er at dette er komplekse hendelser der et stort antall tekniske tjenester er involvert og alle operasjoner utføres i henhold til tidskoder. Tidskode er et spesifikt øyeblikk i tid der noe starter: lys, lyd, folk som drar, sceneblader som åpner seg, og så videre. Vi måtte tilpasse oss dette systemet slik at alt skulle starte til rett tid. Et annet trekk var at scenene og episodene med utvidet virkelighet var manusrelaterte.
Dmitriy: Men bestemte du deg for å forlate bruken av tidskoder på grunn av den høye risikoen for force majeure, eller beregnet du først noen kraftkarakteristikk og innså at belastningen på hele systemet ville være ganske høy?
Andrew: Hvis du lager en synkroniseringstjeneste for et slikt publikum, så er det ikke veldig vanskelig. Forespørsler vil uansett ikke mislykkes over natten. Ja, belastningen er høy, men det er ikke en nødsituasjon. Spørsmålet er om det er verdt å bruke ressurser og tid på dette dersom nettet plutselig går ut. Vi var ikke sikre på at dette ikke ville skje. Til syvende og sist fungerte alt, med avbrudd på grunn av belastningen, men det fungerte, og vi synkroniserte i henhold til tidskoden i henhold til et annet opplegg. Dette var en av de globale utfordringene.
Vanskeligheter med implementering fra et UX-synspunkt
Tidskode (av ) — 10:42
Andrew: Vi måtte også ta hensyn til at stadion ikke er et klassisk konsertsted, og synkronisere systemene på tvers av plassen for mobile enheter. Så for en tid siden ble jeg viral på Eminem-konserter, så var det en sak med Loboda.
Bilde (Unsplash.com)
Men dette er alltid en opplevelse foran deg – hele publikum står foran scenen, synkroniseringen er ganske enkel. Når det gjelder et stadion, må du forstå hvilken side av sirkelen du er på, den relative plasseringen, slik at stadion passer inn i rommet som finnes i det virtuelle miljøet. Det var en sur utfordring. De prøvde å løse det på ulike måter, og resultatet ble en sak nær det som ble implementert av Loboda, men ikke på alle måter.
Vi lar brukeren bestemme hvor han er. Vi laget markeringer for stadion, der folk valgte en sektor, en rekke, et sted. Alt dette med fire "klikk". Deretter måtte vi bestemme retningen til scenen. For å gjøre dette viste vi en silhuett av hvordan scenen omtrent skulle se ut fra et tilpasset perspektiv. Han kombinerte det, banket og det var det - scenen satte seg ned. Vi prøvde å forenkle denne prosessen så mye som mulig. Likevel er 90 % av seerne som ønsket å se programmet ikke de som har erfaring med å kommunisere med utvidet virkelighet.
Dmitriy: Var det en egen søknad for dette prosjektet?
Andrew: Ja, en applikasjon for iOS og Android, som vi presset til butikken. Det var en egen reklamekampanje for det. Det ble tidligere beskrevet i detalj hvordan du laster ned og så videre.
Dmitriy: Du må forstå at det ikke er noe sted for en person å fysisk teste og lære å bruke en slik applikasjon. Derfor ble oppgaven med å "utdanne" publikum mer komplisert.
Andrew: Ja Ja. Med UX fanget vi mange støt, fordi brukeren ønsker å få opplevelsen med tre klikk: lastet ned, installert, lansert – det fungerte. Mange mennesker er for late til å følge komplekse opplæringsprogrammer, lese opplæringsprogrammer og så videre. Og vi prøvde ikke å forklare alt for brukeren så mye som mulig i opplæringen: et vindu åpnes her, tilgang til kameraet her, ellers vil det ikke fungere, og så videre. Uansett hvor mange forklaringer du skriver, uansett hvor detaljert du tygger, uansett hvilke gif-er du setter inn, leser folk det ikke.
I Minsk samlet vi en stor pool av tilbakemeldinger på denne delen, og har allerede endret mye for applikasjonen i Kazan. Vi la inn ikke bare de fonogrammene og de tidskodene som tilsvarer en spesifikk episode av utvidet virkelighet, men vi tok alle fonogrammene og tidskodene i sin helhet. Så applikasjonen hørte hva som skjedde på lanseringstidspunktet, og - hvis en person logget på feil øyeblikk - ga den ut informasjonen: "Kamerat, jeg beklager, AR-episoden din vil være om 15 minutter."
Litt om arkitekturen og tilnærmingen til synkronisering
Tidskode (av ) — 16:37
Dmitriy: Bestemte du deg for å synkronisere med lyd?
Andrew: Ja, det skjedde ved et uhell. Vi så gjennom alternativer og kom over et selskap fra Izhevsk. De lager en ikke spesielt sofistikert, men jernbearbeidende SDK, som lar deg synkronisere lyden med timingen. Systemet ble posisjonert for å fungere med TV, når du kan vise noe i en applikasjon basert på lyden av en betinget reklame eller gi en interaktiv opplevelse basert på filmsporet.
Dmitriy: Men det er én ting - du sitter i stuen din, og en annen ting - et stadion med tusenvis av mennesker. Hvordan fungerte ting for deg med kvaliteten på lydopptaket og den påfølgende gjenkjenningen?
Andrew: Det var mye frykt og tvil, men i de fleste tilfeller ble alt gjenkjent godt. De bygger signaturer på lydsporet med sine utspekulerte algoritmer – resultatet veier mindre enn den originale lydfilen. Når mikrofonen lytter til lyden rundt, prøver den å finne disse funksjonene og gjenkjenne sporet basert på dem. Under gode forhold er synkroniseringsnøyaktigheten 0,1-0,2 sekunder. Dette var mer enn nok. Under dårlige forhold var avviket opptil 0,5 sekunder.
Mye avhenger av enheten. Vi jobbet med en stor flåte av enheter. For iPhones er det bare 10 modeller. De fungerte bra med tanke på kvalitet og andre funksjoner. Men med androider er dyrehagen som min mor. Ikke alle steder viste det seg at lydsynkroniseringen fungerte. Det var tilfeller da det var umulig å høre forskjellige spor på forskjellige enheter på grunn av noen særegenheter. Et sted forsvinner de lave frekvensene, et eller annet sted begynner de høye frekvensene å pipe. Men hvis enheten hadde en normalisator på mikrofonen, fungerte alltid synkroniseringen.
Dmitriy: Fortell oss gjerne om arkitekturen - hva ble brukt i prosjektet?
Andrew: Vi laget applikasjonen i Unity - det enkleste alternativet når det gjelder multiplattform og arbeid med grafikk. Brukte AR Foundation. Vi sa umiddelbart at vi ikke ønsket å komplisere systemet, så vi begrenset oss til en flåte av enheter som støtter ARKit og ARCore for å ha tid til å teste alt. Vi laget en plugin for DigitalSoft SDK, det . Vi laget et innholdsstyringssystem slik at skriptene kjøres i henhold til tidslinjen.
Vi fiklet litt med partikkelsystemet, fordi brukeren kan gå inn når som helst i en bestemt episode, og vi trenger at han ser alt fra det øyeblikket han synkroniserte. Vi fiklet med et system som lar scenarier spilles av tydelig i tid, slik at XNUMXD-opplevelsen kan rulles frem og tilbake, som i en film. Mens det fungerer ut av boksen med klassiske animasjoner, måtte vi tukle med partikkelsystemer. På et tidspunkt begynner de å gyte, og hvis du befinner deg et sted før gytepunktet, er de ennå ikke født, selv om det virker som de burde være det. Men dette problemet er faktisk ganske enkelt å løse.
For den mobile delen er arkitekturen ganske enkel. For TV-kringkasting er alt mer komplisert. Vi hadde maskinvarebegrensninger. Kunden satte en betingelse: "Her har vi en sånn og en maskinpark, grovt sett må alt fungere på den." Vi fokuserte umiddelbart på at vi ville jobbe med relativt budsjett videoopptakskort. Men budsjett betyr ikke at de er dårlige.
Det var restriksjoner på maskinvare, på videoopptakskort og på arbeidsforhold – hvordan vi skulle motta bildet. Capture-kort - Blackmagic Design, fungerte i henhold til intern nøkkelskjema - dette er når en videoramme kommer til deg fra kameraet. Kortet har en egen prosesseringsbrikke, hvor det også settes inn en ramme, som må legges over den innkommende. Kortet blander dem sammen - vi berører ikke noe annet der og påvirker ikke rammen fra videokameraet. Hun spytter ut resultatet til kontrollrommet via videoutgangen. Dette er en god metode for å overlegge titler og andre lignende ting, men den er lite egnet for mixed reality-effekter fordi det er mange restriksjoner på render-pipeline.
Dmitriy: Når det gjelder sanntidsdatabehandling, objektbinding eller noe annet?
Andrew: Når det gjelder kvalitet og oppnå de ønskede effektene. Fordi vi ikke vet hva vi legger bildet på toppen av. Vi sender ganske enkelt farge- og gjennomsiktighetsinformasjon på toppen av den originale strømmen. Noen effekter som refraksjoner, korrekt gjennomsiktighet og ekstra skygger kan ikke oppnås med dette opplegget. For å gjøre dette må du gjengi alt sammen. For eksempel er det ingen måte å skape effekten av luftforvrengning fra brann eller varm asfalt. Det samme gjelder overføring av transparenseffekten med hensyn til brytningsindeksen. Vi laget først innhold basert på disse begrensningene og prøvde å bruke passende effekter.
Dmitriy: Hadde du allerede ditt eget innhold i det første prosjektet til European Games?
Andrew: Nei, hovedstadiet av innholdsutvikling ble gjort av gutta fra Sechenov.com. Grafikerne deres tegnet grunninnholdet med animasjoner og andre ting. Og vi integrerte alt i motoren, la til tilleggseffekter, tilpasset det slik at alt fungerte riktig.
Hvis vi snakker om rørledningen, så for TV-kringkasting samlet vi alt på Unreal Engine 4. Tilfeldigvis begynte de akkurat i det øyeblikket å øke verktøyene sine for blandet virkelighet. Det viste seg at alt ikke er så enkelt. Selv nå er alle verktøyene rå, vi måtte gjøre ferdig mye for hånd. I Minsk jobbet vi med en tilpasset konstruksjon av motoren, det vil si at vi skrev om noen ting inne i motoren slik at vi for eksempel kunne tegne skygger oppå virkelige objekter. Den versjonen av motoren som var aktuell på det tidspunktet hadde ikke funksjoner som gjorde at dette kunne gjøres ved bruk av standardverktøy. Av denne grunn laget gutta våre sin egen tilpassede montering for å gi alt som var helt nødvendig.
Andre nyanser og tilpasning til WorldSkills i Kazan
Tidskode (av ) — 31:37
Dmitriy: Men alt dette på ganske kort tid?
Andrew: Tidsfristene var stramme , ifølge Minsk - normal. Ca seks måneder til utvikling, men tatt i betraktning at seks personer var involvert. Samtidig laget vi mobildelen og utviklet verktøy for TV-produksjon. Det var ikke bare en bildeutgang. For eksempel et sporingssystem med optikk, for dette måtte du lage dine egne verktøy.
Dmitriy: Var det noen tilpasning fra ett prosjekt til et annet? I en og en halv måned var det nødvendig å utnytte utviklingen og overføre prosjektet med nytt innhold til en ny side?
Andrew: Ja, det var i en og en halv måned. Vi hadde planlagt en to ukers ferie for hele teamet etter Minsk-prosjektet. Men umiddelbart etter lukking kommer gutta fra Sechenov.com opp og sier: "Vel, la oss gjøre Kazan da." Vi klarte fortsatt å hvile oss litt, men gikk over til dette prosjektet ganske raskt. Vi har fullført noe teknisk arbeid. Mesteparten av tiden ble brukt på innhold, for for WorldSkills gjorde vi det helt, vi koordinerte det bare med produksjonsteamet. Det var bare et manus fra deres side. Men det var lettere – det var ikke behov for ekstra iterasjoner. Når du lager innhold selv, ser du umiddelbart hvordan det fungerer i motoren, og du kan raskt redigere og koordinere.
Når det gjelder den mobile delen, tok vi hensyn til alle finesser som vi hadde i Minsk. Vi laget et nytt applikasjonsdesign, redesignet arkitekturen litt, la til opplæringsprogrammer, men prøvde å gjøre det så kort og tydelig som mulig. Vi reduserte antall brukertrinn fra å starte applikasjonen til å se innholdet. En og en halv måned var nok til å fullføre et tilstrekkelig prosjekt. På en og en halv uke nådde vi stedet. Det var lettere å jobbe der fordi all kontroll over prosjektet var i hendene på arrangørene, det var ikke nødvendig å koordinere med andre komiteer. Det var enklere og lettere å jobbe i Kazan, og det var ganske normalt at det ble mindre tid.
Dmitriy: Men bestemte du deg for å la tilnærmingen til synkronisering være som den var, basert på lyd?
Andrew: Ja, vi forlot det ved lyd. Det fungerte bra. Som de sier, hvis det fungerer, ikke rør det. Vi tok ganske enkelt hensyn til nyansene i kvaliteten på lydsporet. Da de gjorde introen, var det en treningsepisode som folk kunne prøve før showet startet. Det var overraskende at når det i øyeblikket du spiller banen på stadion er det stormende applaus, "live", lar systemet deg synkronisere godt med dette sporet, men hvis innspilt applaus i dette øyeblikk blandes med banen, så sporet er ikke lenger fanget. Slike nyanser ble tatt i betraktning, og alt ble synkronisert ganske bra lydmessig.
PS I andre del av utgaven snakker vi om vitenskapelig datavisualisering, prosessmodellering i andre prosjekter, spillutvikling og masterprogrammet "" Vi vil publisere en fortsettelse i neste artikkel. Du kan lytte og støtte oss her:
PPS I mellomtiden, på den engelske versjonen av Habr: .
Kilde: www.habr.com