Configuración del reproductor WebGL

Esta página detalla la configuración del reproductor específica para la vista previa de WebGL. Una
descripción de la configuración general del jugador se puede encontrar aquí .

Otros ajustes

Propiedad: Función:

Representación

Ruta de renderizado

API de gráficos
automáticos
Propiedad: Función:

Lotes estáticos ¿Deben habilitarse los lotes estáticos?

Lote Dinámico ¿Deben habilitarse los lotes dinámicos?

Configuración

Backend de Scripting El backend de scripting está en gris ya que solo hay un backend de scripting
en WebGL.

Deshabilitar Cuando se marque, la aplicación enviará información sobre el hardware a Unity

estadísticas de HW (consulte la página dehwstats para obtener más detalles).

Scripting Definir Banderas de compilación personalizadas ( mire la página platform dependent

Símbolos compilation para más detalles).

Optimización

Nivel de compatibilidad Especifica el perfil API .NET activo. Mirar abajo.

de API

.Net 2.0 Librerías .Net 2.0. Máxima compatibilidad .net, tamaño de los archivos más
grandes

.Net 2.0 Subconjunto Subconjunto de completa compatibilidad .net, tamaños de archivo más
pequeños

Mallas de colisión Habilita la cocción de la malla de colisión durante la construcción.

precocidas

Shaders de precarga Habilitar la precarga del sombreador.

Activos de precarga Habilitar la precarga de activos. Especifique el tamaño de los activos para
precargar.

Código del motor de la Habilitar la eliminación de código para WebGL.

tira
 Propiedad: Función:

Compresión del vértice

Optimizar los datos de Elimine todos los datos de meshes que no sean requeridas por el material
malla aplicado a ellos(tangentes, normales, colores, UV).

Nivel de compatibilidad API

Usted puede escoger su nivel mono de compatibilidad api para todos los objetivos excepto el reproductor
web(webplayer). Algunas veces un .net dll tercero va usar cosas afuera del nivel de compatibilidad .net que
usted quiera utilizar. Para entender qué esta pasando en dados casos, y cómo mejor solucionarlo, coja el
“Reflector” en windows.

1. Arrastre los montajes .net para el nivel de compatibilidad de la API en cuestión en el reflector. Usted
puede encontrar estos en Frameworks/Mono/lib/mono/YOURSUBSET/
2. También arrastre sus montajes de terceros.
3. Haga click derecho en sus montajes de terceros, y seleccione “Analyze”.
4. En el reporte de análisis, inspeccione la sección “Depends on”. Cualquier cosa que el montaje de tercero
dependa de, pero no esté disponible en el nivel de compatibilidad .net de su preferencia va a ser subrayado
en rojo.
Configuración de publicación

Propiedad: Función:

Tamaño de Establece la memoria disponible para el tiempo de ejecución de WebGL, dada en

memoria WebGL megabytes. Debe elegir este valor con cuidado: si es demasiado bajo, obtendrá
errores de falta de memoria porque el contenido y las escenas cargadas no cabrán
en la memoria disponible. Sin embargo, si solicita demasiada memoria, es posible
que algunas combinaciones de navegador / plataforma no puedan proporcionarla
y, en consecuencia, no puedan cargar el reproductor. Vea aquí para más detalles.

Habilitar Habilitar soporte de excepción

excepciones

Almacenamiento en Habilite esta opción para almacenar en caché automáticamente los datos de sus
caché de datos contenidos en la máquina de los usuarios, de modo que no tendrá que volver a
descargarlos en ejecuciones posteriores (a menos que el contenido haya
cambiado). El almacenamiento en caché se implementa utilizando la API
IndexedDB proporcionada por el navegador. Algunos navegadores pueden
 Propiedad: Función:

implementar restricciones al respecto, como pedirle al usuario permiso para

almacenar datos en caché sobre un tamaño específico.

Puede encontrar más información sobre la configuración de publicación de WebGL en la página de Creación
y ejecución de WebGL .

Empezar con el desarrollo de WebGL

Qué es Unity WebGL?
La opción de construcción WebGL le permite a Unity publicar contenido como programas JavaScript que utiliza
tecnologías HTML5 y el API de renderización WebGL para correr el contenido de Unity en el explorador web.
Para construir y probar su contenido para WebGL, simplemente escoja el objetivo de construcción WebGL en
la ventana de Build Player, y oprima Build & Run.

Visión general técnica

Para correr en WebGL, todo nuestro código necesita estar en JavaScript. Nosotros utilizamos el toolchain de
compilación emscripten para hacer una compilación cruzada del código de ejecución de Unity (escrito en C y
C++) a [Link] JavaScript. [Link] es un sub conjunto muy optimizado de JavaScript que le permite a los motores
de JavaScript en AOT-compile código [Link] a un código nativo de buena calidad.

Para convertir el código del juego .NET (sus scripts C# y UnityScript) a JavaScript, nosotros utilizamos una
tecnología que llamamos IL2CPP. IL2CPP toma bytecode .NET y lo convierte en archivos fuente
correspondientes a c++, el cual luego compilamos utilizando emscripten para que sus scripts sean convertidos
a JavaScript. Este proceso de conversión podría tener algunos problemas de compatibilidad con su código
script en el lanzamiento de acceso temprano, el cual estamos trabajando por resolver, pero con tal de que
usted no requiera hilos o características de generación de código dinámico se espera que funcione.

Soporte de plataforma
El contenido de Unity WebGL es soportado en las versiones actuales de la mayoría de exploradores en el
escritorio, sin embargo hay unas diferentes en el nivel de soporte ofrecida por diferentes exploradores. Los
dispositivos móviles actualmente no son soportados por Unity WebGL.

No todas las características de Unity están disponibles en las construcciones de WebGL, la mayoría se debe
a restricciones de la plataforma. Específicamente:

 Los hilos todavía no son soportados debido a la falta del soporte de hilos en JavaScript. Esto aplica a ambos
el uso interno de Unity de hilos para mejorar rendimiento, y al uso de hilos en código script y managed dlls
(Básicamente, cualquier cosa en el namespace [Link] no se soporta).
 Las construcciones WebGL no pueden ser depuradas en MonoDevelop o Visual Studio. Ver: Depuración y
resolución de problemas de construcciones WebGL.
 Los navegadores no van a permitir un acceso directo a IP sockets para el networking (red) debido a razones
de seguridad. Ver: WebGL Networking.
 El api de las gráficas de WebGL es equivalente a OpenGL ES 2.0, el cual tiene algunos limites. Ver WebGL
Graphics.
 Las construcciones WebGL utilizan un backend personalizado para Audio, basado en el Web Audio API. Este
soporta solamente una funcionalidad básica de audio. Ver: Utilizando Audio en WebGL.
 WebGL es una plataforma AOT, por lo que no permite una generación dinámica de código
utilizando [Link]. Esto es lo mismo en todas las otras plataformas IL2cpp, iOS, y la
mayoría de consolas.

Compatibilidad del navegador con WebGL

El Unity WebGL soporta la mayoría de los navegadores desktop en cierto grado (8). Sin embargo, el nivel de
soporte y el rendimiento esperado varía entre los diferentes navegadores. Mire en la matriz de características
de abajo para darle una visión general de las características del navegador de interés al contenido de Unity
WebGL, y qué navegador lo soporta.

Tenga en cuenta que el contenido de Unity WebGL actualmente no es soportado en dispositivos

móviles. Puede que funcione, especialmente en dispositivos de alta-gama, pero la mayoría de dispositivos no
son lo suficientemente poderosos y no tienen la memoria necesaria para soportar el contenido de Unity WebGL.
Por esta razón, Unity WebGL va a mostrar un mensaje de advertencia cuando intente de cargar contenido en
los navegadores móviles (que puede ser desactivado si se necesita).

Tenga en cuenta que esta matriz de compatibilidad es valida para las versiones específicas de los navegadores
mencionados. Los navegadores se desarrollan rápidamente, por lo que mucho puede cambiar en las versiones
futuras de los navegadores.

Matriz de compatibilidad del navegador en desktop

Mozilla Google Apple MS MS

Firefox Chrome Safari 9.0 Internet Edge
42 46 Explorer 13
11

Soporte de WebGL habilidad de correr el X (1) X (1) X (Safari X (IE 11 y X

contenido de Unity WebGL 8 y posterior)
posterior)

Web Audio El Web Audio API es requerido X X X - X

para reproducir sonido en contenido de Unity
WebGL.

Soporte pantalla completa X X - (2) X X

Soporte de bloqueo del cursor X X - - - (3)

 Matriz de compatibilidad del navegador en desktop

Soporte de Gamepad X X - - X

IndexedDB (BD indexada) Requerida para un X (4) X X (4) X X

almacenamiento local como se es utilizada por
la característica de Data Caching, la
clase PlayerPrefs,
y [Link].

WebSockets Requeridos para Networking. X X X X X

WebRTC Requerido por la X X - - X

clase WebCamTexture

WebGL 2.0 - (5) - - - -

[Link] AOT compilación [Link] es un sub- X - - - X

conjunto de JavaScript para el cual un
navegador puede específicamente optimizar.
Los navegadores que implementan soporte a
[Link] pueden ser capaces de correr contenido
de Unity WebGL más rápido, ya que Unity
utiliza [Link].

Recomendaciones (6) (7)

Notas de pie de página:

1. Las GPU blacklists (listas negras) aplican. WebGL puede no estar soportado para unas tarjetas gráficas
viejas específicas. Los detalles disponibles están aquí y aquí.
2. Safari soporta el API Fullscreen (pantalla completa) de HTML5, pero ningún input del teclado cuando se
está en modo de pantalla completa, por lo que Unity va a desactivar la funcionalidad de pantalla completa
cuando corra en Safari.
3. Edge no soporta el bloqueo del cursor todavía, pero se espera que cambie en Edge 13.
4. Firefox hasta la versión 42 y Safari no va a soportar IndexedDB (BD indexadas) para el contenido
ejecutándose en un iFrame. Firefox 43 y posterior va a arreglar esto.
5. Firefox soporta WebGL 2.0, pero es desactivada por defecto y necesita estar habilitada en about:config.
6. Chrome puede que necesite una grande cantidad de memoria para parse la generación de código
JavaScript, el cual puede causar errores out-of-memory (sin memoria) o fallas cuando cargue contenido
en exploradores 32-bit. Ver aquí para más información acerca del uso de memoria.
7. Internet Explorer no soporta audio y es muy lento para soportar la mayoría de contenido de Unity WebGL
con resultados decentes. Por esta razón, nosotros vamos a mostrar una advertencia acerca del uso de
navegadores no soportados cuando abra contenido en Internet Explorer. Solamente se lista en esta tabla
de compatibilidad para tener todo completo. Usted le debería advertirle a usuarios IE que se actualicen al
nuevo navegador de Microsoft Edge.
Construyendo y Corriendo un Proyecto
WebGL
Cuando usted construya un proyecto WebGL, Unity va a crear una carpeta con los siguientes archivos:

 un archivo [Link] para que los navegadores puedan navegar y cargar su contenido.
 una carpeta Development o Release que contiene los archivos output de su construcción generada (el
cual depende si usted hizo una development build o no).
 una carpeta TemplateData (al menos cuando construya con el default template (plantilla predeterminada),
conteniendo la barra de cargar y otros assets plantilla. Ver la página del manual acerca de WebGL
templates para más información.
El Development o Release contiene los siguientes archivos (remplace MyProject con el nombre de sus
proyectos). Si usted hace una construcción release, los archivos en esta carpeta serán comprimidos y tendrán
un sufijo gz. Ver los comentarios en el tamaño de Distribución abajo.

 un archivo JavaScript [Link] que contiene el código para su reproductor.

 un archivo [Link] que contiene una imagen binaria para inicializar la memoria heap par su
reproductor.
 un archivo [Link] que contiene los datos del asset y escenas.
 un archivo [Link] que contiene el código necesitado para cargar el contenido de Unity en la
página web.
Usted puede ver su reproductor WebGl directamente en la mayoría de exploradores al simplemente abrir el
archivo [Link]. Por razones de seguridad, Chrome coloca restricciones en scripts abiertos
desde file: URLs locales, por lo que esta técnica no va a funcionar. Si usted utiliza el comando Build &
Run de Unity (menú File > Build & Run) entonces el archivo será temporalmente alojado en el servidor local
web y abierto desde un URL localhost (esto evita las restricciones de seguridad). Usted también puede correr
Chrome con la opción de linea de comando --disable-web-securitypara habilitar que se cargue
contenido desde file: urls.

En algunos servidores usted necesitará hacer que los archivos “.mem” y “.data” sean accesibles. El servidor
va a necesitar proporcionar estos archivos a clientes.

Build Player Options (Opciones para Construir el

Reproductor)
WeGl le permite a usted seleccionar un nivel de optimización en la ventana de Build Player. Estos corresponden
a flags de optimización (–01 - –03) pasados a un compilador emscripten. En general, “Slow” produce
construcciones no optimizadas, pero tienen un mucho menor tiempo de construcción que las otras opciones,
por lo que puede ser utilizado para iterar en problemas de código. “Fast” produce construcciones optimizadas,
y “Faster” habilita algunas optimizaciones adicionales, pero hace que sus construcciones tomen un mayor
tiempo para completarse (por lo que usted podría querer utilizarlo para su lanzamiento final).

Cuando usted marca la casilla de verificación “Development Build”, Unity va a generar una construcción de
desarrollo (con soporte del perfilador y la consola de desarrollo para errores, como en cualquier otra
plataforma). Adicionalmente, los Development builds no son minimizados, por lo que el JavaScript generado
es leíble para humanos y preserva los nombres de las funciones (para que usted tenga una pila de seguimiento
para errores útil), pero muy grande para distribuir.
 La casilla de verificación “Autoconnect Profiler” debe ser utilizada cuando usted quiere perfilar su contenido
WebGL de Unity. No es posible conectar el Profiler a una construcción en ejecución como otras plataformas,
ya que la conexión del perfilador es manejado utilizando WebSockets en WebGL, pero el explorador solamente
va a permitir conexiones salientes del contenido, por lo que la única manera de utilizar el Profiler en WebGl es
marcar “Autoconnect Profiler” para tener el contenido conectado al Editor.

Ajustes del Reproductor (Player Settings)

WebGL tiene algunas opciones adicionales en los Player Settings (menú: Edit > Project Settings > Player).

La opción Strip Engine Code en Other Settings le permite a usted habilitar el stripping de código para WebGl.
Si usted habilita Stripping, Unity no va a incluir el código para cualquier clase que usted no utilice - por lo que
si usted no utiliza algún componente de física o métodos para instanciar, todo el motor de física será stripped
(extraído) de su construcción. Ver la sección de stripping abajo para más detalles.

El campo de WebGL memory size en Publishing Settings le permite a usted específica qué tanta memoria (en
MB) el contenido debería asignar para su heap. Si este valor es demasiado bajo, usted obtendrá errores ‘out
of memory’ cuando su contenido cargado y escenas no encajen en la memoria disponible. Sin embargo, si
usted configura este valor demasiado alto, su contenido podría fallar en cargar algunos exploradores o en
algunas maquinas, ya que su explorador podría no tener la suficiente memoria disponible para asignar el
tamaño heap solicitado. Este valor está escrito en una variable llamada “TOTAL_MEMORY” en el archivo html
generado, por lo que si usted quiere experimentar con este ajuste, usted puede editar el archivo html para
evitar la necesidad de re-construir su proyecto. Ver la página del manual acerca del uso de memoria de
WebGL para más detalles.

La ventana emergente Enable Exceptions en Publishing Settings le permite a usted habilitar el soporte de
excepciones en WebGL. Si usted no necesita un soporte de excepción, configure esto a “None”, que le dará a
usted el mejor rendimiento y las construcciones más chiquitas. Cualquier excepción lanzada va a causar que
su contenido pare con un error en ese ajuste. No obstante, si usted necesita utilizar excepciones, usted puede
configurarlo a:

 Explicitly Thrown Exceptions Only (por defecto), lo cual le va a permitir atrapar excepciones que son
explícitamente lanzadas con una declaración “trow”, y hará bloques “finally” en su código que funcionen. Esto
hará que el código JavaScript generado de los scripts del usuario más grandes y lentos, pero usualmente esto
no es mucho problema si los scripts no son el cuello de botella principal de su proyecto.

 Full, que, adicionalmente a lo anterior, también va a generar excepciones para referencias Null y para accesos
que estén fuera del limite de un arreglo. Estas son generada al incrustar revisiones a cualquier acceso a
referencias al código generado, por lo que va a causar un aumento en el tamaño del código adicional y
slowdowns (más lento). También, esto va a agregar managed stack traces a excepciones. Es recomendable
utilizar este modo solamente cuando usted necesite depurar problemas en su código, ya que genera
construcciones muy grandes y lentas.
La casilla de verificación Data caching en Publishing Settings le permite habilitar un almacenamiento en caché
local de los datos de su reproductor automáticamente. Si esto está activado, sus assets serán almacenados a
un almacenamiento en caché local en la base de datos IndexedDB en los explorados, para que no tengan que
ser re-descargados en posteriores ejecuciones de su contenido. Tenga en cuenta que diferentes explorados
tienen diferentes reglas acerca del almacenamiento en IndexedDB, y puede preguntarle al usuario por permiso
para almacenar los datos si esto es habilitado, y su construcción excede alguna limitación de tamaño definida
por el explorador.

Tamaño de Distribución
 Cuando publique para WebGl, es importante mantener el tamaño de su construcción baja para que las
personas obtengan un tiempo de descarga razonable antes de que el contenido inicio. Para recomendaciones
generales acerca de la reducción de tamaños de asset, ver Reduciendo el tamaño del archivo de la
construcción. Algunos comentarios adicionales específicos a WebGL:

 Especifique el formato de compresión de textura “Crunch” para todas sus texturas comprimidas en
el Texture Importer.
 No despliegue Development Builds (Construcciones de desarrollo), estas no son comprimidas ni Minified y
tienen tamaños de archivo mucho mayores.
 Configure el Optimization Level (nivel de optimización) a “Fastest”
 Configure “Enable Exceptions” en los Payer Settings a “None” si usted no necesita excepciones en su
construcción.
 Habilite “Strip Engine Code” en los Player Settings.
 Tenga cuidado cuando utilice dlls manejadas por terceros, ya que estos pueden traer muchas
dependencias y aumentar el tamaño del código emitido significativamente.
Si usted hace una construcción de lanzamiento, Unity va a comprimir los archivos de construcción de salida
utilizando la compresión gzip. Si su servidor web está configurado correctamente, estos archivos serán des-
comprimidos por el explorador durante la descarga en en nivel del protocol http. Sin embargo, esto significa
que usted necesita asegurarse de que su servidor http en realidad proporcione los datos comprimidos. Si usted
es anfitrión de sus archivos en un servidor web Apache, Unity va a escribir un archivo .htaccess invisible en la
carpeta de resultados de la construcción, que le dice a Apache en comprimir las transferencias, por lo que esto
debería funcionar. Si usted está utilizando otros servidores web, revise el manual de su servidor.

Si su servidor web no está configurado para servir archivos gzip comprimidos en el nivel del protocol http,
desde Unity 5.3, Unity va a descomprimir los datos para usted en el tiempo de carga en JavaScript. Por lo que
usted todavía estaría utilizando archivos comprimidos, pero habría una demora extra al comienza para
descomprimir los datos. Usted podría darse cuenta que esto sucede cuando usted ve un mensaje así en la
consola JavaScript del explorador:

Decompressed Release/[Link] in 82ms. You can remove this delay if

you configure your web server to host files using gzip compression.

AssetBundles
Debido a que todos los datos de sus assets necesitan ser pre-descargados antes de que su contenido inicio,
usted debería considerar mover los assets afuera de sus archivos de datos principales a AssetBundles. De
esta manera, usted puede crear una pequeña escena de cargar para su contenido el cual carga rápidamente,
y dinámicamente carga los assets en demanda a medida que el usuario procede a través de su contenido.
También, los AssetBundles lo ayudarán con asset data memory, ya que usted será capaz de descargar datos
de assets desde memoria para assets que usted no necesita más al llamar [Link]].

Algunas consideraciones aplican cuando utilice AssetBundles en la plataforma WebGL.

 Cuando usted esté utilizando tipos de clases en su AssetBundle que no están siendo utilizados en su
construcción principal, esto puede causar que Unity strip (excluya) el código para esas clases de la
construcción, lo que luego causa que falle cuando intente cargar los assets del AssetBundle. Ver la sección
acerca de Stripping abajo para aprender a cómo solucionar esto.
 Ya que WebGL no soporta threading (hilos), y ya que las descargas http serán solamente disponibles cuando
terminen, las construcciones WebGL de Unity necesitan descomprimir los datos de AssetBundle en el thread
 (hilo) principal cuando la descarga haya finalizado, por lo tanto bloquea el thread principal. Para evitar esta
interrumpción, usted podría de dejar de utilizar el formato por defecto LZMA para sus AssetBundles, y
comprimirlos utilizando LZ4 más bien, el cual tiene una descompresión muy eficiente en demanda. Si usted
necesita tamaños de compresión más pequeños entonces LZ4 cumple, usted puede configurar su servidor
web para comprimir gzip los archivos en el nivel del protocol http (encima de la compresión LZ4).
 El almacenamiento en caché de AssetBundle utilizando [Link] es soportado en
WebGL utilizando el API INdexedDB del explorador para implementar el almacenamiento en caché en el
computador del usuario. Tenga en cuenta que IndexedDB podría tener un soporte limitado en algunos
exploradores, y que los navegadores podrían pedirle autorización al usuario para almacenar los datos en disco.
Stripping
Por defecto, Unity va a realizar code stripping en su construcción - esto puede ser controlado utilizando la
opción Strip Engine Code en other Settings. Code Stripping va a escanear su proyecto para cualquier clase
utilizada derivada de UnityObject (ya sea siendo referenciada en su código script, o en los datos serializados
de sus escenas), y va a strip el código de cualquier de los Unity subsystems que no tienen ninguna de sus
clases utilizadas de la construcción. Esto hará que su construcción emita menos código, resultando en
descargas más pequeñas y menos código para parse (significando que el código será parsed más rápido
utilizando menos memoria). Por lo que por lo general es recomendable siempre construir con stripping
habilitado.

Es posible, sin embargo, que el code stripping pueda causar problemas con su proyecto y excluya código que
sea necesario. Esto puede ser en el caso cuando usted cargue AssetBundles en tiempo de ejecución que
contienen clases que no están incluidas en la construcción principal, y por lo tanto han sido stripped del
proyecto. Usted verá mensajes de error como este en la consola JavaScript del explorador cuando esto suceda
(potencialmente seguido por más errores):

Could not produce class with ID XXX

 dónde XXX puede ser consultado en la Class ID Reference para ver qué cual a cuál clase pertenece la
instancia que está creando. En tales casos usted puede obligar a Unity en que incluya el código para esa clase
en la construcción, ya sea al agregar una referencia a la clase a sus scripts o a sus escenas, p al agregar un
archivo [Link] a su proyecto. Aquí hay un ejemplo que se asegura que la clase Collider (y por lo tanto el
modulo de Físicas) sea conservada en el proyecto - agregue este código xml a un archivo [Link],
y coloque ese archivo a la carpeta suya de Assets:

<linker>
<assembly fullname="UnityEngine">
<type fullname="[Link]" preserve="all"/>
</assembly>
</linker>

Usted siempre puede intentar desactivar la opción Strip Engine Code para pruebas, si usted sospecha que el
stripping está causando problemas con su construcción.

Unity todavía no proporciona una manera conveniente de ver qué módulos y clases son incluidas en la
construcción, lo cual le permitiría a usted optimizar su proyecto para que haga el stripping bine. Estamos
trabajando para proporcionar esa información - mientras tanto, usted podría querer mirar al archivo
 generado Temp/StagingArea/Data/il2cppOutput/[Link] después de hacer una
construcción, para obtener una visión general de las clases y módulos.

Tenga en cuenta que la opción Strip Engine Code solamente afecta el código del motor de Unity. IL2CPP
siempre siempre va a strip código byte de sus managed dlls y scripts. Esto puede causar problemas cuando
usted necesite referenciar managed types dinámicamente a través de reflection en vez de a través de
referencias estáticas en su código. Si usted necesita acceder tipos a través de reflection, usted podrían también
necesitar configurar un archivo [Link] para preservar estos tipos. Ver la página de documentación acerca
de optimización del tamaño de la construcción iOS par más información acerca de archivos [Link].

Moviendo archivos de salida (output) de la construcción

Si usted quiere cambiar la ubicación de los archivos de salida relativo al archivo [Link], usted lo puede
hacer al editar los campos dataUrl, codeUrl, y memUrl y la etiqueta script [Link] en el
archivo [Link]. Usted puede especificar URLs en servidores externos para estos si usted quiere ser un
anfitrión de sus archivos en un CDN, pero usted tiene que asegurarse que el servidor que es anfitrión tiene
habilitado CORS para este trabajo. Ver la página del manual WebGL networking para más información acerca
de CORS.

Depuración y la resolución de problemas de

construcciones WebGL
El contenido de Unity WebGL no puede estar actualmente depurado con MonoDevelop o Visual Studio, lo cual
puede hacer difícil de encontrar lo que está pasando mal con su contenido. Aquí hay algunas recomendaciones
de cómo obtener información de su construcción.

La consola Javascript del navegador

Unity WebGL no tiene acceso a su sistema de archivos, por lo que no va a construir un archivo log (registro)
como otras plataformas. Sin embargo, va a escribir toda la información de registro la cual normalmente iría al
archivo log (como [Link], [Link] o el logging interno de Unity) a la consola JavaScript
del navegador.

 En Firefox, usted puede abrir la consola JavaScript al oprimir Ctrl-Shift-K en Windows o Command-Option-K
en un Mac
 En Chrome, usted puede abrir la consola JavaScript al oprimir Ctrl-Shift-J en Windows o Command-Option-J
en Mac.
 En Safari, usted puede abrir la consola de JavaScript al habilitar el menú de Desarrollo en las pestañas
Advanced (avanzadas) en Preferences (Preferencias), y luego oprimir Command-Option-C.
 En Microsoft Edge o Internet Explore, usted puede abrir la consola de JavaScript al presionar F12.
Development builds (Construcciones de desarrollo)
Por razones de depuración, usted podría típicamente querer hacer una construcción en desarrollo en Unity (la
casilla de verificación Development Build en la ventana de Build Settings window). Las construcciones de
desarrollo le permite a usted conectar el profiler (perfilador), y estos no estarán minified, por lo que el código
JavaScript emitido todavía mantendrá nombres de funciones todavía leíbles por humanos (aunque C++-
mangled). Estas pueden ser utilizadas por el navegador para mostrar rastros de stack cuando usted corra en
un error en el navegador, o cuando usted lance una excepción y el soporte de excepciones esté des-habilitado,
o cuando utilice [Link]. A diferencia de los managed stack traces los cuales usted puede obtener
cuando habilite el soporte entero de excepciones (ver abajo), estos stack traces tendrán nombres mangled, y
tendrá no solo código managed, pero también código interno de UnityEngine.

Soporte de excepciones
WebGL tiene diferentes niveles de soporte de excepciones (Ver la página acerca de Construyendo para
WebGL). Por defecto, Unity WebGL solamente va a soportar excepciones explícitamente lanzadas. Usted
puede habilitar el soporte de excepciones Completo el cual emitirá revisiones adicionales en el código IL2CPP
generado para atrapar accesos a referencias nulas y elementos afuera de los limites de un arreglo en su código
managed. Estas revisiones adicionales van a impactar significativamente el rendimiento y aumentará el tamaño
del código y tiempos de carga, por lo que este modo es solamente recomendado para depuración.

El soporte de excepción Completo va a también emitir nombres de funciones a stack traces generados para
su código managed. Por lo que usted vera stack traces en la consola para excepciones sin atrapar y para
declaraciones [Link], y usted puede obtener una stack traces string
utilizando [Link].

Gráficas WebGL
WebGL es una API para renderizar gráficas en los navegadores web el cual es basado en la funcionalidad de
la libraría gráfica OpenGL ES 2.0.

Global Illumination
Unity WebGL solamente soporta baked GI. El GI en tiempo real actualmente no es soportado en WebGL.
Adicionalmente solamente los lightmaps No-direccionales son soportados.

Procedural Materials
Unity WebGL no soporta Procedural Materials en tiempo de ejecución. Como en cualquier otra plataforma no
soportada, los Procedural Materials serán baked a Materiales común y corrientes durante la construcción.

Linear Rendering
WebGL no soporta linear color space rendering.

MovieTextures (Texturas de película)

WebGL no soporta actualmente la reproducción de video utilizando la clase MovieTexture. Sin embargo, usted
puede eficientemente reproducir video de vuelta en su contenido WebGL utilizando el elemento video de
HTML5. Descargue este Asset Store package para un ejemplo de cómo hacerlo.

Restricciones del código Shader de WebGL

La especificación WebGL 1.0 impone algunos limites en el código shader GLSLS, el cual está más restringido
que lo que la mayoría de las implementaciones OpenGL ES 2.0 permite. Esto es más relevante cuando usted
escribe sus propios shaders.
Específicamente, WebGL tiene restricciones en aquellos valores que serán utilizados como indices de arreglos
o matrices: WebGL solamente permite un indexado dinámico con expresiones constantes, indices de bucles o
una combinación. La única excepción es para un acceso uniforme en vertex shaders, el cual puede ser
indexado utilizando cualquier expresión.

También, las restricciones aplican en el control de estructuras. El único tipo de bucles los cuales son permitidos
son los bucles for, dónde el inicializador inicializa una variable a una constante, la actualización agrega una
constante o resta una constante de la variable, y la prueba continua compara la variable a la constante. Los
bucles for que no coincidan con estos criterios y los bucles while no están permitidos.

Renderización de fuentes
Unity WebGL soporta la renderización dinámica de fuentes como cualquier otra plataforma de Unity. No
obstante, no tiene acceso a las fuentes instaladas en la maquina del usuario, por lo que cualquier fuente
utilizada debe estar incluida en la carpeta del proyecto (incluyendo cualquier fuente fallback para caracteres
internacionales, o versiones itálica/negrilla de las fuentes), y configuradas con nombres de fuentes fallback.

Anti-Aliasing
WebGL soporta el anti-aliasing en la mayoría (pero no todos) de combinaciones de navegadores de internet y
GPUs. Para utilizarlo, el anti-aliasing debe estar activado en el default Quality Setting para la plataforma
WebGL. Cambiar los quality settings (ajustes de calidad) en tiempo de ejecución no va a activar o des-activar
anti-aliasing - este tiene que ser configurado en el Quality Setting por defecto cargada cuando inicie el
reproductor. Tenga en cuenta que diferentes niveles de multi sampling no tienen efecto en WebGL.

Soporte a WebGL 2.0 (Experimental)

Unity incluye soporte para la WebGL 2.0 API, la cual trae las capacidades de renderizado de OpenGL ES 3.0
a la web. Esto actualmente es experimental y desactivado por defecto, ya que ningún navegador actual soporta
WebGL 2.0. No obstante, las construcciones actuales en Firefox le permiten a usted probar la característica,
si usted activa [Link]-prototype-webgl2 en about:config.

Para activar WebGL 2.0, des-marque Automatic Graphics API en la sección de Other Settings en los ajustes
del reproductor de WebGL. Luego usted puede agregar WebGL 2.0 a las APIs gráficas activadas para su
construcción.

Cuando WebGL 2.0 es soportado en los navegadores, el contenido se puede beneficiar de una mejor calidad
en el Standard Shader, soporte de lightmap direccional, ningunas restricciones en indices y bucles en código
shader, y un mejor rendimiento.

WebGL Networking (redes)

No hay acceso directo al socket
Debido a implicaciones de seguridad, el código JavaScript no tiene un acceso directo a IP Sockets para
implementar una conectividad en red. Como resultado, las clases de networking .NET (ie, todo en el
namespace [Link], particularmente [Link]) son no funcionales en WebGL. Lo mismo
aplica a las clases viejas [Link]* de Unity, las cuales no están disponibles cuando
construya para WebGL.

Si usted necesita utilizar Networking (redes) en WebGL, usted actualmente tiene las opciones para utilizar las
clases WWW o UnityWebRequesten Unity o las nuevas características del Unity Networking que soportan
WebGL, o implementar su propio networking (redes) utilizando WebSockets o WebRTC en JavaScript.

Utilizando las clases WWW o WebRequest en WebGL

Las clases WWW y UnityWebRequest son soportadas en WebGL. Estas son implementadas utilizando la
clase XMLHttpRequest en JavaScript, utilizando el navegador para manejar solicitudes WWW. Esto impone
algunas restricciones de seguridad acerca de acceder a recursos a través de dominios. Básicamente cualquier
solicitud WWW a un servidor que es diferente del servidor que aloja el contenido de WebGL necesita estar
autorizado por el servidor que usted está intentado acceder. Para acceder a recursos WWW a través de
dominios en WebGL, el servidor que usted está intentando acceder necesita autorizar el uso de CORS.

Si usted intenta acceder contenido utilizando WWW o UnityWebReqest, y el servidor remoto no tiene CORS
configurado o configurado correctamente, usted verá un error como este en la consola del navegador:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the
remote resource at [Link] This can be fixed by moving the
resource to the same domain or enabling CORS.

CORS significa Cross-Origin Resource Sharing, y está documentado aquí. Básicamente, el servidor necesita
agregar algunos encabezados de Access-Control a las respuestas http que envíe, lo cual le dice a los
navegadores que se permite que páginas web accedan el contenido en el servidor. Aquí hay un ejemplo de
una configuración del encabezado, lo cual le permitiría a Unity WebGL en acceder recursos en un servidor web
desde un origen, con encabezados de solicitudes comunes y utilizando los métodos
http GET, POST o OPTIONS:

"Access-Control-Allow-Credentials": "true",

"Access-Control-Allow-Headers": "Accept, X-Access-Token, X-Application-

Name, X-Request-Sent-Time",

"Access-Control-Allow-Methods": "GET, POST, OPTIONS",

"Access-Control-Allow-Origin": "*",

Tenga en cuenta que [Link] está limitado a un sub-conjunto de los encabezados de

respuesta actuales, de acuerdo a 7.1.1 de la especificación CORS.
También tenga en cuenta que XMLHttpRequest no permite el streaming de datos, por lo tanto la clase WWW
en WebGL solamente va a procesar cualquier dato una vez la descarga haya finalizado (por lo que
AssetBundles no pueden ser descomprimidos y cargados mientras se descarguen como en otras plataformas).

Utilizando Unity Networking

Unity Networking soporta WebGL al habilitar comunicación via el protocol WebSockets.
Ver [Link].

Utilizando Web Sockets o WebRTC desde JavaScript

Como está escrito arriba, el acceso directo a IP Sockets no es posible en WebGL. Sin embargo, si usted
necesita capacidades de networking más allá de la clase WWW, es posible utilizar Web Sockets o WebRTC,
ambos protocols de networking soportados por navegadores. Los Web Sockets tiene un soporte más amplio,
pero WebRTC permite conexiones p2p entre navegadores y conexiones poco fiables. Ninguno de estos
protocolos son expuestos a través de APIs construidas en Unity todavía, pero es posible utilizar un JavaScript
plugin para implementar esto. Un ejemplo de un plugin que implementa el WebSocket networking (redes) en
Unity WebGL se puede encontrar en la AssetStore.

Utilizando Audio en WebGL

El Audio en WebGL es hecho de una manera que en otras plataformas. En otras plataformas nosotros
utilizamos FMOD internamente para proporcionar la mezcla y reproducción de audio. Debido a que la
plataforma WebGL no soporta hilos, nosotros necesitamos utilizar una implementación diferente, este es
basado internamente en el Web Audio API, el cual le permite al navegador manejar la reproducción de audio
y la mezcla.

Desafortunadamente, este limita la funcionalidad de audio en Unity WebGL para soportar solamente las
características más básicas. Esta página va a documentar lo que espera que funciona. Cualquier cosa que no
este aquí, actualmente no es soportado en WebGL.

AudioSource (Fuente de audio)

Los Audio Sources (Fuentes de audio) soportan la reproducción de audio básica de posicionamiento con con
pausa y reanudación, paneo, roll off, ajuste del tono, y soporte para el efecto doppler.

Las siguientes APIs de AudioSource son soportadas:

Propiedades:

 clip
 dopplerLevel
 ignoreListenerPause
 ignoreListenerVolume
 isPlaying
 loop
 maxDistance
 minDistance
 mute
 pitch
 playOnAwake
 rolloffMode
 time
 timeSamples
 velocityUpdateMode
 volume
Métodos:

 Pause
 Play
 PlayDelayed
 PlayOneShot
 PlayScheduled
 SetScheduledEndTime
 SetScheduledStartTime
 Stop
 UnPause
 PlayClipAtPoint
AudioListener
Todas las APIs del AudioListener son soportadas.

AudioClip
Los Audio Clips en WebGL siempre serán importados en formato AAC, ya que es soportado ampliamente por
diferentes navegadores.

Todas las siguientes APIs del AudioClip son soportadas. APIs son soportadas:

Propiedades:

 length
 loadState
 samples
Métodos:

 Create. [Link] solamente es soportado parcialmente: este va a funcionar si el parámetro

de streaming es configurado a false y las muestras de audio completas pueden ser cargadas cuando
[Link] sea llamado. Luego este creará el clip y cargará todas las muestras antes de devolver el
control.
 SetData. [Link] es solamente soportado parcialmente: este va a funcionar para
remplazar el contenido completo del AudioClip. El parámetro offsetSamples es ignorado.
[Link]
[Link] debería funcionar en WebGL, si el audio clip está en un formato el cual es nativamente
soportado por el navegador. Ver aquí para una lista de los formatos soportados en diferentes navegadores.
Microphone (Microfono)
La clase Microphone no es soportada en WebGL.

Consideraciones de rendimiento WebGL

Qué tipo de rendimiento usted espera en WebGL?
Esto es un poco complicado de responder ya que depende de muchos factores.

En general, usted puede asumir que usted obtendrá un rendimiento cerca a apps nativas en el lado del GPU,
ya que el API de gráficos de WebGL utiliza su GPU para un renderizado acelerado de hardware - simplemente
hay una sobre-carga para traducir los llamados de la API de WebGL y shaders al API gráfica de su OS
(típicamente DirectX en Windows o OpenGL en Mac o Linux).

Para el lado del CPU, todo su código es traducido a [Link] JavaScript. Entonces el tipo de rendimiento que
usted espera depende de mucho en el motor JavaScript del navegador utilizado, y hay muchas diferencia
significativas ahí actualmente. En el punto de esta escritura (Noviembre de 2015), Microsoft Edge y Mozilla
Firefox entregan el mejor rendimiento en código de Unity, ya que son los únicos navegadores que hacen uso
del spec [Link] para utilizar una ruta de compilación AOT optimizada de código JavaScript para este caso,
que entrega rendimiento dentro de un factor de menos de una disminución 2x comparada al código nativo para
muchos benchmarks de programación - y ese factor también coincide con los resultados que hemos visto en
diferentes contenidos de Unity desplegado a WebGL y corridos en Firefox y Edge.

Hay otras consideraciones sin embargo. Actualmente el lenguaje JavaScript no soporta multi-hilos, ni SIMBD.
Entonces, cualquier código que se beneficie de estas características verá mayores retrasos que en otro código.
Usted no puede escribir hilos o código SIMBD en WebGL en sus scripts, pero algunas partes del motor son
normalmente ejecutadas en multi-hilos y optimizado-SIMBD. Usted puede utilizar la nueva linea de tiempo del
profile en Unity y ver cómo Unity distribuye trabajo a diferentes hilos en plataformas no-WebGL. En un futuro
no muy lejano, esperamos que estas características se vuelvan disponibles en WebGL también.

Ajustes WebGL-específicos que afectan rendimiento

Para un mejor rendimiento, configure el nivel de optimización a “Fastest” en el dialogo de Build Player, y
configure “Exception Support” a “None” en los player settings para WebGL.

Profiling (perfilando) WebGL

Usted puede utilizar el Unity Profiler en WebGL, como cualquier otra plataforma. Una importante distinción es
que usted no puede adjuntar a los reproductores corriendo en WebGL, aunque, Web GL utilice WebSockets
para comunicación, lo cual no va a permitir conexiones entrantes por el lado del navegador. Más bien, usted
necesita utilizar la casilla de verificación del “Autoconnect profiler” en los build settings. Tenga en cuenta que
las draw calls no pueden ser profiled (perfiladas) actualmente para WebGL.

Contenido WebGL en pestañas del fondo

Si el Run in background está habilitada en los WebGL Player Settings, o si usted
habilita [Link], entonces su contenido va a continuar ejecutándose cuando el
canvas o la ventana del navegador pierdan foco.

Sin embargo hay que señalar que los navegadores pueden estrangular contenido ejecutado en pestañas de
fondo. Si la pestaña con su contenido no es visible, su contenido será actualizado una vez por segundo en la
mayoría de los navegadores. Tenga en cuenta que esto va a causar [Link] que progrese más lento que
lo usual con los ajustes predeterminados, ya que el valor predeterminado de [Link] es
menor que un segundo.

Consideraciones de Memoria cuando tenga

como objetivo WebGL
La memoria en Unity WebGL puede ser un factor limitante restringiendo la complejidad del contenido que usted
puede ejecutar, por lo que queremos proporcionarle una explicación acerca de cómo la memoria es utilizada
en WebGL.

Su contenido WebGL va a ejecutarse dentro de un navegador, por lo que cualquier memoria tiene que ser
asignada por el navegador dentro del espacio de memoria del navegador. La cantidad de memoria disponible
puede variar mucho dependiendo en el navegador, OS y dispositivo utilizado. Los factores determinantes
incluyen si el navegador es un proceso de 32 o 64 bit, si el navegador utiliza procesos separados para cada
pestaña o si su contenido comparte un espacio de memoria con todas las otras pestañas abiertas, y qué tanta
memoria el motor JavaScript del navegador requiere para parse su código.

Hay múltiples áreas dónde el contenido de Unity WebGL va a requerir que el navegador asigne cantidades
significantes de memoria:

Unity Heap
Esta es la memoria que Unity utiliza para almacenar su estado, objetos managed y nativos y assets
actualmente cargadas y escenas. Esta es similar a la memoria utilizada por los reproductores de Unity en
cualquier otra plataforma. Usted puede configurar el tamaño de esto en los ajustes del Unity WebGL player
(pero para una iteración más rápida, usted puede editar el valor TOTAL_MEMORY escrito al archivo html
generado). Usted puede utilizar el Unity Profiler para perfilar y muestrar los contenidos de esta memoria. Esta
memoria será creada como un TypedArray de bytes en código JavaScript, y requiere que el navegador sea
capaz de asignar un bloque de memoria consecutivo de este tamaño. Usted querrá que este espacio sea tan
pequeño como posible (para que el navegador sea capaz de asignarla equitativamente si la memoria es
fragmentad), pero lo suficientemente grande para que encaje todos los datos requeridos para reproducir
cualquier escena de su contenido.

Datos de Asset
Cuando usted cree una construcción de Unity WebGL, Unity va a escribir un archivo .data conteniendo todas
las escenas y assets necesitados para su contenido. Debido a que WebGL no tiene un sistema de archivos
verdaderos, este archivo será descargado antes de que su contenido inicie, y los datos sin comprimir serán
mantenidos en un bloque consecutivo de memoria del navegador para todo el tiempo que su contenido se
ejecute. Entonces, para mantener ambos tiempos de descargar y el uso de memoria bajo, usted debería
intentar mantener estos datos tan pequeños como sean posibles. Ver la página de documentación acerca
de reducir el tamaño de archivospara información acerca de cómo optimizar el tamaño de la construcción para
sus assets.

Otra cosa que usted puede hacer para reducir el tiempo de carga y la cantidad de memoria utilizada para los
assets es empaquetar sus datos de asset en AssetBundles. Al hacer esto, usted obtiene un control completo
de cuando sus assets necesitan ser descargados, y usted puede descargarlos nuevamente cuando usted no
los necesite, lo cual liberará cualquier memoria utilizada por estos. Tenga en cuenta que los AssetBundles
serán cargados directamente a su Unity heap y no va a resultar en asignaciones adicionales por el navegador
(al menos de que usted utilice Asset Bundle Caching utilizando [Link], el cual utiliza
un sistema de archivo virtualmente mapeado de memoria, respaldado por el navegador IndexedDB (BD
indexada)).

Memoria necesita para parse el código

Otro problema relacionada a memoria es la memoria requerida por el motor JavaScript del navegador. Unity
va a emitir una gran cantidad de archivo de millones de lineas de código JavaScript generado, el cual es un
orden de magnitud más grande que los usos comunes de código JavaScript en los navegadores. Algunos
motores de JavaScript puede asignar algunas estructuras grandes de datos para parse y optimizar ese código,
el cual resulta en picos de memoria de hasta varios Gigabytes de memoria cuando carguen contenido en
algunos casos. Nosotros esperamos que haya tecnologías en el futuro como WebAssembly que eventualmente
eliminen este problema, pero hasta ese entonces, el mejor consejo que podemos dar es que mantenga el
tamaño del código emitido bajo. Ver los comentarios del tamaño de distribución aquí para más información
acerca de cómo hacer esto.

Trabajando con problemas de memoria

Cuando usted vea un error relacionado a memoria en la construcción de WebGL, es importante entender si es
el navegador que está fallando asignando memoria o si es el tiempo de ejecución de Unity WebGL el que falla
cuando asigna un bloque libre de memoria dentro del bloque pre-asignado del Unity heap. Si el navegador falla
asignando memoria, entonces puede ayudar intentar reducir el tamaño utilizado por uno más áreas de memoria
de arriba (por ejemplo al reducir el tamaño del Unity heap). Por otro lado, si es el tiempo de ejecución de Unity
el que falla en asignar un bloque dentro del Unity heap, usted puede intentar aumentar el tamaño de este más
bien.

Unity va a intentar de interpretar los mensajes de error para decir cuál de los dos es (y proporcionar sugerencias
acerca de qué hacer). Debido a que diferentes navegadores pueden reportar diferentes mensajes, esto no es
siempre fácil, y puede que no se interprete todos estos. Cuando usted ve un error genérico “Out of memory”
del navegador, es probable que sea un problema del navegador que se quede sin memoria (dónde usted
podría querer usar un Unity heap más pequeño). También, usted a veces ver navegadores que simplemente
fallan cuando carguen contenido de Unity sin mostrar mensajes de error parseables a humano. Esto puede
tener muchas razones, pero es frecuentemente causado por motores de JavaScript requiriendo mucha
memoria para parse y optimizar el código generado.

Consideraciones del Garbage Collection (Recogedor de

basura)
Cuando usted asigne objetos managed a Unity, estos necesitan ser recolectados por la basura cuando no
estén en uso. Ver nuestra documentación acerca del manejo de memoria automático para más información.
En WebGL, esto es lo mismo. Memoria Managed, recolectada por basura es asignada dentro del Unity heap.
Una distinción en WebGL, sin embargo, concierne a los puntos en el tiempo dónde el recolector de basura
(garbage collection -GC-) toma lugar. Para realizar la recolección de basura, el GC normalmente necesitaría
pausar todos los hilos ejecutándose e inspeccionaría sus stacks y registros por referencias de objetos
cargados. Esto no es actualmente posible en JavaScript. Por esta razón, el GC va a solamente ejecutarse en
WebGL en situaciones dónde el stack es conocido por estar vacío (el cual es una vez después de cada frame).
Este no es un problema para la mayoría de contenido que trata con memoria managed de manera conservativa
y tiene pocas asignaciones GC dentro de cada frame (usted puede depurar esto utilizando el profiler de Unity).

Sin embargo, si usted tiene código como el siguiente:

string hugeString = "";

for (int i = 0; i < 100000; i++)

{
hugeString += "foo";
}
, luego este código fallaría corriendo en WebGL, ya que no tendría chance de ejecutar las GC entre iteraciones
del bucle, para librar memoria utilizada por todos los objetos string intermediarios - lo cual eventualmente
causaría que se quedará sin memoria en el Unity heap.

WebGL: Interactuando con scripting del

navegador
Cuando construya contenidos para la web, usted podría necesitar comunicarse con otros elementos en su
página web. O usted podría querer implementar funcionalidad utilizando Web APIs las cuales Unity
actualmente no expone por defecto. En ambos casos, usted necesita directamente interactuar con el motor
JavaScript del navegador. Unity WebGL proporciona diferentes métodos para hacer esto.

Llamando código JavaScript desde Unity

El primero es lo mismo que para el Web Player. Usted puede utilizar las
funciones [Link]() y [Link]() para invocar el código
JavaScript en la página web embebida. Para llamar métodos en GameObjects en su contenido desde el
JavaScript de su navegador, usted puede utilizar el siguiente código:

SendMessage ('MyGameObject', 'MyFunction', 'foobar');

Llamando funciones JavaScript desde un plugin

La otra manera para utilizar JavaScript del navegador en su proyecto es agregar sus fuentes de JavaScript a
su proyecto, y luego llamar esas funciones directamente desde su código script. Para hacer esto, coloque los
archivos con código Javascript utilizando la extensión .jslib (ya que la .js normal sería cogida por el compilador
de UnityScript) a una carpeta “Plugins/WebGL” en su carpeta Assets. El archivo necesita tener una sintaxis
como esta:
Assets/Plugins/WebGL/[Link]

var MyPlugin = {
Hello: function()
{
[Link]("Hello, world!");
},
HelloString: function(str)
{
[Link](Pointer_stringify(str));
},
PrintFloatArray: function(array, size)
{
for(var i=0;i<size;i++)
[Link](HEAPF32[(array>>2)+size]);
},
AddNumbers: function(x,y)
{
return x + y;
},
StringReturnValueFunction: function()
{
var returnStr = "bla";
var buffer = _malloc(lengthBytesUTF8(returnStr) + 1);
writeStringToMemory(returnStr, buffer);
return buffer;
},
BindWebGLTexture: function(texture)
{
[Link](GLctx.TEXTURE_2D, [Link][texture]);
}
};

mergeInto([Link], MyPlugin);

Luego usted llama estas funciones desde sus scripts C# así:

using UnityEngine;
using [Link];

public class NewBehaviourScript : MonoBehaviour {

[DllImport("__Internal")]
private static extern void Hello();

[DllImport("__Internal")]
private static extern void HelloString(string str);

[DllImport("__Internal")]
 private static extern void PrintFloatArray(float[] array, int size);

[DllImport("__Internal")]
private static extern int AddNumbers(int x, int y);

[DllImport("__Internal")]
private static extern string StringReturnValueFunction();

[DllImport("__Internal")]
private static extern void BindWebGLTexture(int texture);

void Start() {
Hello();

HelloString("This is a string.");

float[] myArray = new float[10];

PrintFloatArray(myArray, [Link]);

int result = AddNumbers(5, 7);

[Link](result);

[Link](StringReturnValueFunction());

var texture = new Texture2D(0, 0, TextureFormat.ARGB32, false);

BindWebGLTexture([Link]());
}
}

Tipos numéricos simples se pueden pasar a JavaScript en parámetros de funciones sin requerir conversión.
Otros tipos de datos serán pasados como apuntadores en el heap emscripten (el cual es simplemente un gran
arreglo en JavaScript). Para Strings, usted puede utilizar la función de ayuda Pointer_stringify para
convertirle en un string JavaScript. Para devolver un valor string usted necesita llamar _malloc para asignar
algo de memoria y luego la función de ayuda writeStringToMemory para escribir un string de JavaScript a
esta. Si el string es un valor de retorno, entonces el tiempo de ejecución il2cpp se encargará de liberar la
memoria para usted. Para arreglos que tengan tipos primitivos, emscripten proporciona diferentes
ArrayBufferViews a su heap para diferentes tamaños de enteres, enteros unsigned o representaciones punto
flotantes de memoria: HEAP8, HEAPU8, HEAP16, HEAPU16, HEAP32, HEAPU32, HEAPF32, HEAPF64. Para
acceder a una textura en WebGL, emscripten proporciona el arreglo [Link] que mapea IDs de textura
nativo desde Unity a objetos texture de WebGL. Las funciones WebGL serán llamadas en el contexto de
WebGL de emscripten, GLctx.

Llamando funciones C++ desde un plugin

Debido a que Unity compila sus fuentes a JavaScript desde código C++ utilizando emscripten, usted también
puede escribir plugins en código C o C++, y llamar estas funciones desde C#. Entonces, en vez del archivo
jslib en el ejemplo de arriba, usted puede tener un archivo c como el de abajo en su proyecto - este será
automáticamente compilado con sus scripts, y usted podrá llamar funciones de este, como cualquier otro
ejemplo de JavaScript de arriba.
Si usted está utilizando C++ (.cpp) para implementar el plugin entonces usted debe asegurarse que las
funciones están declaradas con un c linkage para evitar problemas de manejo de nombres.

Assets/Plugins/WebGL/MyPlugin.c

#include <stdio.h>

void Hello ()
{
printf("Hello, world!\n");
}

int AddNumbers (int x, int y)

{
return x + y;
}

Personalizando Revisiones de Compatibilidad o

Manejadores de Errores
Unity va a escribir algo de código JavaScipt a las construcciones por defecto, el cual va a revisar por
compatibilidad de plataforma y errores de manejo. Este código va a mostrar errores de advertencia cuando
corra en plataformas sin soportar, como cuando se intente correr contenido de Unity WebGL en dispositivos
móviles. También va a parse strings de error y excepción del navegador, para revisar por errores conocidos y
mostrar diálogos de error con mensajes de error más compresivos.

Usted puede personalizar este manejo, por ejemplo, si usted quiere suprimir los mensajes de error cuando
corra en dispositivos móviles. Para hacer esto, abra el [Link] generado, y remplace este código con las
implementaciones de funciones JavaScript actuales para el manejo de errores y/o revisiones de compatibilidad:

var Module = {
TOTAL_MEMORY: 268435456,
errorhandler: null,
compatibilitycheck: null,
};

La función compatibilitycheck será llamada al inicio, y usted puede colocar cualquier código aquí para mostrar
mensajes cuando usted detecte que el contenido no es soportado.

La función errorhandler será llamada cuando la página invoque su manejador de eventos [Link], y
utiliza los mismos parámetros. Devuelva “true” de esta función para resumir su ejecución, y “false” para pasar
el error al manejador por defecto de errores de Unity.

Example:

var Module = {
TOTAL_MEMORY: 268435456,
errorhandler: function(err, url, line) {
alert("error " + err + " occurred at line " + line);

// return true so Unity's error handler is not executed.

 return true;
},
compatibilitycheck: function() {
// check compatibility ...
}
};

Utilizando plantillas WebGL

Cuando usted construya un proyecto WebGL, Unity incrustar el player (reproductor) en una página HTML para
que pueda ser reproducido en el navegador. La página por defecto es una página blanca simple con una barra
de carga en un canvas gris. Alternativamente, usted puede seleccionar una plantilla minima (con solamente el
código repetitivo necesario para ejecutar el contenido WebGL) en el inspector de los Player Settings (menú:
Edit > Project Settings > Player).

Las páginas integradas de HTML están bien para pruebas y demostrar un reproductor mínimo pero para
propósitos de producción, a veces se desea ver el reproductor alojado en la página dónde eventualmente será
desplegada. Por ejemplo, si el contenido de Unity interactúa con otros elementos en la página vía la interfaz
de llamado externa entonces debe ser probada con una página que proporciones esos elementos de
interacción. Unity le permite a usted proporcionar sus propias páginas para alojar el reproductor
utilizando WebGL templates (muy similar a las Web Player Templates).

Estructura de una WebGL Template (Plantilla)

Las plantillas personalizadas son agregada a un proyecto al crear una carpeta llamada (WebGLTemplates" en
la carpeta Assets - las plantillas en sí son sub-carpetas dentro de esta carpeta. Cada carpeta de plantilla
contiene un archivo [Link] con otros recursos que la página necesite, como imágenes o stylesheets.
Una vez creado, la plantilla va a aparecer en las opciones del inspector de los Player Settings. (el nombre de
la plantilla será el mismo que su carpeta). Opcionalmente, la carpeta puede contener un archivo
llamado [Link], que debería tener las dimensiones de 128x128 pixeles. La imagen thumbnail será
mostrada en el inspector para insinuar cómo se vería la página terminada.

El archivo html necesita contener un elemento canvas con el id “canvas”. Luego usted debe insertar la
etiqueta UNITY_WEBGL_LOADER_GLUE, que generará las etiquetas de script requeridas para incrustar el
contenido de Unity, el cual luego va a renderizar a ese elemento canvas.

Etiquetas de la plantilla
Durante el proceso de construcción, Unity va a buscar por strings con etiquetas especiales en el texto de la
página y las va a remplazar con valores proporcionados por el editor. Estos incluyen el nombre, las
dimensiones de la pantalla y otra información útil acerca del reproductor.

Las etiquetas están delimitadas por signos de porcentaje (%) en la fuente de la página. Por ejemplo, si el
nombre del producto se define como “MyPlayer” en los Player Settings:-

<title>%UNITY_WEB_NAME%</title>

…en el archivo de plantilla index será remplazado con

<title>MyPlayer</title>

…en la página alojada generada de la construcción. El conjunto completo de etiquetas se da a continuación:-

 UNITY_WEB_NAME: Nombre del reproductor.

 UNITY_WEBGL_LOADER_GLUE: Esa va a inyectar las etiquetas de script necesarias para incrustar el
contenido WebGL. Este se requiere que este en el archivo [Link] de la plantilla.
 UNITY_WIDTH y UNITY_HEIGHT: Anchura de la pantalla y altura del reproductor en pixeles.
 UNITY_DEVELOPMENT_PLAYER: 1 cuando construya con un reproductor de desarrollo, 0 de lo
contrario.
 UNITY_CUSTOM_SOME_TAG: Si usted necesita agregar una etiqueta al archivo index con la forma
UNITY_CUSTOM_XXX, entonces esta etiqueta aparecerá en las Player Settings cuando su plantilla sea
seleccionada. Por ejemplo, si algo como

<title>Unity Web Player | %UNITY_CUSTOM_MYTAG%</title>

…es agregado a la fuente, las Player Settings se verían así:-

La caja de texto alado del nombre de la etiqueta contiene el texto de la etiqueta personalizada que será
remplazada durante la construcción.

Ejemplo
Para ilustrar el uso de la etiquetas de plantilla, aquí está la fuente HTML que Unity utiliza para su plantilla
minima de WebGL.

<!doctype html>
<html lang="en-us">
<head>
<meta charset="utf-8">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Unity WebGL Player | %UNITY_WEB_NAME%</title>
<link rel="stylesheet" href="TemplateData/[Link]">
<link rel="shortcut icon" href="TemplateData/[Link]" />
<script src="TemplateData/[Link]"></script>
</head>
<body class="template">
<p class="header"><span>Unity WebGL Player | </span>%UNITY_WEB_NAME%</p>
<div class="template-wrap clear">
<canvas class="emscripten" id="canvas" oncontextmenu="[Link]()"
height="%UNITY_HEIGHT%px" width="%UNITY_WIDTH%px"></canvas>
<div class="logo"></div>
<div class="fullscreen"><img src="TemplateData/[Link]" width="38" height="38" alt="Fullscreen"
title="Fullscreen" onclick="SetFullscreen(1);" /></div>
<div class="title">%UNITY_WEB_NAME%</div>
</div>
<p class="footer">&laquo; created with <a href="[Link] title="Go to [Link]">Unity</a>
&raquo;</p>
%UNITY_WEBGL_LOADER_GLUE%
</body>
</html>
Agregando una barra de progreso
El contenido de Unity WebGL no va a automáticamente renderizar una barra de progreso para usted cuando
cargue - la plantilla necesita manejar esto. La plantilla por defecto incluida en Unity contiene un
archivo [Link] que implementa una barra de progreso simple. usted puede re-utilizar esta para sus
propias plantillas, o utilizarla como una referencia para crear su propia. Debido a que la barra de progreso es
completamente implementada en JavaScript, usted puede personalizar completamente o remplazarla para
mostrar cualquier cosa que usted quiera como un indicio de progresión.

Input en WebGL

Bloqueo del cursor y modo de pantalla

completa en WebGL
El bloqueo del cursor (utilizando [Link]) y el modo de pantalla completa
(utilizando [Link]) ambos son soportados en Unity WebGL, implementados utilizando las APIs
de HTML5 respectivas ([Link] y [Link]). Estas son soportadas en
Firefox y Chrome, Safari actualmente no puede utilizar el modo de pantalla completa y el bloqueo del cursor.

Cómo habilitar el bloqueo del cursor y el modo de pantalla

completa en WebGL?
Por motivos de seguridad, los navegadores van a solamente permitir el bloqueo del cursor o ir a modo de
pantalla completa en respuesta directa a un evento iniciado por el usuario (como un mouse click o al presionar
una tecla). Des-afortunadamente debido a la manera de cómo Unity maneja eventos (no tiene unos bucles
separados de renderizado y eventos), Unity difiere el manejo de eventos a un punto dónde el navegador no
verá una solicitud de pantalla completa o un bloqueo de cursor emitido de Unity scripting a una respuesta
directa al evento el cual lo activo. Unity luego va a activar la solicitud en el siguiente evento iniciado por el
usuario.

Con el fin de hacer que esto funcione con resultados aceptables, nosotros recomendados que usted active la
solicitud del modo de pantalla completa o el bloqueo del cursor en eventos down (presionado para abajo) de
mouse/tecla (como se opone a eventos up mouse/tecla como usted usualmente haría). De esta manera cuando
la solicitud sea diferida al siguiente evento del usuario, este será activado cuando el usuario suelte el mouse o
tecla.

Si usted está utilizando el componente [Link] de Unity, usted puede lograr el comportamiento deseado al
crear una sub-clase del Botón, el cual anula el OnPointerDown método.

Tenga en cuenta que los navegadores pueden mostrar un mensaje de notificación y/o preguntarle al usuario
por permiso antes de ingresar al modo de pantalla completa o bloquear el cursor.

Input en WebGL
Soporte de Gamepad y Joystick
Gamepads y Joysticks están soportadas en WebGL (utilizando la clase Input) en navegadores que soportan
el API Gamepad de HTML5. Revise nuestra tabla de compatibilidad de navegadores para ver cuáles son estos
navegadores.

Tenga en cuenta que los navegadores sólo podrán permitir el acceso a los dispositivos de input disponibles
una vez que el usuario ha interactuado con el dispositivo mientras que el contenido tiene el foco. Esta es una
medida de seguridad para prevenir el uso de los dispositivos conectados para razones de fingerprinting del
navegador. Por esta razón, usted debería asegurarse de instruir al usuario en hacerle click a un botón en su
dispositivo antes de revisar con [Link]()) por dispositivos conectados.

Soporte táctil
Mientras que Unity WebGL oficialmente no soporta dispositivos móviles todavía, [Link] y las APIs
relacionadas son implementadas en navegadores y dispositivos con soporte táctil - al igual
que [Link].

Input de teclado y manejo de foco

Por defecto, Unity WebGL va a procesar todo el input de teclado enviado a la página, sin importar si el canvas
WebGL tiene foco o no. Esto es hecho para que el usuario pueda comenzar a jugar con un juego basado de
teclado de inmediato sin la necesidad de hacer click en el canvas para enfocar primero. Sin embargo, esto
puede causar problemas cuando haya otros elementos HTML en la página que deberían recibir input de
teclado, como lo son los campos de texto - ya que Unity va a consumir los eventos input antes de que el resto
de la página puede obtenerlos. Si usted necesita que otros elementos HTML reciban input de teclado, usted
puede cambiar este comportamiento utilizando la propiedad [Link].