Ampliando Unity WebGL con Javascript

One of the things that we do to support this idea is target over 25 different platforms and technologies from desktop, PC, Mac, Linux, to mobile, iPhone, Android, PlayStation, Xbox, Virtual Reality, Augmented Reality and one my favorites, the Web. When we build for the Web, we build like for any other platform where we compile the engine and the game logic together into a final executable. In this case, the final executable is WebAssembly and we use different tools to achieve this.

We use this Emscripten which is a C++ compiler that can generate WebAssembly in JavaScript. All the libraries for the engine and the built-in libraries are written in C++ and all the user code and public APIs are written in .NET C Sharp. We have to compile the .NET C Sharp code into C++ in order for it to be compiled with Emscripten. So we use another tool called iotcp to do this. It takes the .NET assemblies and does some stripping and massaging of those assemblies to reduce the code size and then generates C++ code from there. The C++ code can then be compiled with Emscripten to WebAssembly.

For the graphics side of things, Unity has different graphics patterns that it supports from DirectX, Vulkan, Metal, and OpenGL. On the web, graphics are defined by WebGL, which is a variant of OpenGL. So when we build for the web we tell Unity to use the OpenGL graphics device. And when it does this, Emscripten and the compilation processes will generate WebGL calls for all the OpenGL calls that Unity are making. And for shaders, they're typically written in a shading language, a DirectX shading language in Unity, but those aren't directly supported by WebGL so we have to convert those into GLSL to be used by WebGL. To do this, we have shader compilers that will translate HLSL into GLSL.

We can extend Unity with plugins that provide new APIs to Unity written either in C++ or in this case we'll use JavaScript. With the JavaScript plugins for WebGL, we can extend Unity to access browser features that aren't available in the regular Unity API. We can call these JavaScript functions directly from C-sharp and vice versa you can call C-sharp functions from JavaScript. When you define a JavaScript plugin, you put it into the Assets Plugins folder for WebGL and there's two different types of files from the JavaScript function. The main type of file is a JSLib file. This is where your public APIs from JavaScript will be and define the functions that will be callable from C-sharp. A JSPri file is just arbitrary JavaScript that you can include with your plugin. This will get compiled before the JSLib files so that it can provide JavaScript objects and functions that can be used and shared between your JSLib files. This is just a way to keep your projects clean so that your JSLib files can be your public APIs and you put all the rest of your code in JSPri. There's no requirement to do this. You could just use a single JSLib file. I like to keep things separate. The example of plugin I'll be talking about today is integrating WebXR's augmented reality mode into Unity. Unity currently does not support WebXR with its built-in APIs, but we can extend Unity using plugins to do this. This is not an official plugin.

Esto es solo para fines de demostración, y es una implementación muy mínima de WebXR. No estoy implementando todas las características divertidas de WebXR. Solo te estoy mostrando cómo hacer esto. Todo el código fuente para este proyecto se puede encontrar en el proyecto de GitHub aquí, y puedes usarlo para cualquier propósito. El archivo JSLib es donde declaramos la API pública para nuestro complemento. Y aquí proporcionaremos funciones que podemos llamar desde C sharp para inicializar WebXR y obtener su información en su estado actual. Estas funciones se pueden llamar directamente desde C sharp, y esta es la API pública que estamos proporcionando. Y la función merge into aquí es parte de el script, y lo que hace es tomar todas las funciones que estamos declarando en el sujeto y exponerlas a C++ o C sharp. Para llamar a JavaScript desde C sharp, declaramos las funciones como funciones estáticas externas en C sharp, y también las etiquetamos para que se codifiquen desde la DLL interna en Unity. Lo que esto hace es decirle a C sharp que estas funciones no están definidas en el lugar, sino que provienen de una fuente externa, y debido a que WebGL no proporciona soporte para DLL externas, todo se empaqueta junto y el nombre de la DLL interna define que provienen de la DLL incorporada.

Aquí también implemento versiones MTEW de las funciones para plataformas no-WebGL, porque las plataformas no-WebGL no admiten JavaScript. Queremos llamar a versiones ficticias de estas funciones para mantener contento a C sharp y evitar que el editor se queje de que no tienes implementaciones para estas funciones. El archivo JSPRE es donde pongo la mayor parte del código para mantener el archivo JSO simple, y aquí es donde defino todos los objetos principales y métodos para interactuar con WebXR, y aquí puedes poner todas las funciones que se pueden llamar desde tu JSO y gestionar el estado de tu complemento. Nuevamente, no es obligatorio usar un archivo JSPRE. Lo encuentro conveniente. A veces quieres llamar a C sharp desde JavaScript. En algunos casos, tienes una función asíncrona en JavaScript que se llamará en algún momento posterior y quieres llamar a una función de C sharp cuando ese proceso asíncrono haya terminado. Puedes hacer esto declarando un tipo de delegado en C sharp que luego se puede activar desde JavaScript. Puede pasar ese puntero de función de ese tipo de delegado a la función de JavaScript, que puede retenerlo como un puntero, y luego puede llamar a esa función de C sharp cuando haya terminado. Y luego definimos la función de devolución de llamada en C sharp como una función estática. JavaScript no tiene noción de objetos de C sharp, por lo que lo declaramos como una función estática, y desde allí puedes usar variables globales o acceso a singleton para cualquier estado de C sharp que desees. Y desde el lado de JavaScript, podemos usar la función dyne call de la inscripción para llamar la devolución de llamada de C sharp. Esto también puede ser una devolución de llamada de C++. Por lo tanto, el argumento vi para dyne call define el tipo de retorno como void y toma un solo argumento entero y esto puede definir la declaración de función que tienes. Y la devolución de llamada de cambio de estado es la función de puntero que pasé desde C sharp, y estos son los argumentos que estoy pasando a la función de devolución de llamada de C sharp, que es un estado entero. También puedes compartir data entre C sharp y JavaScript. Si asignamos memoria en el lado de C sharp, se asigna en el montón de scripting final y ese montón de scripting final es visible desde JavaScript. Podemos leer y escribir en ese montón de scripting desde JavaScript. Aquí estoy asignando 16 flotantes que se utilizan para almacenar la matriz de vista de WebXR para que pueda actualizar la matriz de vista de la cámara en Unity. Puedo pasar ese data a JavaScript como un simple puntero de función data y luego ahora JavaScript tendrá acceso a ese data.

Y luego, desde el lado de JavaScript, puedo escribir en esa función en el puntero de data usando las variables del montón de la inscripción. En este caso, el montón 32 es una vista de float 32 del montón data.

Ahora estoy copiando la matriz de vista de WebXR en el puntero de data que le paso. Divido el índice del puntero entre dos porque el montón está alineado por cuatro y, por lo tanto, el índice del montón es la dirección del puntero dividida por cuatro.

Puedo interceptar las llamadas de Unity al navegador para cambiar el comportamiento de cómo Unity interactúa con el navegador. En algunos casos, la forma en que Unity interactúa con el navegador no funciona con lo que queremos hacer en nuestro complemento. Por ejemplo, WebXR requiere que se agregue el atributo compatible con XR al contexto webGL. Cuando Unity crea el contexto webGL, no tiene este atributo porque no conoce WebXR. Entonces, lo que podemos hacer es reemplazar la función de contexto webGL de Emscripten con nuestra propia función personalizada. Ahora, cuando Unity llama al contexto webGL, está llamando a nuestra función personalizada en lugar de la incorporada. Luego podemos inyectar el atributo compatible con XR que webXR desea en los atributos para ese contexto webGL y luego llamar a la función original para crear el contexto ahora con ese atributo personalizado agregado. Este es un ejemplo de uso de API privadas y de trabajar alrededor de las cosas que Unity hace mediante la interceptación de llamadas de función entre Unity y el navegador utilizando la naturaleza dinámica de JavaScript. Debido a que estamos utilizando API privadas aquí, no hay garantía de que esto funcione en futuras versiones de Unity. Pero a veces tienes que hacer cosas como esta para trabajar alrededor de limitaciones.

Otra función que queremos interceptar para que WebXR funcione con Unity es que WebXR tiene su propio búfer de cuadros en el que desea que se renderice. Esto tiene, en el caso de la realidad aumentada, la alimentación de la cámara ya incluida, y desea que se renderice encima de eso. Unity está tratando de renderizar sobre el lienzo que está en tu pantalla, y no sabe nada acerca de el búfer de cuadros de WebXR. Entonces, lo que queremos hacer es interceptar la llamada que Unity hace cuando encuentra el búfer de cuadros actual, y detectar cuando Unity intenta dibujar en el búfer de cuadros del lienzo. Podemos saber eso porque el búfer de cuadros nulo es lo que WebGL usa para dibujar en el lienzo, y cuando Unity hace eso, podemos interceptar la función bind frame buffer, detectar que está intentando enlazar el búfer de cuadros nulo en el lienzo, y reemplazar el búfer de cuadros nulo con el búfer de cuadros de WebXR, y luego llamar a la función original bind frame buffer. Ahora, cuando Unity enlaza el lienzo, interceptamos y enlazamos el búfer de cuadros de WebXR, y Unity luego dibujará en el búfer de cuadros de WebXR. Otra función que queremos reemplazar es la función clear de WebGL porque Unity intentará borrar el búfer de cuadros del lienzo cuando dibuje en él. No queremos que se borre el búfer de cuadros de WebXR porque ya tiene la vista de la cámara en él. Queremos que Unity dibuje encima de eso, así que podemos interceptar la función clear de WebGL. Si sabemos que el búfer posterior, el lienzo, está actualmente enlazado, o en este caso, el contexto de WebXR, simplemente omitimos la función clear. De lo contrario, la llamamos normalmente. Y ahora, cuando se enlaza el búfer de cuadros de WebXR, Unity intenta borrarlo cuando se mezcla, el borrado se bloqueará y Unity simplemente dibujará encima de lo que ya está allí, que es la vista de la cámara. Otra función que queremos interceptar es requestAnimationFrame. Unity utiliza esto para controlar la velocidad de fotogramas, y esto es lo que WebGL utiliza para su renderizado, pero WebXR tiene su propia versión de requestAnimationFrame en la que desea que se renderice. Entonces, queremos usar eso en su lugar. Pero como Unity está utilizando la función requestAnimation incorporada, podemos sobrescribir la función requestAnimation incorporada con la nuestra, y dirigirla a la versión de WebXR de la función. Ahora, cuando Unity llama a requestAnimationFunction, está llamando a nuestra función, que luego llama a WebXR requestAnimationFrame, que llamará al callback, y luego le dirá a Unity que haga su renderizado desde allí. Ahora, ese callback tiene toda la información de WebXR en él, y podemos usar esa información para actualizar la vista de la cámara de Unity con esos datos compartidos y luego llamar al callback para que Unity haga su renderizado.

Entonces, si juntamos todo esto, podemos ver a Unity renderizando en la página web. Comenzamos con el contexto de WebXR, y Unity ahora está renderizando en la vista de cuadros de WebXR. No borra el búfer posterior, por lo que está renderizando encima de la vista de la cámara, y todo se integra. La matriz de vista de WebXR se pasa a Unity para que pueda actualizar su vista de cámara, y todo se integra. Ahora, como dije, esta es una implementación muy mínima de WebXR. Para una implementación más completa, otros desarrolladores han hecho un gran trabajo con eso. DeepAnthro tiene un excelente paquete de WebXR disponible en su GitHub que puedes usar para renderizar con modos de realidad virtual y realidad aumentada de WebXR, con muchas más funciones. Lo recomiendo encarecidamente. Y eso es todo lo que tengo para compartir hoy. No dudes en hacer preguntas si tienes alguna. Estoy encantado de responder, y muchas gracias por tomarte el tiempo.

Sí, tal vez en Discord puedas publicar eso.

Sí, exactamente. Y en un momento en el que pueda pensar con más claridad. Claro, no te preocupes. ¿Qué hay de... esta es una pregunta para mí. ¿Qué otras funcionalidades web ejemplos crees que se podrían integrar en Unity con un complemento de JavaScript? Bueno, hay muchas API web diferentes que tienen diferentes niveles de soporte para los navegadores, como transporte web, RTC web y cosas así que que no tenemos API directas en la capa de C Sharp de Unity, pero definitivamente podrías hacer esto de manera similar para exponerlo a Unity y agregarlo a tu juego. Entonces, podrías hacer RTC web. Uno de nuestros desarrolladores hizo un prototipo utilizando transporte web que fue bastante exitoso. Entonces, hay mucho, cualquier cosa que puedas hacer con una API web, y, ya sabes, realmente abre eso. Tiene mucho sentido. Y me preguntaba, si estuviera haciendo, si estuviera publicando algo con Unity WebGL, ¿dónde crees que la mayoría de las personas alojarían sus esquemas de exportación de Unity WebGL o contenido interactivo? Entonces, quiero decir, como cualquier proyecto web, puedes alojarlo en tu propio servidor o Unity tiene, ya sabes, servicios como play.unity.com que pueden alojar cosas para ti. Y, ya sabes, cuando alojas tu, ya sabes, lo haces en tu propio servidor, puedes ser mucho más especializado para tu juego y utilizar, ya sabes, compresión Brotli o gzip, y configurar tu servidor para que sea correcto para eso. Pero sí, no hay limitaciones en cómo puedes alojarlo. Nosotros, cuando construyes tu juego, puedes especificar la plantilla HTML y el andamiaje que lo rodea. Y así puedes personalizarlo para lo que sea que vaya a ser tu objetivo y cualesquiera necesidades técnicas que tengas. Eso es genial. Entonces parece que podrías publicarlo en cualquier lugar, podrías publicar cualquier juego HTML5, juego JavaScript, como Newgrounds o Itch o realmente cualquiera de esos juegos, cualquier plataforma así. Sí, exactamente. Y muchas plataformas y servidores diferentes alojan juegos de Unity, así que realmente no hay una limitación técnica para eso. Muy bien. En algunos casos, requiere más conocimientos técnicos para configurar las cosas correctamente, pero se trata de mejorar las herramientas y la documentación para simplificar esas cosas. Y todas esas son cosas en las que estamos trabajando activamente. Increíble. Y ¿qué hay de, recuerdo vagamente un proyecto llamado Unity Project Tiny. ¿Puedes hablar un poco sobre eso y qué es? Claro. Project Tiny, tenemos una tecnología llamada DOTS, Data Oriented Technology Stack, y Project Tiny fue un derivado de eso, que te permite construir juegos de manera mucho más modular.

Y así no tienes el motor monolítico gigante, sino que seleccionas las piezas que deseas, para que puedas crear juegos muy pequeños. Y eso se suspendió temporalmente mientras los desarrolladores se centran en el lado de renderizado de la tecnología DOTS. Pero es algo en lo que invertiremos más en un futuro cercano. Y eso mejorará drásticamente cosas como el tamaño del juego, el tamaño del paquete, los tiempos de carga y todas estas otras cosas.

¿Qué hay de una pregunta final? ¿Hay alguna característica de Unity en la que estés trabajando o que te emocione y puedas compartir con nosotros? Bueno, lo que todos están interesados, aparentemente, es WebGPU. Y eso es algo en lo que estoy trabajando activamente y tenemos una implementación de eso. No se hará pública. No hay una línea de tiempo para eso, pero está en proceso.

Eso es increíble. ¿Has encontrado dificultades? Porque sé que la especificación de WebGPU ha estado cambiando en los últimos meses más o menos. ¿Ha sido un factor? Es como desarrollar sobre arena movediza. Pero he estado muy involucrado con el Comité de Estándares para ayudar a asegurar que WebGPU tenga lo que Unity necesita y también pueda beneficiar a otras personas y tratar de asegurarme de que la especificación tenga las API que necesitamos y que otras personas necesiten también. Eso es increíble. Y también, activamente, el tamaño de los proyectos de Unity que se están construyendo con WebGPU es mucho más grande que un pequeño concurso de JavaScript codificado a mano. Así que estamos trabajando en cosas como la compilación de shaders y cosas así. Y encontrando lugares donde todavía necesita trabajo y ayudando a descubrir errores y cosas así. Sí, me encanta eso. Eso me da mucha esperanza para el futuro de la web. Creo que tener personas como tú involucradas en el Comité de Estándares asegura que, una vez más, esta marea creciente eleva a todos los barcos, la plataforma evoluciona en beneficio de todos. Esto fue realmente genial. Muchas gracias por estar aquí, Brandon, y gracias por responder todas nuestras preguntas. Muchas gracias a ti también.