Transcripción completa

Dave: Hola, soy Dave Baszucki, fundador y director ejecutivo de Roblox, y estáis escuchando o viendo Tech Talks. Hoy vamos a hablar de qué conforma un motor de juegos de segunda generación, cómo se integra la nube y cómo ayudamos a los usuarios a conectarse al instante en alta resolución. Contamos con el equipo técnico de ensueño aquí, como parte de Roblox.

Tenemos a Varun Mani, a Sergey Makeev y a Tsvetan Tsvetanov, y vamos a profundizar en todo lo relacionado con el streaming. Vamos a hablar de Slim, de la transcodificación de activos, de todo lo que hace que Roblox pueda, en última instancia, dar soporte a cien mil jugadores. Si echamos un vistazo a la industria de los videojuegos de los últimos 10 o 20 años.

Hay una forma tradicional en la que todo este contenido 3D llega hasta ti y... eh... y... y hay algunos problemas con esta forma tradicional. Porque lo que intentamos hacer en Roblox es que te unas al instante. Eh, estamos intentando que las mismas experiencias se ejecuten tanto en un teléfono como en un ordenador gigante. Estamos intentando hacerlo sin latencia, y cuando miramos cómo funcionan los juegos tradicionales, no es exactamente lo mismo, ¿verdad?

Recuerdo que, en mi época, se distribuían en unas cosas llamadas disquetes. Pero incluso hoy en día, ¿no?, distribuimos los juegos en... DVD grandes, creo. ¿Es correcto decirlo así? 

Varun: Sí. Y creo que la clave está en que todo viene empaquetado junto. Sí. ¿Verdad? Así que, ya sea un DVD o una descarga de un juego hoy en día, viene como un paquete gigante que no puedes, no puedes dividir.

Así que tienes que esperar a que se descarguen los 4,7 gigas, o 10 gigas, en algunos casos, antes de poder empezar. 

Sergey: Sí. Y como ha dicho Varun, en algunos juegos eso puede suponer, ya sabes, unos 20 o 40 gigas, y tienes que esperar un montón de tiempo antes de poder empezar a jugar. Y eso es como, ya sabes, como si te rompiera el ritmo, ¿no?

Porque, como quieres jugar, tienes quizá una o dos horas, después del trabajo, quieres jugar a un juego y luego tienes que esperar como 30 o 40 minutos, mientras se actualiza y tal. Básicamente, esa es mi experiencia al jugar. 

Dave: ¿No es eso algo parecido a lo que hemos visto en el vídeo y el cine?

Recuerdo una época en la que las películas se distribuían en DVD y luego recuerdo la época de BitTorrent, por ejemplo. Te descargabas todo y, finalmente, llegamos a un punto en el que voy a mi Amazon, mi Netflix, mi Hulu o mi Tubi y puedo verlo al instante. Pero yo... no creo que eso haya sucedido todavía en el mercado de los videojuegos.

Todavía no. Todavía no. Creo que todavía no. 

Tsvetan: Somos los únicos que nos centramos 

Dave: eso. Así que, históricamente, Roblox ha funcionado así y entre bastidores, eh. Puede que la mayoría de la gente no se dé cuenta, pero cuando vas a la página de inicio de Roblox y haces clic en «Jugar», puedes unirte al instante. En realidad, esto es muy poco tradicional porque, cuando estoy en algunas plataformas de videojuegos muy sofisticadas, he llegado a ver descargas de hasta 200 gigabytes antes de poder jugar.

Entonces, ¿ya estamos haciendo este juego instantáneo? Sí. 

Tsvetan: Eh, Roblox, por lo que yo sé, es la única plataforma que permite esta función de unirse y jugar al instante. Ah, sí, 

Varun: sí, lo siento. Y, ¿es algo parecido a lo que decías sobre el streaming de vídeo, verdad? Es decir, ¿qué estás haciendo realmente cuando ves un vídeo en streaming en el que no quieres descargar la película entera, sino que solo descargas lo que tienes delante, y a eso lo llamamos «buffering»?

Estoy transmitiendo la película. ¿Verdad? Así es, pero eso es solo en una dimensión, porque ahí solo hay una dimensión temporal. Sí, esa es la diferencia clave aquí. Eso es lo difícil de hacerlo en Roblox, porque es un mundo 3D totalmente interactivo en el que tienes que transmitir tanto instancias como activos, que son como los bloques de construcción básicos de todo en 

Dave: Roblox A a y, eh, diría que esto lo ha complicado aún más porque en el mercado tradicional de los videojuegos

Suelo ver diferentes versiones de los juegos, por ejemplo, en un PC de gama alta y en un móvil de gama baja. Y lo que yo, la forma en que lo interpreto, es que en los PC de gama alta, donde puedo descargar cientos de gigabytes, van a tener estos activos realmente grandes y complejos, y en los móviles es casi como si los creadores, creo, hicieran una versión separada 

Sergey: en cierto modo.

Eh, sí. Eso, eso, eso es un punto muy bueno, porque, como en los juegos tradicionales, ya sabes, tienen este proceso que se llama «asset cooking». Así que preparan una versión muy optimizada, por ejemplo, de los recursos, por plataforma. Y si lo piensas desde una perspectiva más de streaming de vídeo, es como en un DVD.

Eh, el vídeo solo se codificó una vez, ¿no? Sí. Pero en cualquier plataforma de streaming tienen múltiples codificaciones para el mismo vídeo, así que se adapta automáticamente a tu dispositivo. Y, eh, todos los juegos actuales, ya sabes, preparan sus activos de antemano y los envían de forma muy específica, como un triplex aquí.

Así que podemos generar una versión optimizada de un recurso por plataforma en la nube. Así es. 

Dave: No pierdas de vista eso, ¿vale? Porque hace un tiempo teníamos la visión de que, si eres un creador joven y desarrollas tu experiencia, esta pueda ejecutarse en cualquier lenguaje. Teníamos la visión de que pudiera ejecutarse en cualquier dispositivo y a varias resoluciones en cualquier dispositivo.

Vamos a, vamos a profundizar en ello. Así que, el mercado de los videojuegos tradicional, ya sabes, empaquetados o descargados. Eh, queremos resolver esos problemas de acceso instantáneo publicado para cualquier dispositivo, baja latencia y todo eso junto. Y por eso hoy vamos a hablar de algo que se llama, literalmente, streaming 3D y 40.

Vamos a hablar de, eh, contenidos en la nube. Vamos a hablar de algo llamado «slim», que creo que a todo el mundo le va a entusiasmar mucho. Y así, quizá, eh, para entrar en materia, Varun, primero una pequeña visión de qué es «slim» y qué. Eh, lo llamamos «cloud Transco». Sí. ¿Y qué significa todo eso? 

Varun: Bueno, si damos un paso atrás, si pensáis en nuestra visión general, estamos intentando alcanzar el 10 % del mercado de los videojuegos.

Sí. La forma de hacerlo es dar a los creadores total libertad sobre lo que crean. Y si pensamos en cómo crecemos, hay dos dimensiones. Podemos hacer una expansión de la plataforma o una expansión de géneros. La expansión de la plataforma consiste en: ¿cómo hacemos que el mismo contenido funcione en cualquier plataforma?

Así que se crea una vez. Roblox, asegurándose de que funcione en todas partes. Y en cuanto a la expansión de géneros, queremos que se creen cosas cada vez más impresionantes y cada vez más alocadas. 

Dave: Y cuando dices «funcionar en cualquier sitio», literalmente, imagina algo realmente grande, alocado y divertido. Grand Theft Auto, Red Dead Redemption, consolas de gama alta.

Que funcione en un teléfono Android de dos gigas y todo lo que hay entremedio. Así es. Desde 

Varun: desde un PC hasta un Android de dos gigas, debería funcionar sin que el creador tenga que hacer ningún trabajo extra. Esa es la visión. Exactamente. La nube, la transcodificación y Slim son solo dos de los primeros pasos que hemos dado en ese camino.

Dave: Vale, eso es un pequeño adelanto. Vamos a explicar qué es Slim y vamos a explicar... Creo que probablemente tú explicarás qué es la transcodificación, pero primero presentemos a todo el mundo. Así que, Sergey, um, has vuelto, ¿puedes contarnos un poco sobre tu experiencia en optimización de motores? Una de las cosas más divertidas del mundo, ¿verdad?

Lenguaje ensamblador C++, como CmD, ¿puedes contarnos un poco en qué has estado trabajando? 

Sergey: Eh, sí, bueno, como has mencionado antes, sí, he estado trabajando básicamente en juegos o en el mundo de los videojuegos y, bueno, toda mi vida me he dedicado a hacer todo tipo de optimizaciones, empezando por la Xbox regional y cosas así.

Eh, y... Ya sabes, cuando descubrí Roblox por primera vez, me quedé alucinado con la idea de un juego creado una sola vez, o más bien, no un juego. Como cualquier experiencia creada una sola vez y que luego se puede ejecutar en cualquier lugar, en cualquier plataforma, en cualquier dispositivo, sin necesidad de que el usuario tenga que hacer nada más.

Y ese es un problema de ingeniería extremadamente complejo. Eh, como, eh, como todo el mundo puede imaginar, ¿no? Así que, eh, y eso requiere un montón de, eh, ya sabes, optimizaciones tradicionales, como CMD, como el multitrading, como una gestión muy cuidadosa de la GPU, la programación, todo eso. Pero al mismo tiempo, ya sabes, hay un límite, eh, en cuanto a cuánto podemos escalar en un solo dispositivo.

Por suerte para nosotros, siempre tenemos nuestra nube, ¿no? Así que podemos subir parte de este trabajo a nuestra nube y ayudar a esos dispositivos a renderizar de forma más eficiente para renderizar paredes más grandes. Hasta cierto punto, ya sabes, como cuando podemos renderizar algunas paredes que ni siquiera caben en la memoria de un dispositivo físico porque, ya sabes, también existen en el lado del servidor y el servidor ayuda a todos los clientes a renderizarlas de forma eficiente.

Dave: Sí. Y, solo como punto destacado, creo que parte de la pista que vamos a compartir es que los motores de juego tradicionales suelen estar escritos en C++, y te descargas todos los recursos. Pero digamos que un juego al que quisieras jugar fuera el mundo entero; por ejemplo, nadie puede meter el mundo entero en un DVD.

Y por eso, lo que realmente estás insinuando, y ya lo vemos con Google Maps y otros servicios similares, No hay forma de que puedas meter todo eso en un mismo sitio. Y, por eso, parte de lo que vamos a hablar cuando hablamos de streaming es eso mismo para los juegos y luego... ¿Podrías contarnos un poco cómo llegaste a Roblox, cuál es tu trayectoria y quizá darnos una pequeña pista de qué es la transcodificación en la nube?

Bueno, 

Tsvetan: eh, antes de unirme a Roblox, desarrollé mi experiencia profesional en dos ámbitos. Uno es el software de diseño y simulación 3D para arquitectura, construcción e ingeniería mecánica. Y el segundo era la computación distribuida a gran escala, que... Puedo aplicar mis conocimientos de ambos ámbitos a Roblox porque, básicamente, eso es lo que es Roblox.

Dave: Sí. Pasemos al streaming en Roblox y hablemos de ello. Bueno, sabemos lo que es el streaming de vídeo. El streaming de vídeo es algo lineal, ¿verdad? Solo se necesita un fotograma. Un fotograma tras otro, los enviamos sucesivamente. ¿Podrías explicarnos qué significa el streaming en 3D en tiempo real? 

Varun: Si te fijas bien, casi todo en un juego de Roblox hoy en día está compuesto por instancias o activos, ¿verdad?

Instancias, que son como la estructura del mundo. Y luego un activo es lo que realmente impulsa esa instancia para el contenido real. Eh, si piensas en el streaming, se trata de transmitir instancias y también esos activos. Eso es lo que hay que hacer. Así que si, en una transmisión de vídeo, solo tienes un activo, ese es el vídeo.

En Roblox, hacemos eso miles, 10 000 veces, una y otra y otra vez. Así que cuando hablas de streaming instantáneo, lo que intentas es transmitir lo suficiente del mundo que te rodea y no sabes qué va a hacer el jugador. El jugador podría ir por aquí, el jugador podría ir por allá. Quieres transmitir o almacenar en búfer lo justo del mundo.

Y luego, en ese mundo que has almacenado en el búfer, quieres almacenar los activos con la calidad exacta adecuada. Así que, como mencionó Sergei, tienes diferentes niveles de calidad para el vídeo. Tenemos lo mismo con las mallas, lo mismo con las imágenes. 

Dave: Entonces, si lo desglosamos, ¿sería correcto decir que las instancias son cosas con las que podríamos estar familiarizados?

Un coche, un árbol, otra persona, una colina, algo así. Y luego los activos son los elementos técnicos que componen esas instancias. Como el interior de esos objetos 3D. Cuando estamos en un juego, tenemos, por ejemplo, grupos de triángulos, tenemos grupos de texturas, así que estamos hablando de elegir cuáles de esos

Realmente incorporarlos en cualquier momento. 

Varun: Sí. Y qué representación de ellos. Así que, mientras caminas, mientras recorres el mundo, es como si el dispositivo dijera: «Vale, quiero ese árbol» o «necesito ese árbol». Ese árbol está compuesto por un montón de mallas y un montón de texturas, y quizá incluso, en el futuro, animaciones, audio, etcétera, etcétera.

Así que entonces decide. Vale. Basándose en la posición de ese árbol, su importancia, cuánto espacio ocupa en pantalla. Quiero la textura en alta calidad. Quiero la malla en calidad media. Y luego el audio, quizá aún no lo necesite, así que no lo retrases. Así que constantemente está haciendo esas... 

Dave: así que, en cierto modo, esto es un poco como cuando uso un programa de mapas: solo importo las imágenes pequeñas, un trocito del mapa.

Estamos hablando de las versiones 3D de eso y, ya sabes, también de componentes 3D interactivos. Vale. Y hay algo realmente esencial aquí entre bastidores. Yo diría que nuestra visión siempre ha sido que, independientemente del dispositivo o de lo que estés usando, intentamos incorporar los elementos adecuados lo más rápido posible.

Y, a veces, decimos que queremos mostrarlos lo más rápido posible para maximizar la percepción humana de la magia. Como si dijeras: «¡Guau! El mundo ha aparecido ante mí». Así que, Sergey, ¿cómo elegimos y cómo clasificamos qué cargar y qué mostrar? 

Sergey: Bueno, sí. Eh, la optimización, como, eh, para la percepción, ya sabes, como la latencia.

Eso es muy importante porque, como acaba de mencionar Varun, ya sabes. Constantemente medimos, ya sabes, el área del espacio en pantalla, la importancia del objeto. Por ejemplo, si ves un árbol a muy corta distancia, o ves exactamente el mismo árbol a una distancia muy grande, podrían parecer dos árboles diferentes, ¿verdad?

Así que si lo ves desde lejos, realmente no te importan los detalles finos de la textura, o algo así. Así que podemos, siempre podemos usar, ya sabes, una textura de baja resolución para el árbol. Eh, no podrás distinguir si se trata de una estructura de bajo riesgo o de alto riesgo, porque es muy pequeña en la pantalla.

Pero, por otro lado, podemos cargar los datos casi al instante porque así se transfieren muchos menos datos. Pero cuando te acerques a esos tres, iremos cargando progresivamente más y más datos y se verá con más detalle. Así que no podrás ver la transición, no notarás la diferencia, pero podrás ver e interactuar con eso de forma inmediata.

Dave: Y, y parte de esto es cuando estoy usando mi, ya sea mi teléfono Android de dos gigas o mi PC para juegos, y quiero unirme a algo al instante. Aunque Internet sea muy rápido, no tenemos ancho de banda, es como si estuviéramos intentando hacer pasar el mundo por ese conducto, ya tengas 10 megabits por segundo o cien megabits por segundo, y equilibrar lo que hacemos pasar por ahí.

Y, y yo, una forma en la que a veces lo pienso es en un árbol que está cerca de mí. Eh, puede usar la misma información que cien árboles que están lejos de mí y, en esencia, los cien árboles que están lejos de mí pueden tener la misma importancia visual que el que está cerca y los traemos con diferente resolución.

Como el que está cerca de mí tiene mucha más fidelidad que los que están lejos. 

Sergey: Sí, eh, eso es exactamente así. Eh, y, y, eh, el punto importante que también has mencionado es que no solo estamos midiendo, ya sabes, la importancia del objeto, sino también cuántos recursos informáticos tenemos.

¿Cuánta memoria tenemos? El ancho de banda de la red, todo. Así que tenemos en cuenta todo lo que afecta a la experiencia del usuario, y eso incluye el rendimiento. Ya sabes, cuánta memoria tenemos y todo eso. 

Dave: Bueno, hemos hablado de que las instancias son como el árbol, y los activos son la malla o las texturas.

¿Puedes explicarnos más en qué se diferencian y qué es lo que realmente hacemos con el streaming de activos bajo el capó? Vale. 

Tsvetan: Sí. Eh, por ejemplo, al transmitir desde el servidor, ¿qué es lo importante? Sí. Y en función de, eh, la importancia que le da G a esta información, la envía a cada cliente, y cada cliente recibe, en realidad, una instancia diferente para eso, dependiendo de...

¿Es visible? No es visible. ¿Participa en el sector interactivo o no? ¿Para el streaming de activos? Es el cliente el que realmente transmite lo que había en el mundo. Eh, en función de la calidad a la que nos dirigimos, como dijo Sergey, en función de las capacidades del dispositivo, solo nos dirigimos a esas representaciones exactas, eh, basadas en la calidad y en la capacidad del dispositivo.

Más o menos así es como lo hacemos. Eh, así que 

Dave: esos árboles que están muy lejos, con suerte, son muy compactos, ¿verdad? Una resolución más baja, que no ocupa mucho. Así podemos dedicar más tiempo y más recursos de cálculo a un árbol que está más cerca de mí. Y por eso tenemos esto que se llama el canal de contenido o el canal de activos.

¿Podrías explicarme un poco cómo es este canal de transcodificación desde el punto de vista de un creador de juegos? Por ejemplo, si utilizo Roblox Studio y construyo un coche muy chulo, ¿qué ocurre detrás 

Tsvetan: 

Dave: las escenas? 

Tsvetan: Debido a las, eh, mejoras en el motor, también queríamos preservar la, eh, intención artística de los diseñadores y desarrolladores de juegos.

Así que se nos ocurrió esta idea de la transcodificación en la nube que nos permite, eh, eh, incorporar el contenido de la, eh, tienda de los creadores. Optimizarlo en función del dispositivo de desarrollo, eh, los dispositivos y las capacidades que, eh, eh, el cliente necesita. Y, eh, este proceso es de extremo a extremo. Es «lazy on demand». Lo que eso significa es que cuando el cliente solicita una representación específica, solo entonces, si no tenemos esa representación, iniciamos un cálculo.

Si no, lo devolvemos si ya existía. Así que somos muy eficientes en cuanto al ancho de banda y la computación que proporcionamos al cliente. Así que 

Dave: si yo, eh, y nosotros, hace mucho tiempo, cuando no teníamos esto, o quizá en realidad hace muy poco, teníamos que poner límites a la fidelidad de estos activos.

Por ejemplo, creo que decíamos que solo podías tener un número determinado de triángulos en tu coche, y que cuantos más triángulos, más preciso se veía el coche. O decíamos que solo podías tener un número determinado de píxeles en el tamaño de una textura. Lo que decimos ahora es que, creo, puedes subir ese coche tal y como lo hayas construido, y luego, cuando hablas de transcodificación entre bastidores...

Creamos varias versiones de ese coche con cada vez menos triángulos. 

Tsvetan: Sí, eso es correcto. O incluso más en el futuro. Sí. Y, bueno, ahora tenemos esta capacidad de que podemos, dependiendo de las mejoras del motor y de la potencia de cálculo que tengamos, podemos mejorar la representación del número de triángulos o de texturas, mapas de relieve o audio, vídeo, animación, lo que sea que necesitemos.

Así que, 

Dave: así que esto es bajo demanda, y creo que lo que decías antes, Sergey, es que antes se utilizaba algo llamado «baking», como si se horneara el nivel alto. Básicamente, estamos haciendo «baking» bajo demanda. Muchas versiones de ese coche a diversas resoluciones. Todas están ahí. Y luego, el coche que veo a lo lejos puede que sea uno de esos de menor resolución.

Y esto es, eh, creo que lo que llamamos transcodificación. Sí. Entonces, ¿cómo funciona la transcodificación? ¿Cómo se cogen un millón de triángulos y se convierten en mil triángulos? Me refiero a eso, eh. 

Tsvetan: Eh, la ingesta. Sí. En el estudio, nosotros, eh, en realidad ingestamos esa, eh, malla de un millón de triángulos. Luego la almacenamos en, eh, nuestro backend, eh, la plataforma de contenido, eh, el sistema backend.

Y luego, eh, bajo petición, ejecutamos, eh, el procesamiento LOD, 

Dave: que significa «nivel de detalle». Nivel de detalle, lo que significa 

Tsvetan: dependiendo de... intentamos conservar la mayor calidad posible para esa, eh, representación limitada de la malla. O textura. 

Dave: Entonces, si, um, quizá Varun, si pensamos en cómo funciona esto en distintos dispositivos, tú eres, um, tú eres el creador.

Tú pones este coche gigante de alta resolución. Yo estoy en un dispositivo Android de gama baja. Tú estás en un PC para juegos de gama alta. Con suerte, aún podremos jugar al mismo juego. Exactamente. ¿Qué pasa para los dos? Y, 

Varun: y bueno, básicamente, cuando mi cliente se conecta, es como: «Hola, soy un dispositivo Android de gama baja. Quiero esto específico», porque hay algo que no hemos mencionado: en realidad, no se trata solo del nivel de detalle, sino también de una representación específica de la plataforma.

Así que Android, iOS, cada una de estas plataformas diferentes tiene representaciones muy específicas en las que puedes comprimir las texturas, puedes adaptarlas de tal manera que funcionen de forma mucho más óptima. Así que mi dispositivo Android se conectará y dirá: «Hola, quiero la versión para Android. De una textura de gama baja para ese árbol», y entonces la transcripción en la nube se pondrá en marcha y la creará para mí, y la almacenará en caché para que el siguiente dispositivo Android que se conecte

No tiene que volver a hacerlo, simplemente puede enviar la versión que yo creé. Cuando tu PC se conecta, es como: «Oye, tengo todos los recursos del mundo. Dame la versión de alta calidad, dame la versión sin comprimir. Solo quiero la máxima fidelidad». Y luego lo almacena en caché, lo que significa que esto es infinitamente a prueba de futuro.

Dave: Y también infinitamente instantáneo. Me encanta Grand Theft Auto, y tienen una nueva versión que va a ser absolutamente alucinante, lo cual me hace mucha ilusión. Si yo fuera un artista que, eh, quisiera ajustar un recurso. En nuestro, esperemos que futuro, sistema, lo volvería a subir en unos cinco segundos.

Tu juego y el mío activarían una nueva transcodificación de eso. Y, literalmente, ya sabes, en el pico de concurrencia, como algo así como cultivar un jardín con 25 millones de personas, en cinco o diez segundos podrías tener a toda esa gente nueva. Posiblemente obteniendo ese nuevo activo. Por eso creo que es, en cierto modo, el futuro, porque creo que parte de la belleza de Grand Theft Auto es que incorporan muchísima calidad.

Lo van a poner en un DVD gigante. Tienen que asegurarse de que sea perfecto y no hay forma de iterar sobre eso. Tienes que conseguir que sea absolutamente perfecto ahí mismo. Y, y, y entonces yo, yo, supongo que finalmente. Sobre la preparación para el futuro, además de los cambios instantáneos, hay algo que parece bueno en almacenar la intención artística, ya sabes, almacenar la obra de arte original.

En cierto modo, ¿podrías mencionar cómo eso podría ayudarnos? Eh, 

Sergey: sí. Bueno, como estamos intentando capturar, eh, todo el contenido artístico original que podamos, y lo estamos almacenando para esto, estamos almacenando, eh, la versión original, eso es. De todos los activos. Y esto, como puedes imaginar, ya sabes, podemos.

No solo reducir la resolución generando versiones más simples de una textura, sino también aumentarla en el futuro, porque ya hemos capturado esa semántica, es decir, cuál era la intención original, así que podemos mejorar la calidad de este activo en el futuro. Y sin necesidad de que el usuario haga nada.

Podemos hacer que se vea mejor. 

Dave: Eso, y eso va a ser una gran pista de cara al futuro. Um, así que vamos, um, vamos a añadir un segundo componente a lo que hemos estado hablando. Así que estamos transmitiendo. Hacemos correcciones instantáneas. Transcodificación en la nube, entregamos cualquier LOD. Y luego, lo que insinuamos al principio, lo vamos a complementar con algo llamado Slim.

Así que Slim no es un programa de entrenamiento. No es como Roblox, no son los snacks de Roblox que, con suerte, nos harán sentir realmente bien a todos y pensar con claridad, eh, ¿qué es Slim en el contexto del motor de Roblox? 

Sergey: Sí. Eh, bueno. Eh, déjame dar un paso atrás y volver a poner este ejemplo, como el del árbol, ¿vale?

Así que tenemos, eh, tienes un árbol, y como dije, como cuando puedes tener varios árboles, como, eh, a lo lejos, eh, Slim es lo que convierte todos esos árboles individuales, como en un bosque y los optimiza, ya no de forma individualizada, sino optimizándolos como algo más grande, eso es agregación, como de elementos individuales y, eh.

Y es la tecnología Slim. Siempre optimiza esos activos, en un contexto específico. Digamos que tienes un edificio, ¿no? Y un montón de, eh... habitaciones dentro de ese edificio. Si estás fuera del edificio, no te importan las habitaciones que hay dentro. Slim es consciente de este contexto y puede eliminar de forma muy eficiente todo el interior del edificio, como en ese caso, y generar una versión muy optimizada de ese activo para ti.

Dave: Hay tres casos de uso en los que, mientras diseñabas esto, hemos estado, ya sabes, en los que he estado pensando. Uno de ellos es que la gente está creando avatares cada vez más complejos. Y, históricamente, en Roblox hemos sido muy cuidadosos con cuántas capas de ropa puedes llevar, cuántas joyas puedes llevar, cuántas cosas.

Pero puede que en el futuro los avatares tengan muchas, muchas cosas, como un centenar. Y creo que nuestros creadores son muy expertos en rendimiento. De hecho, pueden limitar la fidelidad de los avatares porque quieren mucho rendimiento. Avatares que son complejos, número uno. Número dos, como has mencionado, puede que haya un centenar de árboles por ahí y estén muy lejos, y nadie interactúe con ellos.

Y, y luego, en tercer lugar, quizá un edificio con habitaciones en su interior. Eh, creo que lo que, eh, vamos a intentar hacer aquí es que, sea lo que sea, un avatar en movimiento, un montón de árboles o un edificio, este mismo sistema se va a componer esencialmente en un único objeto, una única malla, una única textura, y eso es absolutamente alucinante.

Eh, 

Sergey: sí, tienes toda la razón. Esa es una buena forma de expresarlo. Es como si ese sistema generara dinámicamente una representación de composición, a partir de múltiples activos, y determinara, ya sabes, los límites de esa composición, el nivel de detalle de la misma, de forma dinámica, siempre operando en este contexto del mundo.

Así que es exactamente igual que en dos experiencias diferentes, que podrían optimizarse de forma distinta en función del dispositivo de destino, del contexto en el que se utilizan, y... También admitimos actualizaciones dinámicas para ese contenido. Así que no es siempre así, no es una optimización estática.

Si algo cambia con el tiempo, esto se reflejará en la representación optimizada porque podemos actualizarla dinámicamente. 

Dave: Es... es casi... una de las razones por las que me gusta tanto esto es que casi me siento como si fuera un desarrollador de Roblox. Y realmente quería una escala masiva y, por ejemplo, avatares muy complejos.

Quizá esté soñando con esto, como que puedo acercarme a alguien que está cerca de mí. Pueden quitarse el sombrero, pueden ponerse alguna joya nueva, que es la forma en que este sistema va a funcionar con objetos que están cerca, puede funcionar con alta fidelidad normal. Y luego, a medida que ese avatar se aleja, se reduce a un único objeto.

Y a medida que se aleja, con el LOD. Eh, bromeamos diciendo que lo máximo sería que un avatar muy lejos tuviera unos 12 triángulos y una textura realmente pequeña. Así que esto es, esto es casi lo que un desarrollador como yo, creo, ha soñado. Y luego creo que esto hace que, eh, una de las cosas que esto hace posible es un mundo más grande.

En todos los dispositivos. 

Varun: Por supuesto. Quiero decir, lo que Slim hace esencialmente es ofrecernos un nuevo eje de escalabilidad. Hemos hablado mucho sobre la transcodificación en la nube con diferentes niveles de detalle. Ahora estamos añadiendo otro nivel de otro eje aquí, que tiene que ver con la composición. ¿Verdad? Y puedes pensar en un dos por dos aquí, y cualquier punto de ese es una experiencia válida.

Así es. Así que podrías tener alta calidad y baja composición, o alta calidad y alta composición si estás en un dispositivo de gama muy baja o en un dispositivo diferente. Y todos esos puntos tienen sentido. Así que si hablamos de un mundo enorme, ese mundo entero podría ser de 12 triángulos. Además, si estás lo suficientemente lejos, o si no, si no supone ninguna diferencia.

Dave: Y, entonces, pensando en la experiencia del usuario y en cómo Slim puede conducir a una mejor experiencia de usuario. Si pensamos en LOD, pensamos en la transcodificación en la nube. Si pensamos en Slim, pensamos en el streaming en relación con Roblox hoy o, o hace un año, cómo. ¿Cómo puede esto afectar a la experiencia del usuario? 

Tsvetan: Sí, bueno, Slim... creamos Slim con la idea de que... permitimos a los desarrolladores crear mundos más ricos, grandes y complejos que van a...

Eh, comportarse e interactuar con el usuario final. ¿Siemens? Eh, sí, muy fácilmente. Como sin, eh, y el usuario final, eh, la experiencia de usuario es exactamente la misma que si tuvieras la, eh, máquina más potente. Y, eh, Slim es, um, este sistema que hoy en día permite, um, modelos estáticos. Y estamos, eh, ya sabes. Permitiendo en el futuro avatares y modelos dinámicos que se, um, generan, eh, jerárquicamente, eh, para que podamos, eh, hacer que el sistema sea lo más rápido posible para el usuario final, 

Dave: lo que para el usuario final puede significar mundos más ricos en dispositivos de gama baja.

Podría ser en mi teléfono de gama baja. Puedo jugar contigo en tu PC para juegos. Eh, los creadores pueden hacer modelos más, eh, sin preocuparse por el número de capas de ropa de un avatar. Vehículos más complejos, eh, complicados. Eh, los objetos mecánicos también se comprimirán con Slim, lo cual va a ser realmente genial.

Y luego... Eh, quizá pensar en cómo funcionan juntos. Hablamos de la transcodificación en la nube, eh, para ofrecer un LOD más bajo. Luego hablamos de Slim, que son modelos realmente ligeros. ¿Funcionan juntos? 

Varun: Tienes toda la razón. Y a eso me refería con lo del acceso. Así que todos los modelos Slim pasan también por el mismo proceso de transcodificación en la nube.

Porque una vez que los compones, y una vez que se decide qué Slim usar en función del contexto y del contenido, así es como debe ser la composición. Pasa por el mismo proceso de transcodificación y luego genera una versión de baja calidad, una de alta calidad, una versión para Android y una para iOS para todo.

Así que es, es, es muy, muy complementario, um, entre, 

Dave: y eso, en realidad, para el creador es casi como un doble golpe: un avatar muy complicado a distancia compuesto en un modelo «slim» y luego transcodificado. Ese avatar, una vez más, podría ser de 12 triángulos y de un solo color. Y, y lo que 

Varun: lo que esperas ver, o lo que yo esperaría ver, es una especie de primer paso.

Todas las experiencias existentes pueden empezar a ejecutarse en dispositivos cada vez más básicos. 

Dave: Sí. 

Varun: Pero lo realmente emocionante son los efectos de segundo orden, ¿verdad? Los creadores empiezan a darse cuenta de que, oh, puedo poner más cosas en el mundo. Oh, puedo añadir. Bueno, si lo piensas 

Dave: en ello, um, si estoy creando un vídeo. Es casi como si la cámara estuviera diseñada a la perfección.

Ya sabes, cojo mi cámara 4K y nunca me preocupo, sea donde sea que apunte la cámara, de si podré grabar un vídeo como lo hago. Pero nuestros creadores no tienen esa cámara hoy en día. Como si apuntaran la cámara al lugar equivocado. El mundo podría explotar, ¿no? Demasiada resolución, como si apuntaran la cámara a una multitud de 10 000 personas, es como... así que esto es casi como liberar la cámara 3D inmersiva, 

Varun: pero dando libertad a los creadores.

Así que podemos hacer expansión de plataforma y luego de género. Sí, 

Dave: y, y creo que hay un momento que no sabemos cuándo será, es una mezcla de la ley de Moore, computación Slim 3D, streaming de IA, upscaling de tecnología local, lo que sea. En el que puede que esta cámara ya no sea una limitación, en el que si quisieras cien mil personas en un estadio gigante, fotorrealistas pasando el rato con tus amigos, transmitiendo en un dispositivo de gama baja con baja latencia, se sienta bien.

Eso será, creo, cuando digamos que la cámara inmersiva de 40 cámaras está madura; la, eh, la buena noticia o la mala noticia es que hay mucho trabajo por hacer. Así que eso hace que nuestro trabajo sea bastante interesante. Y yo, supongo que, en ese tema de qué es, a qué velocidad avanzamos hacia esa cámara tridimensional y tetradimensional definitiva, um, Sergei, ¿qué es lo siguiente para Slim y, bueno, qué optimizaríamos después de esto?

Así que 

Sergey: en cuanto a Slim, bueno... Tenemos por delante unos cuantos pasos importantes. Es decir, el siguiente paso es hacer que Slim sea totalmente dinámico y admita avatares, vehículos en movimiento, mecanismos móviles y todo eso. Pero el paso más importante después de eso es hacer que Slim sea jerárquico, como mencionó Barron, ya sabes, de modo que Slim genere prácticamente los mismos activos que los activos normales.

Pasan exactamente por el mismo proceso de streaming. Los optimizamos porque cada modelo Slim tiene sus propias ologías y esas cosas. Pero, ¿y si pudiéramos llevarlo aún más lejos? ¿Y si pudiéramos combinar varios Slims en uno, como un mega-Slim, y luego repetirlo una y otra vez de esta forma, como un fractal?

Dave: Bueno, esto formaba parte de nuestra pregunta de diseño. Porque cuando tú, yo propuse Slim originalmente, estábamos trabajando en avatares y teníamos un proyecto aparte. Pensábamos en cómo juntaríamos cien avatares y cómo simularíamos a cien mil personas en un estadio. Y lo que fue realmente... hubo un día fascinante en el que creo que dijiste: «¿Sabes qué? Quizá podamos coger avatares «slim» y poner cien de ellos en una colección de cien avatares con exactamente la misma tecnología».

Y eso fue más o menos lo que dijimos. ¿Te dejó alucinado esa naturaleza jerárquica? 

Sergey: Eh, sí, eh, eso es exactamente. Y si llevas este ejemplo al extremo, puedes imaginarlo así: vale, nuestra cámara virtual puede ver todo el planeta. Vemos todo el planeta y es como, ya sabes, una esfera, con textura.

Cuando la cámara se acerca, ves los continentes por separado, luego ves las ciudades individuales y luego puedes bajar hasta, por ejemplo, un estadio lleno de gente, porque toda la simulación se ejecuta en el servidor y el cliente no necesita saber, eh, sobre todo el mundo.

Está claro que no puedes meter todo el planeta en la memoria de un dispositivo, ni siquiera en un ordenador potente. Pero nuestros servidores son muy potentes y, al generar esta representación clave para Slim, podemos ir desde la escala de un planeta hasta la escala de una habitación, o incluso hasta un micromundo.

Dave: Bueno, claro. Podemos llegar hasta el reloj que tú o yo llevamos puesto, fijándonos en la pequeña manecilla del reloj e incluso más allá de eso. Y entonces, al pensar en esto, eh, Satan, ¿qué te parece? ¿Cómo podría esto cambiar lo que los creadores empiezan a hacer? Claro. Vamos a... Esperemos que nos libremos de eso de: «Ay, Dios mío, tengo que preocuparme por el rendimiento de un avatar».

¿Algún otro cambio que creas que podríamos ver? 

Tsvetan: esto eliminará, eh, en mi opinión, todas las limitaciones que tienen hoy en día. Ellos, como has dicho, no tendrán que pensar en, eh, lo complejo que es el mundo que están creando. Solo tendrán que pensar en lo que quieren presentar como dinámica de juego a sus, eh, jugadores.

Nada más. De todo lo demás nos encargaremos nosotros automáticamente. 

Dave: Bien, y me parece interesante profundizar en algunas de esas cosas automáticas. Ya sabes, en el antiguo Roblox tradicional hacíamos algo llamado «atlas de texturas». De hecho, teníamos una plantilla para una textura, y tú tenías que averiguar cómo funcionaba. Supongo que con un modelo «slim» eso es completamente automático.

Eh, como la generación de esa textura a menor resolución. 

Tsvetan: Sí. Eso será automático, al igual que la determinación de esos, eh, bloques de construcción que Sergei explicó en el mundo dinámico jerárquico. 

Dave: Vale, pues ahora, um, ahora nos vamos a dejar alucinados y vamos a hablar de, um, es fácil imaginar que algo sea más simple, ¿verdad?

Es casi como si fueras un artista, es muy fácil imaginarlo. Hacerlo más tosco y aplanarlo un poco, es mucho más difícil imaginar que algo tenga una resolución más alta. Y por eso quiero, quiero profundizar un poco en, um, el futuro de la IA y ahí, hay mucho trabajo ahora mismo en IA, como cómo vamos a generar videojuegos y streaming inmersivo en tiempo real y modelos del mundo y todo eso.

Y yo... siento cada vez más que vamos a descubrir que esto no es algo monolítico. Va a ser una pila de 3, 4, 5 o seis modelos que funcionan todos juntos, incluyendo, ya sabes, una línea de comandos en la que, si estamos pasando el rato, podemos, como hacemos con 4D, simplemente decir: «Convierte el Monumento a Washington en Godzilla» y, ¡bum!, va a suceder allí mismo.

Eh, y, en última instancia, generar objetos, mundos o juegos completos. Eh, y con suerte en un contexto multijugador. Así que estamos, estamos paseando juntos, los cuatro, y decimos: «Oye, por ahí, a los cuatro nos gustaría diseñar un nuevo juego y que todo apareciera por arte de magia». Hay un aspecto secundario. Eh, además de la línea de comandos, la generación de mundos y el 3D, que es lo que decías, eh, está el upscaling y, y eso, eh, si, si imagino a veces el clásico Crossroads, que es un juego de hace 20 años en Roblox, en realidad hay suficiente información ahí.

Si tomáramos el Crossroads clásico y, Sergey, tú dijiste, hiciéramos que esto tuviera un aspecto... como una versión medieval fotorrealista en la que la jugabilidad pudiera ser la misma. Ya sabes, todas estas divertidas y pequeñas herramientas de lanzacohetes son las mismas, pero de repente todo tiene un aspecto nuevo. Entonces, ¿cómo funcionaría esto en este contexto?

No sé quién quiere intervenir. Sobre el LOD, porque ahora el LOD tiene que subir en lugar de desaparecer. 

Varun: Yo, creo que uno de los puntos que Sergey mencionó antes, ¿verdad? Se trata de conservar la mayor parte posible de la intención artística original para que podamos hacer algunas de estas cosas en el futuro. Y, y mi ejemplo favorito, y este es un ejemplo aleatorio, pero imagina que estoy usando una textura, pero esa textura era en realidad una foto que alguien tomó si realmente almacené la apertura.

El tamaño, si hubiera guardado la apertura del diafragma cuando se tomó esa foto. Ahora mi algoritmo Uprising tiene mucho más contexto. Sí. Si sé dónde se está utilizando esa textura, si sé que se está utilizando en un castillo, ¿se está utilizando en el suelo? Mi algoritmo Uprising puede ser mucho más inteligente a la hora de crear eso y mantener la intención original del creador de principio a fin, tanto en ese PC de gama alta como en algún PC futuro que ni siquiera se ha inventado todavía.

Así que 

Dave: mostramos esto en la RDC, creo que mostramos un vídeo de unos 15 segundos de Crossroads con el muestreo mejorado. Eh, ¿podemos hablar de lo que podría pasar realmente? El activo está en la nube, los objetos 3D, las texturas. Eh, se envía una indicación adicional a nuestro sistema de contenido que dice: «Mira, todos estos activos forman parte de, eh, lo que debería ser un mundo medieval mucho más fotorrealista de lo que uno pueda imaginar».

Entonces, todos esos diferentes LED se regeneran para estar mucho más cerca de la versión fotorrealista mediante lo que llamaríamos un muestreador 3D UPS o, en realidad, un creador generativo 3D. Entonces, ¿quién quiere profundizar en lo que podría pasar con el castillo, por ejemplo? 

Sergey: Yo, yo, creo que, como acaba de mencionar Baron, ya sabes, parece que estamos capturando algo mucho más semántico de ese mundo.

Eso es lo que es extremadamente importante. Por ejemplo, en este ejemplo de la encrucijada, ¿verdad? Si te fijas en el castillo... Eh, desde mi perspectiva de activos individuales, son simplemente, ya sabes, una serie de bloques, solo son cajas. Y no tienes suficiente contexto, ya sabes, no puedes hacer que esos bloques se vean mejor.

Y el castillo es, eh, es más que solo bloques individuales. Es la suma de todos ellos. Eh, y Slim, dado que Slim opera en este contexto, Slim es consciente de esto como un todo. Así que, ahora cualquier conjunto sabrá mucho más sobre, ya sabes, el castillo en su conjunto, no sobre activos individuales.

Así que puede crear una versión mucho mejor de ese castillo remasterizado porque, bueno, simplemente entiende que 

Dave: como, y, y, y en cierto sentido, uno podría imaginarlo sin tener ese castillo de Crossroads ya existente. Y para que todo el mundo lo sepa, Crossroads es un juego de Roblox muy antiguo, de aspecto pixelado.

Ese castillo es, en realidad, una ayuda muy buena para la indicación. «Constrúyeme un castillo». Esa es una indicación bastante abierta. Como si fuéramos a obtener un castillo aleatorio con una forma aleatoria. Pero el castillo de Crossroads, en cuanto a dimensiones y tamaño, es una gran fuente de información para mejorar la resolución y convertirlo en un castillo de alta calidad.

Sergey: Eh, sí. Eh, eso es exactamente así. Porque, como, eh, esta parte tridimensional del castillo, en primer lugar, va a ser muy importante desde el punto de vista de la jugabilidad, ¿no? Así que no puedes generar cualquier castillo y hacer que funcione para el juego. Eh, porque. Pero si puedes capturar todas las dimensiones, toda la semántica, en todos los contextos, en lo que, eh, se ha utilizado, entonces puedes aumentar la resolución de manera muy eficiente.

Y, y no vas a estropear tu juego al hacer esto. Porque, como esto, hay otra cosa muy importante. No quieres aumentar la resolución de un activo que pueda hacer que tu juego sea injugable. 

Dave: Bueno, bueno, creo que hay un mundo futuro en el que, además de toda tu información 3D, podrás editar tu información 3D o editar tu prompt.

Ambos se unen para generar ese mundo, de modo que... La actualización de cinco segundos de la que hablamos, que es una modificación de activos en el futuro. Puede ser una actualización de la indicación de cinco segundos y un pequeño toque más en la indicación. Y luego generar ese mundo de forma diferida bajo demanda. Y, y luego creo que hay una última cosa, um, cuando pensamos en todas las dimensiones de cómo la IA puede combinarse para hacer que estas cosas sean fotorrealistas, no lo estamos haciendo.

Ahí hay una capa final, que es la capa 2D. ¿Qué está pasando en tu PC para juegos? ¿Qué pasaría en algún dispositivo de vídeo en la nube donde podría producirse un muestreo aún mayor? Así que, um, por ejemplo, el pelo perfecto en mi cabeza. El mejor lugar para hacer ese pelo puede ser localmente con un muestreador 2D. Sé que has trabajado en muchos juegos que intentan hacer el pelo en 3D.

¿Qué opinas? ¿Crees que algún día todo el pelo se hará con remuestreo 2D o será pelo en 3D? 

Sergey: Sí, claro. Creo que nos estamos moviendo en esa dirección porque hay cosas que solo se pueden hacer en el espacio de pantalla, ya que es más eficiente. Déjame explicarlo así: es más eficiente hacerlo en el espacio de pantalla.

Por ejemplo, como esto, eh, como el pelo, el renderizado, ¿no? Y, bueno, o... Muchos motores de juego actuales hacen cosas basadas en ML, como el upscaling, pasando de, eh, 1080p a 4K. Pero se puede hacer mucho más que eso, ¿no? Se puede cambiar el sombreado, se puede cambiar el aspecto de las cosas.

Y si llevamos este ejemplo al extremo, un motor de videojuegos puede simplemente renderizar, ya sabes, información semántica, como para un algoritmo de ML, y entonces este algoritmo de ML generará, ya sabes, pelo con buen aspecto, o materiales con buen aspecto. Como en el espacio de renderizado, la directiva.

Dave: Genial. Eh, bueno, y entonces, ya que estamos terminando, quizá para todos los programadores de C++ que hay por ahí, los programadores de lenguaje ensamblador, que, eh, ojalá yo fuera así, es una de las cosas más divertidas del mundo. Estamos haciendo algo muy difícil aquí, ¿verdad? Estamos intentando, eh, hacer que todas estas tecnologías funcionen en todos los dispositivos.

Pregunta sobre la transcodificación. La pregunta sobre la transcodificación es: sé que muchos ordenadores tienen optimizaciones, eh, con registros SIMD y cosas por el estilo para que todo esto funcione más rápido. ¿Hemos empezado a probar con SIMD en alguno de nuestros transcodificadores, o es una optimización para el futuro? 

Tsvetan: Eh, bueno, en primer lugar, por cierto, la transcodificación también puede ejecutarse en el motor hoy en día.

Vale. Excelente. Bien. Así que estamos aprovechando las optimizaciones CMD, pero estamos, eh, mirando más allá de eso utilizando GPUs y, eh, otras, 

Dave: ¿Así que la transcodificación en GPU es una posibilidad? 

Tsvetan: Bueno, sí, lo estamos estudiando. 

Dave: Vale. Lo cual es súper, súper divertido. Vale, pues, um, gran actualización para todos, eh, eh, para aquellos que quieran algo visual, posiblemente RDC, presentación en el escenario principal.

Creo que deberíamos, teníamos imágenes de gran parte de esto. Todo de lo que hemos hablado está en marcha. Eh, lo estamos siguiendo de cerca y yo, yo, realmente creo que, eh, todos vosotros y los distintos equipos que hay detrás estáis contribuyendo de verdad a lo que sería, lo que a veces llamo «motor de juego 2.0», eh, que se basa en gran medida en la nube.

Con un gran apoyo de los transcodificadores en toda esta tecnología. Así que gracias a todos. Creo que hoy hemos dejado a todo el mundo boquiabierto. Se lo agradezco de verdad. 

Tsvetan: Gracias. 

Dave: Vale, hola, soy Dave. Eh, una vez más, charlas técnicas, y esperamos veros la próxima vez. Gracias de parte de todo el equipo. Gracias.