Roblox biedt onderdak aan miljoenen ervaringen, van eenvoudige minigames tot uitgestrekte open werelden vol met hoogwaardige 3D-assets. Ons doel is om de steeds intensievere en complexere ervaringen te ondersteunen die makers voor ogen hebben op een breed spectrum aan gebruikersapparaten, wat innovatie vereist in onze engine, contentleveringssystemen en infrastructuur. Scalable Lightweight Interactive Models, of SLIM, is een onderdeel van een meerdelig ontwikkelingsproject dat makers in staat stelt hun grootse artistieke visies te realiseren zonder in te boeten aan prestaties. 

Met SLIM kunnen makers automatisch lichtgewicht weergaven maken van elk object in een Roblox-ervaring, waardoor het aantal draw calls, driehoeken en datamodelinstanties dat de client nodig heeft om een robuuste, naadloze wereld weer te geven, tot een minimum wordt beperkt. SLIM biedt ons streamingmodel krachtige nieuwe manieren om content te optimaliseren, waardoor een gebruiker met een high-end gaming-pc en een gebruiker met een low-end mobiel apparaat dezelfde ervaring kunnen delen met de hoogste kwaliteit die hun apparaat aankan.

Twee pijlers van streaming: instances en assets

Wanneer u een film bekijkt op uw favoriete streamingdienst, downloadt uw apparaat niet het volledige bestand voordat u begint met kijken. Het downloadt net genoeg gegevens om direct te kunnen beginnen met kijken, en downloadt (of buffert) vervolgens continu de volgende paar seconden, zodat de ervaring niet wordt onderbroken. Als je streamt op een minder krachtig apparaat of via een trage verbinding, past het platform zich automatisch aan door je een versie van de content met lagere kwaliteit te sturen, terwijl het genoeg data downloadt om de content in hoge kwaliteit te streamen. 

Roblox gebruikt een soortgelijk concept om content on-the-fly te streamen, maar de data die nodig is om een 3D-simulatie met hoge kwaliteit weer te geven, brengt zijn eigen uitdagingen met zich mee. Terwijl een video een lineaire tijdlijn van content heeft die vanuit één perspectief wordt bekeken, bevatten Roblox-ervaringen enorme, interactieve 3D-werelden vol met allerlei soorten assets die vanuit vele perspectieven kunnen worden bekeken, die door de gebruiker worden bestuurd. Voeg daar 151,5 miljoen dagelijkse actieve gebruikers aan toe die spelen, verkennen en uiteindelijk content streamen vanaf een breed scala aan apparaten, en er is een enorm potentieel voor het optimaliseren van de manier waarop content wordt geleverd en weergegeven.¹

Alles wat een gebruiker op Roblox ziet – een auto, een boom, een avatar of een gebouw – wordt binnen de engine weergegeven als een aantal instanties. Een bruikbare auto wordt bijvoorbeeld opgesplitst in instanties voor de bumpers, deuren, wielen, enzovoort. Elke instantie wordt in de ervaring opgebouwd met behulp van meerdere assets, zoals 3D-meshes, texturen, animaties en audio.

Bijna alle streaming op Roblox is onderverdeeld in twee kerntechnologieën: instantie-streaming en asset-streaming.

• Instance-streaming bepaalt welke instances het apparaat van een gebruiker moet streamen. Het is niet nodig om delen van de ervaring te streamen die de gebruiker nog niet kan zien of waarmee hij nog geen interactie kan hebben. In het bovenstaande voorbeeld worden alleen de instances die de nabijgelegen gebouwen vertegenwoordigen naar de client gestreamd.
• Assetstreaming bepaalt de kwaliteit van de gestreamde instances. Het is niet nodig om een 4K-textuur met hoge resolutie te downloaden voor een berg die zo ver weg is dat de gebruiker de fijne details niet kan onderscheiden. In de afbeelding hierboven maken gebouwen in de verte en gebouwen die weinig schermruimte innemen gebruik van gedecimeerde meshes en texturen met een lagere resolutie. 

Het centrale brein voor deze operatie is een systeem dat we Harmony noemen, dat elke frame de beschikbare bronnen van elke gebruiker controleert. Harmony past zowel de instantiestreaming als de assetstreaming aan om de beste ervaring te bieden op basis van het geheugen van het apparaat, de GPU- en CPU-belasting en de netwerkbandbreedte. Voor een high-end gaming-pc zet Harmony alles op de hoogste kwaliteit. Voor een mobiel apparaat met een zwakke verbinding schakelt het automatisch terug om de gebruikerservaring soepel te houden.

Het team besprak de technologie achter streaming, cloudtranscodering en SLIM in aflevering 30 van de Tech Talks-podcast. 

SLIM: Schaalbare, lichtgewicht interactieve modellen

Het kernidee van SLIM is eenvoudig maar krachtig: SLIM kan automatisch meerdere lichtgewicht, geoptimaliseerde weergaven van elk object of model in de wereld van een maker creëren en deze op de server opslaan om tijdens de uitvoering te worden opgehaald. De client van elke gebruiker kan vervolgens dynamisch schakelen tussen het weergeven van de originele instanties en assets of een van de lichtgewicht SLIM-weergaven, op basis van de beschikbare bronnen van het apparaat. 

SLIM maakt gebruik van twee belangrijke technieken om een lichtgewicht weergave te genereren:

1. Compositing

Ten eerste combineert SLIM meerdere onderdelen tot minder onderdelen. In plaats van dat de onderstaande auto 112 afzonderlijke meshes en 24 afzonderlijke texturen nodig heeft, heeft de lichtgewicht weergave ervan mogelijk slechts één mesh en vier texturen nodig. Het compositingproces is nauwkeurig afgestemd op de manier waarop de engine de inhoud uiteindelijk zal weergeven, waardoor onzichtbare geometrie binnen een object wordt geëlimineerd en het aantal draw calls dat nodig is om het weer te geven, wordt verminderd.

2. Detailniveau (LoD)

Na het samenstellen van het model genereert SLIM meerdere versies met verschillende detailniveaus. Dit betekent dat er versies van de 3D-mesh worden gemaakt met aanzienlijk minder driehoeken en dat er texturen worden gegenereerd met veel lagere resoluties, zoals we dat ook doen met individuele mesh- of textuurasets met behulp van traditionele LoD-technieken. Deze technieken kunnen verder worden geoptimaliseerd wanneer ze worden toegepast op SLIM-modellen, omdat we beschikken over de individuele coördinatenkaders van elke onderliggende instantie. Dit geeft ons volledige inzicht in hoe de maker bedoelde dat elk van deze assets samen moest worden weergegeven. Met deze kennis stelt SLIM ons in staat om beter geïnformeerde beslissingen te nemen over waar onnodige details moeten worden verwijderd en waar de details moeten worden behouden die gebruikers zullen opmerken.

De juiste weergave op het juiste moment

Zodra we meerdere weergaven van een object hebben gemaakt, moet SLIM beslissen welke weergave voor het apparaat van een specifieke gebruiker moet worden gebruikt, of dat er in plaats daarvan traditionele weergavetechnieken moeten worden gebruikt. Het systeem verdeelt de wereld in drie verschillende regio's. Een eenvoudige manier om deze regio's voor te stellen, is door je concentrische cirkels van details voor te stellen die zich vanuit de speler naar buiten uitstrekken.

HH-regio (zware instanties, zware weergave)

In de HH-regio worden volledige, zware instanties vanaf de server naar het client-datamodel gestreamd, en bepaalt de client voor elke instantie welke specifieke assetweergave moet worden gedownload en weergegeven. Schaalbaarheid kan in deze regio nog steeds worden bereikt met mesh-LoD's en textuur-mips, maar er is geen compositing. Vóór SLIM werd elke instantie die naar een ervaring werd gestreamd op deze manier weergegeven. 

HL-regio (zware instanties, lichte weergave) 

De HL-regio bevindt zich tussen de HH- en LL-regio's. In deze regio heeft de client de zware instances in het datamodel, maar kan hij kiezen om te renderen met behulp van de volledige renderpijplijn of de SLIM-pijplijn. Deze regio past zich aan om een naadloze overgang tussen de HH- en LL-regio's te garanderen, zelfs als de gebruiker te maken krijgt met netwerklatentie. Het overgangspunt tussen de HH- en HL-regio's is dynamisch, waardoor Harmony onmiddellijk kan opschalen of afschalen als reactie op een piek in de benodigde resources in beide richtingen.

LL-regio (lichtgewicht instanties, lichtgewicht weergave) 

In de LL-regio streamt de client alleen superlichtgewicht weergaven van instanties die nodig zijn om een coördinatenkader voor een SLIM-model te definiëren, samen met de absolute minimale metadata. In deze regio worden alleen lichtgewicht samengestelde SLIM-modellen weergegeven, in plaats van elke afzonderlijke instantie en asset. De LL-regio vereist veel minder driehoeken en draw calls, en vermindert het geheugengebruik op het apparaat van de gebruiker in vergelijking met het streamen van elke zware instantie en het gebruik van de traditionele renderpijplijn.

Deze regio-techniek stelt de client in staat om de volledige zichtbare wereld te allen tijde te renderen zonder de volledige rekenkosten te dragen die gepaard gaan met het gelijktijdig gebruiken van elke zware instantie en asset. Verre objecten zijn sterk geoptimaliseerde, lichtgewicht weergaven, die worden vervangen door hun high-fidelity tegenhangers naarmate de gebruiker dichterbij komt. Het vermogen van SLIM om composities en meerdere geschaalde LoD-modellen te creëren, geeft Harmony meer mogelijkheden om de assetkwaliteit voor het apparaat van elke gebruiker te optimaliseren.

Wanneer alles samenkomt, zou de speler zich volledig ondergedompeld moeten voelen en geen van de overgangen of variërende detailniveaus moeten opmerken.

De toekomst: hoe gaat het nu verder met SLIM?

SLIM is slechts de eerste stap in een reis die uit meerdere stappen bestaat, en we zijn benieuwd hoe makers de technologie in hun workflows gaan integreren. We onderzoeken hoe we SLIM in de toekomst in twee hoofdrichtingen kunnen uitbreiden. 

Bepalen wat er nog meer met SLIM kan worden gedaan 

We beginnen met de statische modellen die makers in Studio aanwijzen, maar in de toekomst zal SLIM in staat zijn om enkele van de meest complexe modellen op Roblox te optimaliseren: platformavatars. Avatars, met al hun bijbehorende animaties, gelaagde kleding en accessoires, kunnen een onvoorspelbare variabele zijn voor makers. Door avatars te laten SLIM-en, kan de engine de resources die een individueel avatarmodel gebruikt effectief beperken.

Uiteindelijk willen we makers de mogelijkheid bieden om SLIM te gebruiken voor wijzigingen aan dynamische modellen. Stel je een model voor waarbij de server actief wijzigingen kan aanbrengen (bijvoorbeeld een deur die opengaat of een onderdeel dat wordt vernietigd), maar waarbij de client met een paar slimme trucs dezelfde lichtgewicht weergave kan hergebruiken.

De SLIM-pijplijn optimaliseren 

Nu we een end-to-end-pijplijn hebben die de engine een nieuwe dimensie van flexibiliteit biedt, richten we ons ook op het slimmer, sneller en efficiënter maken van de pijplijn zelf. Dit omvat:

• Herindeling van texturen: meerdere modeltexturen op een slimme manier samenvoegen tot één geoptimaliseerd textuurblad.
• Automatische segmentatie: automatisch gebruikmaken van semantisch en ruimtelijk inzicht in de wereld om de beste SLIM-geschikte modellen te identificeren.
• Lichtere representaties: voor dynamische objecten die minder afhankelijk zijn van latentie, onderzoeken we het genereren van 2D-representaties die vrijwel geen resources vergen om op de client te renderen.
• Hiërarchische SLIM: SLIM-modellen achter elkaar nesten, zodat hele groepen instanties kunnen worden vereenvoudigd en de engine dynamisch kan kiezen tussen verschillende niveaus van gedetailleerdheid – bijvoorbeeld van een enkele boom naar een bos naar een heel landmass vol bossen en andere objecten.
• Up-rezzing: Vandaag richten we ons op het optimaliseren van de prestaties, maar zeer binnenkort zal ditzelfde systeem ons in staat stellen om de resolutie van assets te verhogen voor toekomstige hardware, met behoud van de oorspronkelijke artistieke intentie van de maker. Deze nieuwe architectuur betekent dat naarmate onze engine beter wordt in het simuleren van de werkelijkheid, we de representaties die deze gebruikt voortdurend kunnen upgraden. 

SLIM, in combinatie met Harmony en de rest van onze streaming- en contentleveringsarchitectuur, is een enorme sprong voorwaarts in onze visie om uitgebreidere en gedetailleerdere werelden voor meer spelers te ondersteunen. De nauwe integratie van onze engine, contentlevering en cloudinfrastructuur, in combinatie met de enorme contentbasis van miljoenen makers, stelt ons in staat om diep onderling verbonden systemen te bouwen die de hele ervaring verbeteren. Naarmate onze engine beter wordt in het simuleren van de werkelijkheid, kunnen we de weergaven die deze gebruikt voortdurend upgraden. Vandaag richten we ons op het optimaliseren van de prestaties, maar zeer binnenkort zal ditzelfde systeem ons in staat stellen om assets op te schalen voor toekomstige hardware, met behoud van de oorspronkelijke artistieke intentie van de makers.

We bouwen een platform dat niet alleen die artistieke intentie respecteert, maar ook op een intelligente en automatische manier hun creaties kan leveren aan elke gebruiker op een breed scala aan apparaten, overal waar Roblox beschikbaar is. We kunnen niet wachten om te zien wat de community hiermee gaat bouwen.