Qualcomm werkt aan vr-toepassing via streamingtechnologie zonder videobeelden

Wetenschappers en Qualcomm werken aan commerciële exploitatie van wat de onderzoekers omschrijven als een nieuwe streamingtechniek voor vr-brillen. Hierbij wordt data gestreamd; dat vergt minder bandbreedte en kan leiden tot hoogwaardige vr-toepassingen op goedkope brillen.

Volgens de Oostenrijkse onderzoekers van de Graz University of Technology, die onder leiding staan van hoogleraar Dieter Schmalstieg van het Institute of Computer Graphics and Vision, betreft het een methode waarin de voordelen van cloudcomputing en vr worden gecombineerd. De wetenschappers stellen dat het uitvoeren van berekeningen door servers de potentie heeft om vr-games op een hoger niveau te krijgen, maar dat de bandbreedtevereisten nog altijd een uitdaging vormen. Volgens hen loopt de inzet van traditionele videotransmissie, waarbij via een internetverbinding in feite een videostream naar de eindgebruiker wordt gestuurd, tegen zijn grenzen aan bij vr-toepassingen.

Hun eerder ontwikkelde methode noemen ze shading atlas streaming, die volgens de wetenschappers de potentie heeft om een doorbraak te betekenen voor draadloze vr-toepassingen, waarbij de vr-bril niet via een draad vastzit aan bijvoorbeeld een pc die alle berekeningen uitvoert. Met deze methode worden geen video's gestreamd, maar alleen de zichtbare geometrie en een soort overkoepelende atlas die de shadinginformatie bevat. Aan de kant van de client, dus door de vr-bril, wordt die data vervolgens gecombineerd. Dat leidt volgens de onderzoekers tot een veel lagere benodigde bandbreedte, zonder dat wordt ingeboet aan kwaliteit.

Dit systeem vormt ook een oplossing voor latency. Volgens Schmalstieg is het fysiek onmogelijk om alle latency te verwijderen, maar de methode van de onderzoekers maakt het mogelijk om correcte afbeeldingen te voorspellen gedurende een kort toekomstig tijdsvenster. Dat betekent dat de gebruikers volgens Schmalstieg geen latency zullen ervaren. Om hun technologie in te passen in bestaande infrastructuur, wordt conventionele mpeg-videocompressie toegepast om de data te coderen en versturen.

Reacties (11)

Als ze dit daadwerkelijk voor elkaar krijgen dan gaat dat VR in één keer een enorme boost geven. Hoop dat het haalbaar is!

Ik geloof er niks van. Microsoft kon cloud computing ook niet goed genoeg laten werken op de Xbox One om ook zelfs maar in 1 game toe te passen. En voor de Oculus Quest heb je een dure kabel nodig om VR via de PC te streamen en dan is er alsnog meer latency en gaat het ten koste van de videokwaliteit. Draadloos lukt ze nog niet eens en 3rd party toepassingen zijn ook niet helemaal ideaal. En dan gaat Qualcomm beweren dat zij iets kunnen dat op een compleet ander niveau zit? Ze zijn misschien een gigagroot bedrijf, maar dit is echt niet iets wat op korte termijn mogelijk zal zijn.

[Reactie gewijzigd door RedHeroDude op 2 december 2019 19:11]

Je hebt het nu steevast over pre-rendered materiaal. Deze oplossing is een combinatie van cloud en local computing. De zware berekeningen worden op de server gedaan en de laatste stap is het renderen op de PC waarbij dus al een flink deel elders is gedaan. Er zijn in een beeld een paar miljoen pixels maar slechts enkele honderdduizenden polygonen. Als je per polygon efficiënt data kan versturen over de weergave kan je de laatste stap snel op locatie doen.

Het is wel degelijk mogelijk net de huidige technologie. Zo is er nu al een oplossing voor de HTC Vive en Vive Pro dezelfde basis met de nieuwste componenten van Intel zouden prima de Index op 120Hz kunnen draaien. Het punt is dat Intel deze componenten nog niet in grote aantallen maakt aangezien er nog geen klanten voor zijn.
Op de /r/ValveIndex reddit zijn er al een aantal mensen bezig geweest met de berekeningen.

Omdat het iets volledig anders is.
In plaats van video sturen ze een deel pre-processed mesh data zodat de wireless headset deze kan combineren met die atlas data. De wireless headset neemt dus een deel van de processing over.
Ipv 2 keer 4k video over een wireless verbinding te sturen, sturen ze de textures een keer, en dan gewoon mesh data hoe die in de viewport verandert. Slim gezien.
Aangezien het nog altijd op de remote headset gerendered wordt, gaat het weer onderworpen zijn aan hoe goed deze headset graphics kan laten zien natuurlijk. Maarja die kan dan eventueel een lagere textureatlas nemen voor het makkelijker te maken.

Volgens mij moet je streamen in dit geval niet zien als een technische verbetering maar een truukje dat er eenrichtingsverkeer van maakt om fouten te kunnen negeren. Het resultaat zal 'glitchy' worden in ruil voor dat het vaker werkt met meer hardware. Er is geen bi-directioneel protocol meer dat feedback behandelt en eisen stelt aan beide kanten. Gevolg is dat de ontvangende kant, dus het display-apparaat, gewoon pech heeft als er iets niet klopt en er maar wat van moet zien te maken totdat het volgende frame aan de beurt is.

btw, hoogwaarde -> hoogwaardigere?

[Reactie gewijzigd door blorf op 2 december 2019 19:43]

Vergelijk het met een corrupte mp3. Of je speelt een bestand af in een player die op zijn bek gaat, of je accepteert het als stream met een constante transfer rate. die wel of niet correct interpreteerbaar is maar na een foutje wel gewoon door gaat, ook al is die goed hoorbaar.
Dat geometrie-verhaal is als je het mij vraagt gewoon verkapt een lineaire compressiemethode om de transfer-data kleiner te maken. Het gaat misschien uit van een format, dus een enigzins VR-dedicated methode die bij random data minder goed zou werken of helemaal zinloos zou zijn.

[Reactie gewijzigd door blorf op 2 december 2019 20:33]

klinkt leuk in theorie, maar zal in de praktijk enkel in wat demo's getoond worden en dan verder in de vergeetput wegrotten

Zo zag ik ook eens een oplossing for meer pixels door dubbele LCD schermen te gebruiken, het resultaat was waanzinnig goed maar daarna nooit meer wat van vernomen

Klinkt leuk maar ik zie de volgende struikelblokken:

• renderen 'in' de bril vergt heel wat meer compute power dan een dom display
• mpeg leent zich juist erg slecht voor het comprimeren van niet-video data omdat het een lossy algoritme betreft dat geoptimaliseerd is in het weglaten van video-details die het oog toch niet kan zien