Transcription intégrale

Dave : Bonjour, je suis Dave Baszucki, fondateur et PDG de Roblox, et vous écoutez ou regardez Tech Talks. Aujourd’hui, nous allons parler de ce qui caractérise un moteur de jeu de deuxième génération, de son intégration au cloud et de la manière dont nous aidons les utilisateurs à se connecter instantanément en haute résolution. Nous avons ici la dream team technique de Roblox.

Nous avons donc Varun Mani, Sergey Makeev et Tsvetan Tsvetanov, et nous allons nous plonger dans tout ce qui touche au streaming. Euh, nous allons parler de Slim, nous allons parler de transcodage des ressources, de tout ce qui permet à Roblox de prendre en charge, au final, cent mille joueurs. Si l'on regarde l'industrie du jeu vidéo au cours des 10 ou 20 dernières années.

Il y a une méthode traditionnelle pour que tout ce contenu 3D s'affiche devant vous, et... euh... et cette méthode traditionnelle pose quelques problèmes. Parce que ce qu'on essaie de faire chez Roblox, c'est de permettre une connexion instantanée. Euh, nous essayons de faire en sorte que les mêmes expériences fonctionnent aussi bien sur un téléphone que sur un gros PC. Euh, nous essayons de le faire sans aucune latence, et quand on regarde comment fonctionnent les jeux traditionnels, ce n'est pas tout à fait pareil, n'est-ce pas ?

Je me souviens, euh, à mon époque, ils étaient distribués sur ces trucs appelés disquettes. Mais même aujourd'hui, on distribue les jeux sur... de gros DVD, je crois. C'est bien ça ? 

Varun : Oui. Et je pense que la clé, c'est que tout est regroupé dans un seul paquet. Oui. N'est-ce pas ? Donc, qu'il s'agisse d'un DVD ou d'un téléchargement de jeu aujourd'hui, ça arrive sous la forme d'un énorme paquet qu'on ne peut pas, qu'on ne peut pas diviser.

Il faut donc attendre que les 4,7 Go, voire 10 Go dans certains cas, soient entièrement téléchargés avant de pouvoir commencer. 

Sergey : Oui. Et comme l’a dit Varun, pour certains jeux, ça peut faire, tu sais, genre 20 ou 40 Go, et tu dois attendre super longtemps avant de pouvoir commencer à jouer. Et ça, en quelque sorte, ça casse le rythme, non ?

Parce que, tu veux jouer, tu as peut-être une heure ou deux après le travail, tu veux jouer à un jeu, et là tu dois attendre 30 ou 40 minutes pendant les mises à jour et tout ça. C'est à peu près ce que je vis quand je joue. Genre 

Dave : alors, n’est-ce pas un peu similaire à ce qu’on a vu avec les vidéos et les films ?

Je me souviens de l'époque où les films étaient distribués sur DVD, puis je me souviens de l'époque de BitTorrent, par exemple. On téléchargeait le film en entier, et puis finalement on en est arrivés à pouvoir aller sur Amazon, Netflix, Hulu ou Tubi et regarder le film tout de suite. Mais je ne pense pas que ce soit encore tout à fait le cas sur le marché du jeu vidéo.

Pas encore. Pas encore. Je ne pense pas que ce soit déjà le cas. 

Tsvetan : Nous sommes les seuls à viser 

Dave : ça. Donc, historiquement, Roblox a toujours fonctionné comme ça, en coulisses, euh. La plupart des gens ne le remarquent peut-être pas, mais quand tu vas sur la page d’accueil de Roblox et que tu cliques sur « Jouer », tu peux rejoindre le jeu instantanément. C’est en fait très peu conventionnel, parce que quand je suis sur certaines plateformes de jeux très sophistiquées, euh, j’ai déjà vu des téléchargements atteindre 200 gigaoctets avant de pouvoir jouer.

Donc, on propose déjà ce jeu instantané ? Oui. 

Tsvetan : Euh, Roblox est, à ma connaissance, la seule plateforme qui permet de rejoindre et de jouer instantanément. Ah oui, 

Varun : ouais, désolé. Et, c'est un peu comme quand tu parlais du streaming vidéo, non ? Genre, qu'est-ce que tu fais en réalité quand tu regardes une vidéo en streaming ? Je ne veux pas télécharger le film en entier, je télécharge juste la partie du film qui est devant moi, et on appelle ça la mise en mémoire tampon.

Je, je diffuse le film en streaming. C'est ça ? C'est vrai, mais ça ne concerne qu'une seule dimension. Parce qu'il n'y a qu'une dimension temporelle là-dedans. Ouais, c'est la différence essentielle ici. C'est ce qui est difficile à faire dans Roblox, parce que c'est un monde 3D entièrement interactif où il faut diffuser à la fois les instances et les ressources, qui sont en quelque sorte les éléments de base de tout ce qui se trouve dans 

Dave : Roblox A a et euh, je dirais que ça a rendu les choses encore plus difficiles parce que sur le marché traditionnel des jeux vidéo.

j'ai tendance à voir différentes versions de jeux, par exemple sur un PC haut de gamme et un mobile bas de gamme. Et ce que j'en pense, la façon dont j'interprète ça, c'est que sur les PC haut de gamme, où je peux télécharger des centaines de gigaoctets, on va avoir ces ressources vraiment énormes et complexes, et sur mobile, c'est presque comme si les créateurs, je pense, faisaient une version distincte 

Sergey : à un certain niveau.

Euh, oui. C'est un très bon point, parce que dans les jeux traditionnels, tu sais, ils ont ce processus qu'on appelle « asset cooking ». Donc ils préparent une version très optimisée, disons, pour chaque plateforme. Et si tu y réfléchis d'un point de vue plus, disons, de streaming vidéo, c'est un peu comme sur un DVD.

Euh, la vidéo n'a été encodée qu'une seule fois, c'est ça ? Ouais. Mais sur n'importe quelle plateforme de streaming, ils ont plusieurs encodages pour la même vidéo, donc ça s'adapte en quelque sorte automatiquement à ton appareil. Et, euh, tous les jeux actuels, tu sais, ils pré-préparent leurs ressources, en quelque sorte, et les livrent de manière très spécifique, comme en triplex ici.

Nous sommes donc capables de générer une version optimisée d’un élément par plateforme sur le cloud. C’est ça. 

Dave : Bon, gardez ça en tête, d'accord ? Parce qu'il y a quelque temps, on avait cette vision : si vous êtes un jeune créateur et que vous développez votre expérience, elle peut fonctionner dans n'importe quel langage. On avait cette vision qu'elle puisse fonctionner sur n'importe quel appareil et s'afficher en différentes résolutions sur n'importe quel appareil.

On va, on va se plonger dedans. Donc, donc, donc le marché traditionnel du jeu vidéo, tu sais, en boîte ou en téléchargement. Euh, on veut résoudre ces problèmes d’accès instantané, de publication sur n’importe quel appareil, de faible latence et tout ça à la fois. Et donc on va parler aujourd’hui de quelque chose qui s’appelle littéralement le streaming 3D et 40.

On va parler de, euh, contenus dans le cloud. On va parler de quelque chose appelé « slim », qui, je pense, va vraiment enthousiasmer tout le monde. Et donc peut-être, euh, pour entrer dans le vif du sujet, Varun, d’abord un petit aperçu de ce qu’est « slim » et de quoi il s’agit. Euh, on appelle ça « cloud Transco ». Ouais. Et qu’est-ce que tout ça signifie ? 

Varun : Bon, si on prend un peu de recul, notre vision globale, c'est d'essayer d'atteindre 10 % du marché du jeu vidéo.

Oui. Pour y parvenir, nous donnons aux créateurs une liberté totale sur ce qu’ils développent. Euh, et si l’on réfléchit à notre croissance, il y a en quelque sorte deux dimensions. On peut soit développer la plateforme, soit élargir les genres. Le développement de la plateforme consiste à faire en sorte que le même contenu fonctionne sur n’importe quelle plateforme.

Donc, vous créez une seule fois. Roblox, s'assure que ça fonctionne partout. Et pour l'élargissement des genres. Nous voulons que vous créiez des choses de plus en plus impressionnantes et de plus en plus folles. 

Dave : Et quand tu dis « fonctionner partout », littéralement, imagine quelque chose de vraiment énorme, de fou et d’amusant. Grand Theft Auto, Red Dead Redemption, sur une console haut de gamme.

Fonctionnant sur un téléphone Android de 2 Go et tout ce qui se trouve entre les deux. C'est ça. Pour 

Varun : du PC jusqu'à un Android de 2 Go, ça devrait simplement fonctionner sans que le créateur ait à faire d'efforts supplémentaires. C'est donc ça, la vision. Exactement. Le cloud, le transcodage et Slim ne sont que deux des premières étapes que nous avons commencées pour nous engager dans cette voie.

Dave : D'accord, c'est un petit avant-goût. On va expliquer ce qu'est Slim et on va expliquer... Je pense que tu vas probablement expliquer ce qu'est le transcodage, mais commençons par présenter tout le monde. Alors Sergey, hum, tu es de retour, peux-tu nous parler un peu de ton expérience en optimisation de moteurs ? C'est l'une des choses les plus amusantes au monde, n'est-ce pas ?

Le langage assembleur C++, comme le CmD, par exemple, peux-tu nous parler un peu de ce sur quoi tu as travaillé ? 

Sergey : Euh, ouais, donc comme tu l’as mentionné tout à l’heure, ouais, j’ai surtout bossé sur des jeux, et en fait, toute ma vie, j’ai fait ce genre d’optimisations, en commençant par la Xbox régionale et tout ça.

Euh, et... Tu sais, quand j'ai découvert Roblox pour la première fois, j'ai été complètement époustouflé par cette idée d'un jeu créé une seule fois, ou plutôt, pas vraiment un jeu. Plutôt une expérience créée une seule fois, qui peut ensuite fonctionner partout, sur n'importe quelle plateforme, sur n'importe quel appareil, sans nécessiter aucune intervention supplémentaire de la part de l'utilisateur.

Et c'est un problème d'ingénierie extrêmement difficile. Euh, comme, euh, comme tout le monde peut l'imaginer, n'est-ce pas ? Donc, euh, et ça nécessite beaucoup de, euh, tu sais, d'optimisations traditionnelles, comme le CMD, le multi-trading, une gestion très minutieuse du GPU, la planification, tout ça. Mais en même temps, tu sais, il y a comme une limite, euh, sur la quantité de ressources qu'on peut faire évoluer sur un seul appareil.

Heureusement pour nous, on a toujours notre cloud, n'est-ce pas ? Donc, on peut télécharger une partie de ce travail sur notre cloud et aider ces appareils à effectuer le rendu plus efficacement pour afficher des murs plus grands. Dans une certaine mesure, par exemple, on peut afficher des murs qui ne tiennent même pas dans la mémoire d’un appareil physique, car ils existent aussi côté serveur, et le serveur aide tous les clients à les afficher efficacement.

Dave : Ouais. Et donc, juste pour souligner un point, je pense qu’une partie de ce qu’on va partager là-dessous, c’est que les moteurs de jeu traditionnels sont généralement écrits en C++, et on télécharge toutes les ressources. Mais disons qu’un jeu auquel tu voudrais jouer représente le monde entier, par exemple : personne ne peut mettre le monde entier sur un DVD.

Et donc ce que tu veux vraiment dire, et on le voit déjà avec Google Maps et d'autres services de ce genre. Il est impossible de mettre tout ça au même endroit. Et donc, une partie de ce dont nous allons parler quand nous parlons de streaming, c'est la même chose pour les jeux, et ensuite... Pouvez-vous nous dire comment vous êtes arrivé chez Roblox, quel est votre parcours, et peut-être nous donner un petit aperçu de ce qu'est le transcodage dans le cloud ?

Donc, 

Tsvetan : euh, avant de rejoindre Roblox, j’ai acquis mon expérience professionnelle dans deux domaines. Le premier est celui des logiciels de conception et de simulation 3D pour l’architecture, la construction et l’ingénierie mécanique. Et le second était le calcul distribué à grande échelle. Je peux appliquer mes connaissances issues de ces deux domaines à Roblox, car c’est en gros ce qu’est Roblox.

Dave : Oui. Passons au streaming sur Roblox et parlons-en. Bon, on sait ce qu’est le streaming vidéo. Le streaming vidéo, c’est en quelque sorte un processus linéaire, n’est-ce pas ? Il suffit d’une image. On envoie les images les unes après les autres. Peux-tu nous expliquer ce que le streaming signifie en 3D et en temps réel ? 

Varun : Si tu regardes bien, presque tout dans un jeu Roblox aujourd’hui est constitué d’instances ou d’assets, n’est-ce pas ?

Des instances, en quelque sorte la structure du monde. Et puis un asset, c'est ce qui anime réellement cette instance pour le contenu proprement dit. Euh, si on pense au streaming, il s'agit de diffuser des instances et de diffuser ces assets également. C'est ce qu'il faut faire. Donc si, dans un flux vidéo, on n'a qu'un seul asset, c'est la vidéo.

Dans Roblox, on fait ça des milliers, des dizaines de milliers de fois, euh, encore et encore. Donc quand on parle de streaming instantané, on essaie juste de diffuser suffisamment du monde qui nous entoure sans savoir ce que le joueur va faire. Le joueur pourrait marcher par là, ou par là. On veut diffuser juste ce qu’il faut, ou mettre en mémoire tampon juste ce qu’il faut du monde.

Et ensuite, dans ce monde que vous avez mis en mémoire tampon, vous voulez mettre en mémoire tampon les ressources avec exactement la bonne qualité. Donc, comme l’a mentionné Sergei, vous avez différents niveaux de qualité pour la vidéo. C’est pareil pour les maillages, et pareil pour les images. 

Dave : Donc, si on décompose tout ça, serait-il juste de dire que les instances sont des choses qui nous sont familières ?

Une voiture, un arbre, une autre personne, une colline, quelque chose comme ça. Et puis les ressources sont les éléments techniques qui composent ces instances. Comme à l’intérieur de ces objets 3D. Quand on est tous sur un jeu, on a des grappes de triangles, on a des grappes de textures, et donc on parle de choisir lesquelles on va

À charger à tout moment. 

Varun : Ouais. Et de quelle représentation de ceux-ci. Donc, quand tu te promènes, que tu traverses le monde, c'est comme si, euh, l'appareil disait : « OK, je veux cet arbre », ou « j'ai besoin de cet arbre ». Cet arbre est composé d'un tas de maillages et d'un tas de textures, et peut-être même, à l'avenir, d'animations, d'audio, etc.

Donc, il prend une décision. D'accord. En fonction de la position de cet arbre, de son importance, de l'espace qu'il occupe à l'écran. Je veux la texture en haute qualité. Je veux le maillage en qualité moyenne. Et puis l'audio, peut-être que je n'ai pas encore besoin de l'audio, donc ne retarde pas l'audio. Donc, il prend constamment ces décisions, 

Dave : donc, d’une certaine manière, c’est un peu comme quand j’utilise un programme de cartographie : j’importe juste de petites images, un petit morceau de la carte.

On parle ici des versions 3D de ça et, tu sais, des composants 3D interactifs aussi. D'accord. Et, et il y a quelque chose de vraiment essentiel ici, en coulisses. Je, je, je dirais que notre vision a toujours été la suivante : quel que soit l'appareil ou la plateforme sur laquelle tu te trouves, on essaie d'intégrer les bons éléments le plus rapidement possible.

Et parfois, on dit qu'on veut les intégrer le plus vite possible pour maximiser la perception humaine de la magie. Comme si on se disait : « Waouh, le monde vient d'apparaître devant moi. » Alors Sergey, comment choisit-on et comment trie-t-on ce qu'il faut charger et intégrer ? 

Sergey : Eh bien, oui. Euh, l’optimisation, par exemple, euh, pour la perception, tu sais, comme la latence.

C'est très important parce que, comme Varun vient de le mentionner, tu vois. On mesure constamment, tu sais, la surface de l'espace à l'écran, l'importance de l'objet. Par exemple, si tu vois un arbre de très près, ou si tu vois exactement le même arbre de très loin, ça pourrait être comme deux arbres différents, non ?

Donc, si tu le vois de loin, tu ne te soucies pas vraiment des détails fins de la texture, par exemple. On peut donc toujours utiliser, tu vois, une texture à basse résolution pour l’arbre. Euh, tu ne seras pas capable de faire la différence entre, tu sais, une structure à faible risque ou à haut risque, parce que c'est juste très petit sur ton écran.

Mais d'un autre côté, on peut charger les données presque instantanément, car il y en a beaucoup moins. Mais quand on s'approche de ces trois-là, on charge progressivement de plus en plus de données et ça devient plus détaillé. Donc, on ne verra pas la transition, on ne verra pas la différence, mais on pourra immédiatement, immédiatement voir et interagir avec ça.

Dave : Et, et ça s’applique aussi quand j’utilise mon téléphone Android à 2 Go ou mon PC de jeu, et que je veux rejoindre quelque chose instantanément. Même si Internet est vraiment rapide, on n’a pas de bande passante. C’est comme si on essayait de faire passer le monde entier par ce tuyau, que tu aies 10 mégabits par seconde ou 100 mégabits par seconde, et qu’on doive équilibrer ce qu’on y fait passer.

Et, et moi, une façon dont je, je pense parfois à ça, c'est un arbre qui est près de moi. Euh, il peut utiliser les mêmes informations que cent arbres qui sont loin de moi et, en gros, ces cent arbres qui sont loin de moi peuvent avoir la même importance visuelle que celui qui est proche, et on les affiche à des résolutions différentes.

Par exemple, celui qui est près de moi est beaucoup plus fidèle que ceux qui sont loin. 

Sergey : Oui, euh, c'est tout à fait ça. Euh, et, et, euh, le point important que tu as aussi mentionné, c'est qu'on ne mesure pas seulement, tu sais, l'importance de l'objet, mais aussi, par exemple, de quelles ressources informatiques on dispose ?

Comme la quantité de mémoire dont nous disposons ? La bande passante réseau, tout ça. Donc, euh, nous prenons en compte tout ce qui affecte l'expérience utilisateur, y compris les performances. Tu sais, comme la quantité de mémoire dont nous disposons, et tout ça. 

Dave : Bon, on a parlé des instances comme étant l'arbre, et des ressources comme étant le maillage ou les textures.

Pourrais-tu nous en dire plus sur leurs différences et sur ce qu’on fait réellement en coulisses avec le streaming des ressources ? D’accord. 

Tsvetan : Oui. Hum, par exemple, pour le streaming du serveur, des sites, qu’est-ce qui est important ? Oui. Et en fonction de, euh, l’importance, euh. G fournit cette information, la transmet à chaque client, et chaque client reçoit en fait une instance différente pour cela, selon le cas.

Est-ce visible ? Ce n'est pas visible. Est-ce que cela participe à la zone interactive ou non ? Pour le streaming des ressources ? C'est le client qui diffuse en réalité ce qui se trouve dans le monde. Euh, en fonction de la qualité que nous visons, comme l'a dit Sergey, en fonction des capacités de l'appareil, nous ne ciblons que ces représentations précises, euh, en fonction de la qualité et des capacités de l'appareil.

C'est à peu près comme ça que nous fonctionnons. Euh, donc 

Dave : ces arbres au loin sont, espérons-le, très compacts, n'est-ce pas ? Une résolution plus faible, qui ne prend pas beaucoup de place. Ainsi, nous pouvons consacrer plus de temps et de puissance de calcul à un arbre qui est plus proche de moi. Et donc, nous avons ce qu'on appelle le pipeline de contenu ou le pipeline d'actifs.

Pourriez-vous m'expliquer un peu, par exemple, si je suis un créateur de jeux, à quoi ressemble ce pipeline de transcodage ? Disons que j'utilise Roblox Studio et que je construis une très belle voiture. Que se passe-t-il en coulisses 

Tsvetan : les 

Dave : les scènes ? 

Tsvetan : En raison des, euh, améliorations apportées au moteur, nous voulions également préserver l’intention artistique des concepteurs et des développeurs de jeux.

Nous avons donc eu l’idée du transcodage dans le cloud, qui nous permet d’ingérer le contenu depuis la boutique des créateurs. De l’optimiser en fonction des appareils de développement et des capacités dont le client a besoin. Et ce pipeline est de bout en bout. Il est « lazy on demand ». Cela signifie que lorsque le client demande une représentation spécifique, ce n’est qu’à ce moment-là, si nous ne disposons pas de cette représentation, que nous lançons un calcul.

Sinon, nous la renvoyons si elle existait déjà. Nous sommes donc très optimisés en termes de bande passante et de calcul que nous fournissons au client. Donc 

Dave : si je, euh, et nous, il y a longtemps, quand nous n'avions pas ça, ou peut-être même assez récemment, nous devions limiter la fidélité de ces ressources.

Par exemple, je pense qu’on disait qu’on ne pouvait avoir qu’un certain nombre de triangles dans une voiture, et que plus il y avait de triangles, plus la voiture semblait précise. Ou bien on disait qu’on ne pouvait avoir qu’un certain nombre de pixels dans la taille d’une texture. Ce qu’on dit maintenant, c’est que je crois qu’on peut télécharger cette voiture telle qu’on l’a construite, et ensuite, quand on parle de transcodage en arrière-plan.

Nous créons différentes versions de cette voiture avec de moins en moins de triangles. 

Tsvetan : Oui, c'est exact. Ou plutôt, à l'avenir. Oui. Et euh, nous disposons désormais de cette capacité qui nous permet, euh, en fonction des améliorations du moteur et euh, de la puissance de calcul dont nous disposons, nous pouvons, euh, améliorer la représentation du nombre de triangles ou de textures, des cartes de texture, ou encore de l'audio, de la vidéo, de l'animation, tout ce dont nous avons besoin.

Donc, 

Dave : donc c'est à la demande, et je pense que c'est ce que tu disais tout à l'heure, Sergey. Avant, on avait ce qu'on appelait le « baking », comme si on « cuisait » le haut de gamme. Nous, nous faisons essentiellement du « baking » à la demande. De nombreuses versions de cette voiture à différentes résolutions. Elles sont toutes là. Et puis la voiture que je vois au loin est peut-être l'une de celles à plus faible résolution.

Et c'est, euh, je crois que c'est ce qu'on appelle le transcodage. Oui. Alors, comment fonctionne le transcodage ? Comment transformez-vous un million de triangles en mille triangles ? Je veux dire ça, euh. 

Tsvetan : Euh, l'ingestion. Oui. Donc, au studio, nous, euh, nous ingérons en fait ce, euh, maillage d'un million de triangles. Nous le stockons ensuite dans, euh, notre système backend, euh, notre plateforme de contenu, euh, notre système backend.

Et ensuite, euh, sur demande, on lance, euh, un traitement LOD, 

Dave : ce qui signifie « niveau de détail ». Le niveau de détail, ce qui veut dire 

Tsvetan : en fonction de cela, nous essayons de préserver autant de qualité que possible pour cette, euh, représentation limitée du maillage. Ou de la texture. 

Dave : Donc, euh, peut-être Varun, si on réfléchit à la façon dont ça fonctionne sur différents appareils, tu es, euh, tu es le créateur.

Tu as intégré cette énorme voiture en haute résolution. Je suis sur un appareil Android bas de gamme. Tu es sur un PC de jeu haut de gamme. Avec un peu de chance, on pourra quand même jouer au même jeu. Exactement. Qu'est-ce qui se passe pour nous deux ? Et, 

Varun : et donc, en gros, quand mon client se connecte, c'est comme s'il disait : « Salut, je suis un appareil Android bas de gamme. Je veux ça en particulier », parce qu'il y a une chose qu'on n'a pas mentionnée : en fait, ce n'est pas seulement une question de niveau de détail, mais aussi de représentation spécifique à la plateforme.

Donc, Android, iOS, chacune de ces différentes plateformes a des représentations très spécifiques : on peut compresser les textures, on peut en fait les adapter de manière à ce qu’elles fonctionnent de façon bien plus optimale. Donc, mon appareil Android se connectera et dira : « Salut, je veux la version Android. » D’une texture bas de gamme pour cet arbre, puis le serveur de transcription se mettra en route et créera ça pour moi, et il la mettra en cache pour que le prochain appareil Android qui se connecte

Il n’aura pas à recommencer, il pourra simplement envoyer la version que j’ai créée. Quand votre PC se connecte, c’est comme s’il disait : « Hé, j’ai toutes les ressources du monde. Donne-moi la version haute qualité, donne-moi la version non compressée. Je veux juste la meilleure fidélité possible. » Et ensuite, il va la mettre en cache, ce qui signifie que c’est infiniment à l’épreuve du temps.

Dave : Et aussi infiniment instantané. J’adore Grand Theft Auto, et ils ont cette nouvelle version qui va être absolument époustouflante, ce qui m’enthousiasme vraiment. Si j’étais un artiste qui, euh, voulait modifier un élément. Dans notre système, espérons-le futur, je le réenverrais en cinq secondes environ.

Ton jeu et le mien déclencheraient un nouveau transcodage de celui-ci. Et littéralement, tu sais, au pic de concurrence, comme dans un jeu où 25 millions de personnes cultivent un jardin, tu pourrais en cinq à dix secondes avoir tous ces nouveaux joueurs. Qui pourraient éventuellement obtenir ce nouvel élément. C'est pourquoi je pense que c'est, en quelque sorte, l'avenir, parce que je pense qu'une partie de la beauté de Grand Theft Auto, c'est qu'ils y intègrent tellement de qualité.

Ils vont le mettre sur un DVD géant. Ils doivent s’assurer que c’est parfait et qu’il n’y a aucun moyen de faire des itérations là-dessus. Il faut que ce soit absolument parfait dès le départ. Et, et, et donc je, je, je suppose enfin. Concernant la pérennité, en plus des changements instantanés, il y a quelque chose qui semble intéressant dans le fait de conserver l’intention artistique, tu vois, de conserver l’œuvre d’art originale.

D'une certaine manière, peux-tu nous dire en quoi cela pourrait nous aider ? Euh, 

Sergey : oui. Donc, comme on essaie de capturer autant de contenu artistique original que possible, on stocke, pour ça, on stocke la version source, c'est ça. De tous les éléments. Et on peut, comme tu peux l'imaginer, tu sais, on peut.

Non seulement de le sous-échantillonner en générant des versions plus simples d’une texture, mais aussi de le sur-échantillonner à l’avenir, car nous avons déjà capturé cette sémantique, c’est-à-dire l’intention d’origine, ce qui nous permettra d’améliorer la qualité de ce ressource à l’avenir. Et ce, sans nécessiter aucune intervention de l’utilisateur.

Nous pouvons l'améliorer visuellement. 

Dave : Ça, et ça va être un indice important à mesure que nous avançons vers l'avenir. Hum, alors ajoutons, hum, ajoutons un deuxième élément à ce dont nous avons parlé. Donc, nous diffusons en continu. Nous effectuons des corrections instantanées. Transcodage dans le cloud, livraison de n'importe quel niveau de détail (LOD). Et puis, ce que nous avons laissé entendre au début, nous allons compléter cela avec quelque chose appelé Slim.

Donc, Slim n'est pas un programme d'entraînement. Ce n'est pas comme Roblox, ce ne sont pas les snacks Roblox qui, espérons-le, vont nous faire nous sentir vraiment bien et penser clairement, euh, qu'est-ce que Slim dans le contexte du moteur Roblox. 

Sergey : Donc, oui. Euh, bon. Euh, laissez-moi revenir en arrière, genre, euh, et euh, reprendre cet exemple, euh, avec un arbre, d'accord ?

Donc, on a, euh, tu as un arbre, et comme je l’ai dit, par exemple là où tu pourrais avoir plusieurs arbres, genre, euh, au loin, euh, Slim, c’est ce qui transforme tous ces arbres individuels, en quelque chose comme une forêt et les optimise, genre, ils ne sont plus individualisés, mais optimisés comme un ensemble plus grand, c’est de l’agrégation, genre, de licences individuelles et, euh.

Et c'est la technologie Slim. Elle optimise toujours ces éléments, dans un contexte spécifique. Disons que vous avez un bâtiment, d'accord ? Et, disons, un tas de, euh. Euh, pièces à l'intérieur de ce bâtiment. Par exemple, si vous êtes à l'extérieur du bâtiment, vous ne vous souciez pas des pièces à l'intérieur du bâtiment. Donc, Slim est conscient de ce contexte, en quelque sorte, et il peut très efficacement supprimer tous les éléments intérieurs du bâtiment, comme dans ce cas, et optimiser, et générer une version très optimale de cet élément pour vous.

Dave : Il y a donc trois cas d'utilisation auxquels j'ai réfléchi pendant que vous conceviez cela. Le premier cas d'utilisation concerne les avatars de plus en plus complexes que les gens créent. Historiquement, sur Roblox, nous avons toujours fait très attention au nombre de couches de vêtements que l'on peut porter, à la quantité de bijoux ou d'accessoires.

Mais à l'avenir, les avatars pourraient avoir des centaines d'éléments. Et je pense que nos créateurs sont très avertis en matière de performances. Ils pourraient en fait limiter la fidélité des avatars parce qu'ils veulent vraiment des performances optimales. Les avatars complexes, c'est le premier point. Deuxièmement, comme tu l'as mentionné, il pourrait y avoir une centaine d'arbres là-bas, très loin au loin, et personne n'interagit avec eux.

Et puis, troisièmement, il y a peut-être un bâtiment avec des pièces à l'intérieur. Euh, je pense que ce que, euh, nous allons essayer de faire ici, c'est que peu importe ce que c'est, un avatar en mouvement, un groupe d'arbres ou un bâtiment, ce tout même système va essentiellement se décomposer en un seul objet, un seul maillage, une seule texture, et c'est absolument ahurissant.

Euh, 

Sergey : oui, tu as tout à fait raison. C'est un bon terme. En gros, ce système génère dynamiquement une représentation de composition, à partir de plusieurs éléments, et il détermine, tu vois, les limites de cette composition, le niveau de détail de cette composition, de manière dynamique, en fonction du contexte.

Donc exactement comme dans deux expériences différentes, qui peuvent être optimisées différemment en fonction de l'appareil cible, en fonction du contexte dans lequel elles sont utilisées, et... Euh, nous prenons également en charge les mises à jour dynamiques pour ce contenu. Ce n'est donc pas toujours comme ça, ce n'est pas une optimisation statique.

Si quelque chose, euh, change, par exemple au fil du temps, euh, cela se reflétera dans la représentation allégée, car nous pouvons la mettre à jour de manière dynamique. 

Dave : C'est... c'est presque... l'une des raisons pour lesquelles j'aime vraiment ça, c'est que j'ai presque l'impression d'être un développeur Roblox. Et je voulais vraiment une échelle massive et, par exemple, des avatars vraiment complexes.

Je rêve peut-être de ça, genre, je peux m'approcher de quelqu'un près de moi. Ils peuvent enlever leur chapeau, mettre de nouveaux bijoux, c'est comme ça que ce système va fonctionner avec les objets proches, ça peut fonctionner en haute fidélité normale. Et puis, à mesure que cet avatar s'éloigne, il se décompose en un seul objet.

Et à mesure qu'il s'éloigne, avec le LOD. Euh, on plaisante en disant que le summum, c'est un avatar très loin qui pourrait n'être composé que de 12 triangles et d'une texture vraiment minuscule. Donc c'est, c'est presque ce dont un développeur comme moi, je pense, a rêvé. Et puis je pense que ça rend, euh, l'une des choses que ça rend possible, c'est un monde plus vaste.

Sur tous les appareils. 

Varun : Tout à fait. Je veux dire, ce que Slim fait essentiellement, c'est nous offrir un nouvel axe d'évolutivité. On a beaucoup parlé du transcodage dans le cloud à différents niveaux de détail. Maintenant, on ajoute ici un autre niveau, un autre axe, qui concerne la composition. N'est-ce pas ? Et on peut imaginer un tableau de deux cases sur deux, où n'importe quel point correspond à une expérience valable.

C'est exact. Vous pourriez donc avoir une haute qualité avec un faible niveau de composition, ou une haute qualité avec un niveau de composition élevé si vous êtes sur un appareil très bas de gamme ou sur un autre appareil. Et tous ces points ont du sens. Donc, si vous parlez d'un monde gigantesque, ce monde entier pourrait se résumer à 12 triangles. De plus, si vous êtes suffisamment loin, ou si cela n'a pas d'importance.

Dave : Et donc, en réfléchissant à l’expérience utilisateur et à la manière dont Slim peut mener à une meilleure expérience utilisateur. Si on pense au LOD, on pense au transcodage dans le cloud. Si on pense à Slim, on pense au streaming par rapport à Roblox aujourd’hui ou, ou il y a un an, comment. Comment cela peut-il affecter l’expérience utilisateur ? 

Tsvetan : Oui, donc Slim... euh, nous avons conçu Slim avec l'idée de permettre aux développeurs de créer des mondes plus riches, plus vastes et plus complexes qui vont, euh...

Euh, se comporter et interagir avec l’utilisateur final. Siemens ? Euh, oui, très facilement. Comme sans, euh, et pour l’utilisateur final, euh, l’expérience utilisateur est exactement la même que si vous disposiez de la, euh, machine la plus puissante. Et, euh, Slim est, euh, ce système qui permet aujourd’hui, euh, des modèles statiques. Et nous sommes, euh, vous savez. Permettre à l'avenir des avatars et des modèles dynamiques qui sont, euh, générés, euh, de manière hiérarchique, euh, afin que nous puissions, euh, rendre le système aussi rapide que possible pour l'utilisateur final, 

Dave : ce qui, pour l'utilisateur final, pourrait se traduire par des univers plus riches sur des appareils bas de gamme.

Ça pourrait être sur mon téléphone bas de gamme. Je pourrais jouer avec toi sur ton PC de jeu. Euh, les créateurs peuvent faire des choses plus, euh, sans se soucier du nombre de couches de vêtements sur un avatar. Des véhicules plus complexes, euh, compliqués. Euh, les objets mécaniques aussi vont être compressés par Slim, ce qui va être vraiment, vraiment cool.

Et puis. Hum, peut-être réfléchir à la façon dont ils, ils fonctionnent ensemble. Donc on a parlé du transcodage dans le cloud, euh, donc proposer un niveau de détail (LOD) plus bas. Puis on a parlé de Slim, qui propose des modèles vraiment légers. Est-ce qu’ils fonctionnent ensemble ? 

Varun : Tout à fait. Et c'est ce que je voulais dire par là, par cette histoire d'accès. Donc tous les modèles Slim passent également par exactement le même pipeline de transcodage dans le cloud.

Car une fois qu’on les a composites, et une fois que Slim a été déterminé en fonction du contexte et du contenu, c’est ainsi que le composite doit être. Il passe par le même pipeline de transcodage, puis génère une version basse qualité, une version haute qualité, une version Android, une version iOS pour tout.

Donc c'est, c'est, c'est vraiment très complémentaire, euh, entre, 

Dave : et donc, pour le créateur, c'est presque un double coup dur : un avatar très complexe, composé à distance en un modèle « slim », puis transcodé. Cet avatar pourrait, encore une fois, être composé de 12 triangles et d'une seule couleur. Et, et ce que 

Varun : ce que l'on espérerait voir, ou ce à quoi je m'attendrais, c'est en quelque sorte une première étape.

Toutes les expériences existantes peuvent simplement commencer à fonctionner sur des appareils de plus en plus bas de gamme. 

Dave : Ouais. 

Varun : Mais ce qui est vraiment passionnant, ce sont les effets de second ordre, n’est-ce pas ? Les créateurs commencent à se rendre compte : « Oh, je peux mettre plus de choses dans le monde. Oh, je peux ajouter. Eh bien, tu y penses 

Dave : d’y réfléchir, euh, si je réalise une vidéo. C’est presque comme si la caméra était conçue de manière très poussée.

Tu sais, j’ai ma caméra 4K et je ne m’inquiète jamais : peu importe où je pointe la caméra, je peux filmer comme je le fais d’habitude. Mais nos créateurs n’ont pas cette caméra aujourd’hui. Par exemple, s’ils pointent la caméra au mauvais endroit. Le monde pourrait exploser, non ? C'est comme si la résolution était trop élevée, par exemple s'ils pointent la caméra vers une foule de 10 000 personnes, c'est comme si... C'est donc presque comme libérer la caméra 3D immersive, 

Varun : tout en donnant de la liberté aux créateurs.

On peut donc s’attaquer à l’expansion de la plateforme, puis au genre. Ouais, 

Dave : et, et je pense qu’il y a un moment, on ne sait pas quand, où ce sera un mélange de la loi de Moore, de calcul 3D allégé, d’IA en streaming, de suréchantillonnage local, peu importe. Où il se pourrait que cette caméra ne soit plus une limite, où si tu voulais cent mille personnes dans un stade géant, en rendu photoréaliste, à traîner avec tes amis, en streaming sur un appareil bas de gamme avec une faible latence, ça ferait du bien.

Ce sera, je pense, quand on dira que la caméra immersive à 40 caméras est arrivée à maturité, la, euh, la bonne ou la mauvaise nouvelle, c'est qu'il y a beaucoup de travail à faire. Ça rend donc notre travail assez intéressant. Et je suppose que, dans le cadre de ce thème sur la vitesse à laquelle nous progressons vers cette caméra ultime en trois et quatre dimensions, euh, Sergei, quelle est la prochaine étape pour Slim et, disons, que devrions-nous optimiser après cela ?

Donc 

Sergey : pour Slim, euh... Il y a quelques grandes étapes qui nous attendent. Donc, la prochaine étape consiste à rendre Slim entièrement dynamique pour prendre en charge les avatars, les véhicules en mouvement, les mécanismes mobiles, euh, et tout ça. Mais l'étape la plus importante après ça, c'est de rendre Slim hiérarchique, comme l'a mentionné Barron, tu vois, pour que Slim génère à peu près les mêmes ressources que, euh, les ressources classiques.

Ils passent exactement par le même pipeline de streaming. On les optimise parce que chaque modèle Slim a ses propres ologies, et tout ça. Mais, et si on pouvait aller encore plus loin, et si on pouvait combiner plusieurs Slims en un seul, genre un méga-Slim, puis encore et encore, de cette manière, comme une fractale.

Dave : Ça faisait partie de notre réflexion sur la conception. Parce que quand tu as proposé Slim au départ, on travaillait sur des avatars et on avait un projet distinct. On se demandait comment on pourrait rassembler une centaine d’avatars et comment on allait simuler cent mille personnes dans un stade. Et ce qui était vraiment fascinant, c’est ce jour où tu as dit : « Tu sais quoi, on pourrait peut-être prendre des avatars Slim et en mettre une centaine dans une collection d’avatars en utilisant exactement la même technologie.

Et c'est un peu là qu'on s'est dit : « Ça nous a époustouflés, cette nature hiérarchique, tu vois ? » 

Sergey : Euh, oui, euh, c'est tout à fait ça. Et si on pousse cet exemple à l'extrême, on peut imaginer, par exemple, notre caméra virtuelle qui permet de voir la planète entière. On voit donc la planète entière, et c'est comme, tu vois, une sphère, avec sa texture.

Quand la caméra se rapproche, on voit les continents, puis les villes, et on peut descendre jusqu’au stade rempli de monde, parce que toute la simulation tourne sur le serveur et le client n’a pas besoin de connaître, euh, le monde entier.

C'est clair, tu vois, c'est comme si tu ne pouvais pas faire tenir, tu vois, toute cette planète dans la mémoire d'un appareil, même si tu es sur un PC puissant. Mais nos serveurs sont très puissants et en générant cette représentation clé pour Slim, tu vois, on peut passer de l'échelle de la planète jusqu'à l'échelle d'une pièce, tu vois, ou même jusqu'au micromonde.

Dave : Eh bien, c'est vrai. On pourrait descendre jusqu'à la montre que toi ou moi portons, en regardant le petit bouton de la montre, et même encore plus loin que ça. Et donc, quand on y réfléchit, euh, Satan, qu'en penses-tu, en quoi cela pourrait-il changer ce que les créateurs commencent à faire ? Exactement. On va... se débarrasser, espérons-le, de ce « oh mon Dieu, je dois m'inquiéter des performances d'un avatar ».

Hum, d'autres changements que tu penses qu'on pourrait voir 

Tsvetan : À mon avis, cela supprimera toutes les contraintes auxquelles ils sont confrontés aujourd’hui. Comme vous l’avez dit, ils n’auront plus à se soucier de la complexité du monde qu’ils créent. Ils n’auront plus qu’à réfléchir à la dynamique de jeu qu’ils souhaitent proposer à leurs joueurs.

Rien d'autre. Tout le reste sera géré automatiquement par nous. 

Dave : Bon, et c'est bien d'approfondir un peu ces aspects automatiques. Tu sais, dans l'ancien Roblox traditionnel, on utilisait ce qu'on appelait un « atlas de textures ». On avait en fait un modèle de texture, et tu devais te débrouiller tout seul. Je suppose qu'avec un modèle allégé, c'est complètement automatique.

Euh, comme la génération de cette texture en basse résolution. 

Tsvetan : Oui. Ça sera automatique, tout comme la détermination de ces, euh, éléments de base que Sergei a expliqués dans le monde dynamique hiérarchique. 

Dave : D'accord, alors maintenant, euh, on va vraiment se faire exploser le cerveau et on va parler de, euh, c'est facile d'imaginer quelque chose de plus simple, non ?

C'est presque comme si, en tant qu'artiste, c'était très facile à imaginer en quelque sorte. Rendre quelque chose plus grossier et l'aplatir, c'est beaucoup plus difficile d'imaginer que quelque chose atteigne une résolution plus élevée. Et donc je veux, je veux aborder un peu, euh, l’avenir de l’IA et là, il y a beaucoup de travail en cours sur l’IA, comme la façon dont on va générer des jeux vidéo et du streaming immersif en temps réel et des modèles de monde et tout ça.

Hum, et je... je sens de plus en plus qu’on va se rendre compte que ce n’est pas une chose monolithique. Ce sera une pile de 3, 4, 5 ou 6 modèles fonctionnant tous ensemble, y compris, tu sais, une ligne de commande où, si on traîne ensemble, on peut, comme on le fait avec la 4D, simplement dire : « Transforme le Washington Monument en Godzilla », et boum, ça va se produire juste là.

Hum, et, et finalement générer des objets, des mondes ou des jeux complets. Hum, et, espérons-le, dans un contexte multijoueur. Donc, on se balade ensemble, tous les quatre, et on dit : « Hé, là-bas, on aimerait bien concevoir un nouveau jeu et le voir apparaître comme par magie. » Il y a un aspect secondaire. Euh, en plus de l'invite de commande, de la génération de mondes et de la 3D, ce dont tu parlais, euh, il y a l'upsampling et, et ça, euh, si, si j'imagine parfois le Crossroads classique, qui est un jeu vieux de 20 ans sur Roblox, il y a en fait suffisamment d'informations là-dedans.

Si on prenait le Crossroads classique et que, comme tu l’as dit Sergey, on lui donnait ce look. Comme une version médiévale photoréaliste où le gameplay pourrait rester le même. Tu sais, tous ces petits outils sympas comme le lance-roquettes, ils sont les mêmes, mais tout à coup, tout a un nouveau look. Alors, comment ça fonctionnerait dans ce contexte ?

Je ne sais pas qui veut intervenir. Sur le LOD, parce que maintenant le LOD doit augmenter plutôt que disparaître. 

Varun : Je pense que c'est l'un des points que Sergey a soulevés tout à l'heure, n'est-ce pas ? Il s'agit de conserver autant que possible l'intention artistique d'origine afin de pouvoir faire ce genre de choses à l'avenir. Et, mon exemple préféré, même si c'est un exemple pris au hasard, imagine que j'utilise une texture, mais que cette texture soit en fait une photo prise par quelqu'un, si j'avais conservé l'ouverture.

La taille, si j’avais conservé l’ouverture du diaphragme au moment où cette photo a été prise. Maintenant, mon algorithme Uprising dispose de beaucoup plus de contexte. Oui. Si je sais où cette texture est utilisée, si je sais qu’elle est utilisée sur un château, est-ce qu’elle est utilisée sur le sol ? Mon algorithme Uprising peut être bien plus intelligent pour créer cela et conserver l’intention originale du créateur tout au long du processus, que ce soit sur un PC haut de gamme ou sur un futur PC qui n’a même pas encore été inventé.

Donc 

Dave : on a montré ça au RDC, je crois qu’on a montré une vidéo de 15 secondes de Crossroads en upscaling. Euh, tu peux, parlons de ce qui pourrait réellement se passer. Les ressources sont dans le cloud, les objets 3D, les textures. Hum, une instruction supplémentaire est envoyée à notre système de contenu qui dit : « Écoutez, tous ces éléments font partie d’un monde médiéval qui devrait être bien plus photoréaliste que ce qu’on peut imaginer.

Ensuite, toutes ces différentes LED sont régénérées pour se rapprocher beaucoup plus de la version photoréaliste grâce à ce qu’on pourrait appeler un échantillonneur 3D UPS ou, en réalité, un créateur génératif 3D. Alors, hum, qui veut se plonger dans ce qui pourrait arriver au château, par exemple ? 

Sergey : Je, je, je pense que, comme Baron vient de le mentionner, tu sais, euh, on dirait qu’on capture quelque chose de bien plus sémantique, issu de ce monde.

C'est ce qui est extrêmement important. Par exemple, pour cet exemple de carrefour, d'accord ? Donc, si vous regardez le château. Euh, de mon point de vue sur les éléments individuels, c'est juste, vous savez, comme un certain nombre de blocs, ce ne sont que des boîtes. Et vous n'avez pas assez de contexte, vous savez, vous ne pouvez pas rendre ces blocs plus beaux.

Et le château, c'est juste, euh, c'est plus que de simples blocs individuels. C'est la somme de ceux-ci. Euh, et Slim, puisque Slim fonctionne, disons, dans ce contexte, Slim a conscience de cette chose, en tant qu'ensemble. Donc, et maintenant, n'importe quel assemblage, en quelque sorte, en saura bien plus sur, tu vois, le château dans son ensemble, et non sur les éléments individuels.

Donc, il peut créer une version bien meilleure de ce château upscalé, parce que, c'est juste que, il comprend ça 

Dave : et, et, et dans un sens, on pourrait l’imaginer sans ce château de Crossroads existant. Et pour que tout le monde sache, Crossroads est un très vieux jeu Roblox à l’aspect pixélisé.

Ce château est en fait une très bonne aide pour la consigne. « Construis-moi un château ». C'est une consigne assez ouverte. On va obtenir un château aléatoire de forme aléatoire. Mais le château de Crossroads, avec ses dimensions réelles, c'est une mine d'informations utiles pour le suréchantillonner en un château de très haute qualité.

Sergey : Euh, oui. Euh, c'est tout à fait ça. Donc, parce que, euh, euh, cette partie en 3D du château, tout d'abord, ça va être très important, d'un point de vue gameplay, non ? Donc on ne peut pas juste générer n'importe quel château et le faire fonctionner pour le jeu. Euh, parce que. Mais si vous pouvez capturer toutes les dimensions, toute la sémantique, dans tous les contextes, dans quoi que ce soit où cet ensemble a été utilisé, alors vous pouvez l'upsampler très efficacement.

Et, et tu ne vas pas casser ton jeu en faisant ça. Parce que, c'est une autre chose très importante. Tu ne veux pas suréchantillonner un élément qui pourrait rendre ton jeu injouable. 

Dave : Eh bien, je pense qu’il y a un monde futur où, en plus de toutes vos informations 3D, vous pourrez soit modifier vos informations 3D, soit modifier votre prompt.

Les deux s’assemblent pour générer ce monde, de sorte que… La mise à jour de cinq secondes dont nous avons parlé, qui correspond à une modification de l’élément à l’avenir. Ce sera peut-être une mise à jour de cinq secondes de la commande et un petit indice supplémentaire dans la commande. Et ensuite, générer ce monde de manière différée à la demande. Et puis, je pense qu’il y a une dernière chose… quand on réfléchit à toutes les dimensions de la façon dont l’IA peut s’assembler pour rendre ces éléments photoréalistes, on n’en est pas là.

Il y a une dernière couche, qui est la couche 2D. Que se passe-t-il sur votre PC de jeu ? Que se passerait-il dans un appareil vidéo dans le cloud où un suréchantillonnage encore plus élevé pourrait avoir lieu ? Donc, euh, par exemple, des cheveux parfaits sur ma tête. Le meilleur endroit pour réaliser ces cheveux serait peut-être localement avec un suréchantillonneur 2D. Je sais que vous avez travaillé sur beaucoup de jeux qui essaient de réaliser les cheveux en 3D.

Qu'en penses-tu ? Penses-tu qu'un jour, tous les cheveux seront créés avec un suréchantillonnage 2D ou s'agira-t-il de cheveux en 3D ? 

Sergey : Oui, tout à fait. Je pense qu'on s'oriente dans cette direction, car certaines choses ne peuvent être réalisées que dans l'espace écran, c'est plus efficace. Disons-le ainsi : c'est plus efficace de le faire dans l'espace écran.

Par exemple, comme ça, euh, comme les cheveux, le rendu, tu vois ? Donc, et genre, ou. Beaucoup de moteurs de jeu aujourd'hui utilisent des techniques basées sur le ML, comme l'upsampling, euh, en passant de 1080p à 4K. Mais on peut, on peut faire bien plus que ça, non ? On peut changer l'ombrage, on peut, euh, changer l'aspect des choses.

Et si on pousse cet exemple à l’extrême, un moteur de jeu peut simplement rendre, tu vois, des informations sémantiques, pour un algorithme d’apprentissage automatique, par exemple, et ensuite cet algorithme va générer, tu vois, des cheveux qui ont l’air bien, ou des matériaux qui ont l’air bien. Comme dans l’espace de rendu, la directive.

Dave : Super. Hum, alors, et puis alors que nous commençons à conclure, peut-être pour tous les codeurs C++ là-bas, les codeurs en langage assembleur, ce que, hum, j’aimerais bien faire, c’est l’une des choses les plus amusantes au monde. On fait quelque chose de très difficile ici, n’est-ce pas ? On essaie de, hum, faire fonctionner toutes ces technologies sur tous les appareils.

Question sur le transcodage. La question sur le transcodage est la suivante : je sais que beaucoup de PC disposent d’optimisations, euh, avec des registres SIMD et des choses de ce genre pour accélérer le fonctionnement. Avons-nous commencé à explorer le SIMD dans l’un de nos transcodeurs, ou s’agit-il d’une optimisation future ? 

Tsvetan : Euh, tout d'abord, au fait, le transcodage peut également fonctionner sur le moteur aujourd'hui.

D'accord. Excellent. Bien. Nous tirons donc parti des optimisations CMD, mais nous visons encore plus loin en utilisant des GPU et, euh, d'autres, 

Dave : donc le transpo... D'accord. Le transcodage sur GPU est peut-être en vue. 

Tsvetan : Eh bien, oui, nous étudions la question. 

Dave : D'accord. Ce qui est super, super sympa. Bon, alors, euh, super mise à jour pour tout le monde, euh, euh, pour ceux qui veulent du visuel, peut-être une présentation RDC sur la scène principale.

Je pense qu’on devrait, on avait des visuels pour beaucoup de ces éléments. Tout ce dont on a parlé est en cours de développement. Euh, on suit ça de près et je, je, je pense vraiment que, euh, vous tous et les différentes équipes derrière vous contribuez vraiment à ce que je appelle parfois le « moteur de jeu 2.0 », euh, qui repose fortement sur le cloud.

Fortement soutenu par Transcoders dans toute cette technologie. Alors merci à tous. Je pense qu’on a époustouflé tout le monde aujourd’hui. Je vous en suis vraiment reconnaissant. 

Tsvetan : Merci. 

Dave : Bon, alors salut, c'est Dave. Euh, encore une fois, merci pour ces discussions techniques et on a hâte de vous revoir la prochaine fois. Merci de la part de toute l'équipe. Merci.