Oto pierwsza część transkrypcji tekstowej drugiego wywiadu dla naszego programu (, ). Gość wydania - (), doktorant, starszy pracownik naukowy w Narodowym Centrum Badań Poznawczych, profesor nadzwyczajny na Wydziale Transformacji Cyfrowych.
Od 2012 roku Andrey pracuje w grupie badawczej Wizualizacja i Grafika Komputerowa. Zaangażowany w duże projekty aplikacyjne na poziomie krajowym i międzynarodowym. W tej części rozmowy opowiadamy o jego doświadczeniach w obsłudze AR wydarzeń publicznych.
Strzał Fotek (Unsplash.com)
Kontekst i cele projektu
Kod czasowy (wg ) — 00:41
: Chciałbym zacząć od projektu Igrzysk Europejskich. Jest wieloelementowy, w przygotowaniach wzięło udział kilka zespołów, a udostępnienie rzeczywistości rozszerzonej wielotysięcznej publiczności już podczas wydarzenia na stadionie to dość poważne zadanie. Jeśli chodzi o Twoje zaangażowanie, czy najpierw było oprogramowanie?
: Tak, wykonaliśmy część programową i zapewniliśmy wsparcie podczas pokazu. Konieczne było śledzenie, monitorowanie i uruchamianie wszystkiego w czasie rzeczywistym, a także współpraca z grupą telewizyjną. Jeśli spojrzymy na ten projekt jako całość, możemy porozmawiać o ceremoniach otwarcia i zamknięcia w Mińsku, a także o ceremonii otwarcia mistrzostw w Kazaniu. To był ten sam schemat pracy, ale różne zdarzenia. Między nimi była dwumiesięczna przerwa. Projekt przygotowaliśmy wspólnie z chłopakami z firmy .
Spotkaliśmy ich przypadkiem które odbyło się jesienią 2018 r. Studenci naszego studiów magisterskich zaprezentowali swój projekt kursu na temat VR. Chłopaki podeszli do nas i zapytali, co robimy w naszym laboratorium. Wyglądało to mniej więcej tak:
— Pracujesz z VR, ale czy potrafisz pracować z rzeczywistością rozszerzoną?
- Cóż, w pewnym sensie tak.
- Jest takie zadanie z takimi wstępami. Możesz to zrobić?
Podrapali się trochę po rzepie, nie wydaje się, żeby było w tym coś nierealnego:
- Spróbujmy najpierw przestudiować wszystko, a następnie znaleźć rozwiązanie.
Dmitrij: Czy zapewniają jedynie wsparcie medialne?
Andrew: Tworzą pełny stos. Z punktu widzenia zarządzania i organizacji zajmują się całkowicie reżyserią, inscenizacją, doborem scenografii, logistyką i pozostałą obsługą techniczną. Chcieli jednak zrobić coś wyjątkowego dla Igrzysk Europejskich. Te efekty specjalne, podobnie jak rzeczywistość mieszana, są kręcone dla telewizji już od dłuższego czasu, ale nie są najbardziej budżetowe pod względem technicznym. Dlatego chłopaki szukali alternatywnych opcji.
Dmitrij: Omówmy problem bardziej szczegółowo. Z czego się składało?
Andrew: Jest wydarzenie. Trwa półtorej godziny. Musimy zadbać o to, aby widzowie oglądający transmisję na żywo oraz osoby siedzące na stadionie mogły zobaczyć efekty rozszerzonej rzeczywistości w pełnej synchronizacji z występem na żywo pod względem czasu i miejsca na stronie.
Istniało wiele ograniczeń technicznych. Synchronizacja czasu przez Internet nie była możliwa, gdyż istniały obawy o nadmierne obciążenie sieci przy pełnych trybunach i perspektywę obecności na wydarzeniu głów państw, co mogłoby spowodować zakłócenia w sieciach komórkowych.
Andriej Karsakow, fot
W tym projekcie mieliśmy dwa kluczowe elementy – osobiste doświadczenia, które ludzie mogą uzyskać za pośrednictwem urządzeń mobilnych oraz to, co trafia do transmisji telewizyjnej i ekranów informacyjnych na samym stadionie.
Jeśli nagle ktoś ogląda odcinki rzeczywistości rozszerzonej na urządzeniu mobilnym i jednocześnie trafia na ekran, powinien zobaczyć ten sam obraz.
Potrzebowaliśmy dwóch praktycznie różnych systemów, aby móc je całkowicie zsynchronizować w czasie. Ale osobliwością takich pokazów jest to, że są to złożone wydarzenia, w które zaangażowana jest duża liczba służb technicznych, a wszystkie operacje wykonywane są zgodnie z kodami czasowymi. Kod czasowy to specyficzny moment w czasie, w którym coś się zaczyna: światło, dźwięk, wychodzenie ludzi, otwieranie się płatków sceny i tak dalej. Musieliśmy się dostosować do tego systemu, aby wszystko zaczęło się w odpowiednim czasie. Kolejną cechą było to, że sceny i odcinki z rzeczywistością rozszerzoną były powiązane ze scenariuszem.
Dmitrij: Ale czy zdecydowałeś się zrezygnować ze stosowania kodów czasowych ze względu na duże ryzyko wystąpienia siły wyższej, czy też początkowo obliczyłeś pewne charakterystyki mocy i zdałeś sobie sprawę, że obciążenie całego systemu będzie dość duże?
Andrew: Jeśli utworzysz usługę synchronizacji dla takiej publiczności, nie jest to bardzo trudne. W każdym razie żądania nie zawiodą z dnia na dzień. Tak, obciążenie jest duże, ale nie jest to sytuacja awaryjna. Pytanie, czy warto poświęcać na to zasoby i czas, jeśli sieć nagle zgaśnie. Nie byliśmy pewni, że to się nie stanie. Ostatecznie wszystko działało, z przerwami ze względu na obciążenie, ale udało się i zsynchronizowaliśmy według kodu czasowego według innego schematu. Było to jedno z globalnych wyzwań.
Trudności wdrożeniowe z punktu widzenia UX
Kod czasowy (wg ) — 10:42
Andrew: Musieliśmy także wziąć pod uwagę, że stadion nie jest klasyczną salą koncertową i zsynchronizować systemy w całej przestrzeni z myślą o urządzeniach mobilnych. Więc jakiś czas temu zyskałem popularność na koncertach Eminema był wtedy przypadek Lobody.
Strzał Fotek (Unsplash.com)
Ale to zawsze jest przeżycie przed tobą – cały tłum stoi przed sceną, synchronizacja jest dość prosta. W przypadku stadionu trzeba zrozumieć, po której stronie okręgu się znajdujemy, względną pozycję, tak aby stadion wpasował się w przestrzeń istniejącą w środowisku wirtualnym. To było kwaśne wyzwanie. Próbowano to rozwiązać na różne sposoby, w wyniku czego powstał przypadek zbliżony do tego, który wdrożył Loboda, ale nie pod każdym względem.
Pozwalamy użytkownikowi decydować, gdzie się znajduje. Robiliśmy oznaczenia stadionu, gdzie ludzie wybierali sektor, rząd, miejsce. Wszystko to w czterech „kliknięciach”. Następnie musieliśmy określić kierunek na scenę. Aby to zrobić, pokazaliśmy zarys tego, jak mniej więcej powinna wyglądać scena z niestandardowej perspektywy. Połączył, zapukał i tyle – scena usiadła. Staraliśmy się maksymalnie uprościć ten proces. Mimo to 90% widzów, którzy chcieli obejrzeć program, to nie osoby, które mają doświadczenie w komunikacji z rozszerzoną rzeczywistością.
Dmitrij: Czy dla tego projektu był osobny wniosek?
Andrew: Tak, aplikacja na iOS i Androida, którą wrzuciliśmy do sklepu. Była na to osobna kampania promocyjna. Wcześniej szczegółowo opisano, jak pobrać i tak dalej.
Dmitrij: Trzeba zrozumieć, że nie ma miejsca, gdzie można fizycznie przetestować i nauczyć się obsługi takiej aplikacji. Dlatego zadanie „edukowania” publiczności stało się bardziej skomplikowane.
Andrew: Tak tak. W przypadku UX złapaliśmy wiele nierówności, ponieważ użytkownik chce uzyskać doświadczenie za pomocą trzech kliknięć: pobrać, zainstalować, uruchomić - zadziałało. Wiele osób jest zbyt leniwych, aby korzystać ze skomplikowanych samouczków, czytać samouczki i tak dalej. I nie staraliśmy się jak najlepiej wyjaśnić użytkownikowi wszystkiego w samouczku: tutaj otworzy się okno, tutaj dostęp do kamery, inaczej nie będzie działać i tak dalej. Nieważne, ile wyjaśnień napiszesz, nieważne, jak szczegółowo przeżuwasz, nieważne, jakie gify wstawisz, ludzie tego nie czytają.
W Mińsku zebraliśmy dużą pulę opinii na ten temat i już wiele zmieniliśmy w aplikacji w Kazaniu. Umieściliśmy tam nie tylko te fonogramy i te kody czasowe, które odpowiadają konkretnemu epizodowi rzeczywistości rozszerzonej, ale wzięliśmy wszystkie fonogramy i kody czasowe w całości. Tak więc aplikacja w momencie uruchomienia usłyszała, co się dzieje i – jeśli ktoś zalogował się w niewłaściwym momencie – przekazała informację: „Towarzyszu, przepraszam, twój odcinek AR będzie za 15 minut”.
Trochę o architekturze i podejściu do synchronizacji
Kod czasowy (wg ) — 16:37
Dmitrij: Czy zdecydowałeś się na synchronizację za pomocą dźwięku?
Andrew: Tak, stało się to przez przypadek. Przeglądaliśmy opcje i natknęliśmy się na firmę z Iżewska. Tworzą niezbyt wyrafinowany, ale niezawodny SDK, który pozwala zsynchronizować dźwięk z synchronizacją. System został przystosowany do współpracy z telewizorem, gdzie można wyświetlić coś w aplikacji w oparciu o dźwięk reklamy warunkowej lub zapewnić interaktywne wrażenia w oparciu o ścieżkę filmową.
Dmitrij: Ale to jedno – siedzisz w swoim salonie, a drugie – stadion z tysiącami ludzi. Jak u Was ułożyła się sprawa z jakością nagrania dźwięku i jego późniejszym rozpoznawaniem?
Andrew: Było wiele obaw i wątpliwości, ale w większości przypadków wszystko zostało dobrze rozpoznane. Budują podpisy na ścieżce audio za pomocą swoich przebiegłych algorytmów – wynik waży mniej niż oryginalny plik audio. Kiedy mikrofon słucha otaczającego dźwięku, stara się znaleźć te cechy i na ich podstawie rozpoznać utwór. W dobrych warunkach dokładność synchronizacji wynosi 0,1-0,2 sekundy. To było więcej niż wystarczające. W złych warunkach rozbieżność sięgała 0,5 sekundy.
Wiele zależy od urządzenia. Pracowaliśmy z dużą flotą urządzeń. W przypadku iPhone'ów dostępnych jest tylko 10 modeli. Działały dobrze pod względem jakości i innych funkcji. Ale z androidami zoo jest jak moja matka. Nie wszędzie okazało się, że synchronizacja dźwięku zadziałała. Zdarzały się przypadki, gdy nie można było usłyszeć różnych utworów na różnych urządzeniach ze względu na pewne osobliwości. Gdzieś znikają niskie częstotliwości, gdzieś wysokie częstotliwości zaczynają świszczeć. Ale jeśli urządzenie miało normalizator na mikrofonie, synchronizacja zawsze działała.
Dmitrij: Proszę opowiedzieć o architekturze – co wykorzystano w projekcie?
Andrew: Aplikację wykonaliśmy w Unity - najprostsza opcja pod względem wieloplatformowości i pracy z grafiką. Używany podkład AR. Od razu powiedzieliśmy, że nie chcemy komplikować systemu, dlatego ograniczyliśmy się do floty urządzeń obsługujących ARKit i ARCore, aby mieć czas na przetestowanie wszystkiego. Stworzyliśmy wtyczkę do pakietu DigitalSoft SDK, it . Stworzyliśmy system zarządzania treścią tak, aby skrypty uruchamiały się zgodnie z osią czasu.
Majstrowaliśmy trochę przy systemie cząstek, ponieważ użytkownik może wejść w dowolnym momencie konkretnego odcinka i potrzebujemy go, aby widział wszystko od momentu, w którym się zsynchronizował. Opracowaliśmy system, który pozwala na wyraźne rozgrywanie scenariuszy w czasie, dzięki czemu wrażenia XNUMXD można przewijać w przód i w tył, jak w filmie. Chociaż działa to od razu z klasycznymi animacjami, musieliśmy majstrować przy systemach cząstek. W pewnym momencie zaczynają się rozmnażać i jeśli znajdziesz się gdzieś przed punktem odrodzenia, oznacza to, że jeszcze się nie narodziły, chociaż wydaje się, że powinny. Ale ten problem jest w rzeczywistości dość łatwy do rozwiązania.
W przypadku części mobilnej architektura jest dość prosta. W przypadku transmisji telewizyjnych wszystko jest bardziej skomplikowane. Mieliśmy ograniczenia sprzętowe. Klient postawił warunek: „Tutaj mamy taki a taki park sprzętowy, z grubsza rzecz biorąc, wszystko musi nad tym popracować”. Od razu skupiliśmy się na tym, że będziemy pracować ze stosunkowo budżetowymi kartami do przechwytywania wideo. Ale budżet nie oznacza, że są złe.
Były ograniczenia sprzętowe, dotyczące kart przechwytujących wideo i warunków pracy – tego, jak powinniśmy odbierać obraz. Karty przechwytujące - Blackmagic Design, działające zgodnie ze schematem kluczowania wewnętrznego - wtedy klatka wideo przychodzi do Ciebie z kamery. Karta posiada własny układ przetwarzający, do którego wstawiana jest również ramka, którą należy nałożyć na przychodzącą. Karta je miesza – niczego innego tam nie dotykamy i nie wpływamy na kadr z kamery. Wypluwa wynik do sterowni za pośrednictwem wyjścia wideo. Jest to dobra metoda nakładania tytułów i innych podobnych rzeczy, ale nie jest zbyt odpowiednia do efektów rzeczywistości mieszanej, ponieważ istnieje wiele ograniczeń dotyczących potoku renderowania.
Dmitrij: Jeśli chodzi o obliczenia w czasie rzeczywistym, wiązanie obiektów czy coś innego?
Andrew: Pod względem jakości i osiągnięcia zamierzonych efektów. Ponieważ nie wiemy, na czym umieścimy zdjęcie. Po prostu wysyłamy informacje o kolorze i przezroczystości na górze oryginalnego strumienia. Za pomocą tego schematu nie można uzyskać niektórych efektów, takich jak załamania światła, prawidłowa przezroczystość i dodatkowe cienie. Aby to zrobić, musisz wyrenderować wszystko razem. Na przykład nie ma sposobu, aby uzyskać efekt zniekształcenia powietrza w wyniku pożaru lub gorącego asfaltu. To samo dotyczy przeniesienia efektu przezroczystości z uwzględnieniem współczynnika załamania światła. Początkowo tworzyliśmy treści w oparciu o te ograniczenia i staraliśmy się zastosować odpowiednie efekty.
Dmitrij: Czy miałeś już własne treści w pierwszym projekcie na Igrzyska Europejskie?
Andrew: Nie, główny etap tworzenia treści został przeprowadzony przez chłopaków z Sechenov.com. Ich graficy rysowali podstawową treść za pomocą animacji i innych rzeczy. I zintegrowaliśmy wszystko z silnikiem, dodaliśmy dodatkowe efekty, dostosowaliśmy tak, aby wszystko działało poprawnie.
Jeśli mówimy o rurociągu, to na potrzeby transmisji telewizyjnych zmontowaliśmy wszystko na Unreal Engine 4. Przypadkowo właśnie w tym momencie zaczęli ulepszać swoje narzędzia do rzeczywistości mieszanej. Okazało się, że nie wszystko jest takie proste. Nawet teraz wszystkie narzędzia są surowe, wiele musieliśmy wykańczać ręcznie. W Mińsku pracowaliśmy nad niestandardową wersją silnika, czyli przepisaliśmy pewne rzeczy w silniku, tak abyśmy mogli np. rysować cienie na rzeczywistych obiektach. Aktualna wówczas wersja silnika nie posiadała funkcji, które pozwalałyby na wykonanie tego przy użyciu standardowych narzędzi. Z tego powodu nasi ludzie zbudowali własny, niestandardowy zestaw, aby zapewnić wszystko, co było niezbędne.
Inne niuanse i adaptacja do WorldSkills w Kazaniu
Kod czasowy (wg ) — 31:37
Dmitrij: Ale to wszystko w dość krótkim czasie?
Andrew: Terminy były napięte , według Mińska - normalne. Około sześciu miesięcy na rozwój, ale biorąc pod uwagę fakt, że zaangażowanych było sześć osób. W tym samym czasie wykonywaliśmy część mobilną i opracowywaliśmy narzędzia do produkcji telewizyjnej. Nie było tylko wyjścia obrazu. Na przykład system śledzenia z optyką, w tym celu trzeba było stworzyć własne narzędzia.
Dmitrij: Czy były jakieś adaptacje z jednego projektu do drugiego? Czy w ciągu półtora miesiąca trzeba było skorzystać z rozwoju sytuacji i przenieść projekt z nową treścią na nową stronę?
Andrew: Tak, trwało to półtora miesiąca. Po projekcie w Mińsku zaplanowaliśmy dla całego zespołu dwutygodniowe wakacje. Ale zaraz po zamknięciu podchodzą chłopaki z Sechenov.com i mówią: „No cóż, w takim razie zróbmy Kazań”. Udało nam się jeszcze trochę odpocząć, ale dość szybko przeszliśmy do tego projektu. Zakończyliśmy prace techniczne. Większość czasu poświęcono na content, bo w przypadku WorldSkills zrobiliśmy to w całości, po prostu skoordynowaliśmy to z zespołem produkcyjnym. Z ich strony był tylko scenariusz. Ale było łatwiej – nie było potrzeby wykonywania dodatkowych iteracji. Gdy samodzielnie tworzysz treść, od razu widzisz, jak ona działa w silniku, możesz ją szybko edytować i koordynować.
Jeśli chodzi o część mobilną, wzięliśmy pod uwagę wszystkie subtelności, które mieliśmy w Mińsku. Zrobiliśmy nowy projekt aplikacji, przeprojektowaliśmy trochę architekturę, dodaliśmy tutoriale, ale staraliśmy się, aby było to możliwie krótkie i przejrzyste. Zmniejszyliśmy liczbę kroków użytkownika od uruchomienia aplikacji do przeglądania treści. Na wykonanie odpowiedniego projektu wystarczyło półtora miesiąca. Po półtora tygodnia dotarliśmy na miejsce. Tam było łatwiej pracować, bo cała kontrola nad projektem była w rękach organizatorów, nie było potrzeby koordynowania działań z innymi komitetami. W Kazaniu było łatwiej i łatwiej pracować i to normalne, że czasu było mniej.
Dmitrij: Czy jednak zdecydowaliście się na pozostawienie dotychczasowego podejścia do synchronizacji, opartego na dźwięku?
Andrew: Tak, zostawiliśmy to przy dźwięku. To działało dobrze. Jak to mówią, jeśli coś działa, nie dotykaj tego. Po prostu wzięliśmy pod uwagę niuanse jakości ścieżki audio. Kiedy robili wprowadzenie, widzowie mogli wypróbować odcinek szkoleniowy przed rozpoczęciem programu. Zaskakujące było to, że gdy w momencie odtwarzania utworu na stadionie słychać burzliwe brawa, „na żywo”, system pozwala dobrze zsynchronizować się z tym utworem, natomiast jeśli w tym momencie nagrane brawa zmieszają się z utworem, to ślad nie jest już uchwycony. Takie niuanse zostały uwzględnione i wszystko zostało dźwiękowo zsynchronizowane całkiem nieźle.
PS W drugiej części numeru rozmawiamy o wizualizacji danych naukowych, modelowaniu procesów w innych projektach, tworzeniu gier i programie magisterskim”" Kontynuację opublikujemy w następnym artykule. Tutaj możesz nas słuchać i wspierać:
PPS Tymczasem w angielskiej wersji Habr: .
Źródło: www.habr.com