Ya que estoy usando el motor de unity, decidí aprovechar las herramientas que me da para realizar las pruebas de software.

Hasta ahora todo el código que he escrito en unity ha sido en C# y cada vez que hacía uso de un plugin que me añadiese librerías o métodos, este lo importaba en unity y ya estaba disponible para referenciar en mi código. El problema vino que, a la hora de hacer las pruebas, necesitaba crear un Assembly específico para estas y añadir a ella todo el código que necesitase.

Esto hizo que todo mi código lanzase errores de dereferenciación.

Al no haber trabajado nunca con C# tuve que investigar que exactamente era un Assembly, como funcionaban y que era realmente lo me pedía unity para implementar las pruebas.

Resulto que Unity gestiona los Assembly (paquetes) por mí, pero en cuanto yo creo uno, cae en mi la responsabilidad de gestionarlos. Lo que me obligo a organizar TODOS mis plugins en Assemblies para no perder las referencias en mi código.

Para colmo, existen diferentes assemblies para código en tiempo de ejecución y código del editor de unity, lo que no hizo más que complicar las cosas.

Pero finalmente conseguí organizar todo de manera que compilase

Ninguno de los servidores TURN gratuitos que estoy usando parece que ser accesible desde una red movil. No se si esto es cosa de el servidor como tal o mi propia red movil, ya que he leido de gente online que si han conseguido realizar una conexión desde LTE.

Desde la misma red local no he tenido problemas en realizar una conexion, y aun me falta por probar desde dos redes mediante wifi, aunque espero que no resulte un problema, ya que he podido comprobar que desde wifi, si que se accede al servidor.

Desde el cliente elige como herramienta ARText, no aparece nada al pulsar ni se muestra el teclado. Basicamente no esta implementado.

Al colocar un elemento ARText, en android pide la entrada del teclado. No esta implementado para que pida la entrada en escritorio.

De momento lo aplazo hasta que haga el port a escritorio.

Un problema muy grande ha sido el encontrar una solución para poder transmitir los datos de video y audio y que no requiriese coste de servidores o tener que mantener el mío propio. Además, necesito que sea compatible con Unity ya que es el motor que necesito usar para implementar AR con el conocimiento actual que tengo sobre la tecnología.

Las opciones gratuitas que existen como Proton o Agora.io facilitan muchísimo la comunicación, así como la propia captura de video y audio, pero desafortunadamente, tiene demasiadas limitaciones como para poder desplegar una aplicación como la que estoy desarrollando.

Esto es lo que me lleva a recurrir a una tecnología P2P que me permita conectar dos pares y así ahorrar una cantidad inmensa de datos que ya no necesitan pasar por un servidor.

Tras mucha investigación llegue a WebRTC que es exactamente lo que necesito.

Este es el problema que con diferencia más ha retrasado el proyecto, ya que se une mi desconocimiento de la tecnología con la falta de soporte en Unity.

Tuve que llevarme un par de semanas sin descanso investigando sobre WebRTC en Unity, Con la esperanza de que hubiese algún tipo de implementación o plugin que me permitiese usarlo sin necesidad de desarrollar la comunicación desde cero.

Desgraciadamente lo poco que conseguí encontrar era de pago o tutoriales requerían de más conocimiento sobre la tecnología del que yo tenía.

Encontré una implementación de Microsoft específica para realidad mixta, orientada a las HoloLens, pero aplicable a cualquier aplicación, además ofrecía herramientas que simplificaban en gran medida el proceso de grabación y comunicación. Pero no tenía soporte para android, lo cual es imprescindible para mi proyecto.

Finalmente, no tuve más remedio que usar la implementación de WebRTC oficial de Unity, la cual está aún en fase de desarrollo (añadiendo soporte a android no más que en mayo de 2021) y me vi obligado a estudiar la tecnología para poder descifrar lo códigos de ejemplo y como aplicarlos a mi proyecto. Ya que la documentación sobre esta Implementacion en Unity es escasa o prácticamente nula.

Después de muchos intentos a base de prueba y error conseguí implementar la transmisión de video mediante WebRTC directamente desde Unity, aunque como consecuencia el resultado final no es perfecto y el proyecto se ha retrasado bastante.

Al recibir la notificación de una llamada entrante de un usuario registrado, es necesario pulsar el botón de aceptar llamada.

Si se pulsa la notificación, se abre la aplicacion en el menu principal.

Un problema que me he encontrado con la implementación de WebRTC en unity es que, en la API oficial de la tecnología, me permite acceder a las dimensiones del video que se me esta enviado y así poder asignar correctamente la relación de aspecto para visualizar el video original. Pero con unity, el método que comienza la transmisión en el lado del cliente, requiere del ancho y largo al que quiero recibir la imagen.

No entiendo con qué idea se ha implementado así, ya que no puedo conocer las dimensiones del video que voy a recibir hasta que no comience la transmisión, pero se me pide introducir unas dimensiones PRECISAMENTE para comenzar a recibir el video. Resultando en la imagen siempre deformada a menos que ambos dispositivos tenga exactamente las mismas dimensiones.

La manera en la que lo he solucionado es estableciendo una resolución por defecto en 16:9, con la misma anchura a la que ya sé que se va a enviar el video, la única que conozco. Luego, abriendo un canal de datos adicional cuando ya se realice la conexión, envío la relación de aspecto original al cliente, y "estiro" los pixeles verticalmente para que tengan la misma relación de aspecto que el video original, solucionando así la deformación.

Como ya he comentado, la implementación de WebRTC que estoy usando está siendo desarrollada a la vez que la uso. Por lo que además de una falta increíble de documentación, hay funcionalidades que directamente no están implementadas aún.

Una de ellas es la transmisión de audio. La API me permite transmitir audio, pero no hay forma alguna de que el receptor adquiera los datos. La funcionalidad está programada para mediados de julio de 2021, pero no me puedo permitir esperar hasta entonces para comenzar a probar el audio.

Gracias a un usuario de github, pude solucionar el problema codificando la entrada del micrófono a una cadena de bytes y mandarlo mediante el canal de datos de WebRTC.

Esto ha ralentizado el proyecto ya que, aunque ha proporcionado una solución, ha traído muchos problemas de cara a silenciar el micrófono sin corromper la cadena de bytes, problemas de volumen, echo etc... que me ha llevado semanas resolver y aun así no es óptimo.

Cuando este implementada la opción real de WebRTC hare la transición.

Debido a la manera en la que está pensado Unity, no es muy eficiente el tema de la interfaz para una aplicación de android en lugar de un juego.

Como realmente solo necesito unity para la funcionalidad AR, decidí usarlo como una librería externa en un proyecto nativo de android. Y así gestionar todo mediante la aplicación nativa, dejando solo la videollamada en unity.

En un principio conseguí crear la librería y podia controlar la actividad de Unity desde la aplicación nativa directamente y podía pasar mensajes si fuese necesario.

El problema surgió que una vez ya implementada la videollamada, había conflictos con la librería de firebase, y tras varias pruebas y viendo el tiempo que tenía disponible, decidí abandonar el proyecto de android y centrarme únicamente en la aplicación completa desde Unity.

De la manera en la que se muestra la imagen al usuario no es directamente desde la camara de unity, ya que esta está siendo grabada para transmitirse y por tanto inutilizable. De la manera que se muestra es asignando la textura que se está grabando a una imagen que colocamos justo en frente de otra camara, la cual no está transmitiendo y por tanto es utilizable.

Este método supone una carga mayor en el dispositivo y la conexión, por lo que reduzco gratamente la resolución de la textura que se muestra para no sobrecargar el dispositivo.

Esto lleva al problema de que la manera de obtener el input del usuario de basa en el pixel que este haya pulsado, y unity presenta métodos para traducir esta coordenada a puntos en el entorno 3d. Pero al reducir la textura que se está mostrando, si simplemente le dijéramos a unity el pixel que el usuario pulsa lo muestre por pantalla, esa coordenada seguramente quede fuera de la textura, ya que tiene muchos menos pixeles.

Este problema lo he remediado haciendo una clase que encapsule la funcionalidad básica del input del ratón/dedo y hago una conversion del pixel que se ha pulsado al pixel que se debería pulsar dada la textura más pequeña que se muestra. De esta manera, de cara a la programación no tengo que preocuparme de corregir el input, simplemente pregunto la posición a mi clase en lugar de la de unity.

Con esta clase controló también el input del cliente, en el que además de convertir las coordenadas, las envío por un canal de datos al host, el cual ahora simula una pulsación cada vez que el cliente pulse su pantalla.

WebRTC modela la comunicación entre pares, pero requiere que ambos hayan establecido ya una conexión. Esta conexión es lo que se conoce como signaling y decidí usar firebase, ya que el plan gratuito me ofrece más que suficientes límites para transmitir la cantidad de datos que necesito y dispone de funcionalidades aparte de la base de datos que mi proyecto necesita, como son la autenticación por teléfono móvil, distribución mediante google play, hosting gratuito, etc...

Donde surge el problema es que la API para acceder a la base de datos a tiempo real, por la naturaleza de la tecnología, emplea métodos asíncronos, algo que conozco, pero con lo que apenas he trabajado antes.

Esto no sería un problema de no ser por el modo particular en el que Unity trabaja con métodos asíncronos. Esto me ha llevado a muchísimos quebraderos de cabeza intentando acceder a un dato cuando este aún no estaba inicializado.

No solo he tenido que reescribir gran parte de mi código para que sea compatible con llamadas asíncronas, sino que he tenido que mezclar la manera en la que C# trabaja con métodos async y unity usa corrutinas con IEnumerator.

Aunque esto ha retrasado bastante el proyecto, al menos me ha servido para comprender mejor el motor de Unity corregir más rápidamente errores futuros.

Debido a la implementación de Unity de WebRTC, la aplicación no está disponible en dispositivos con ARMv7. Solamente aquellos con ARM64 pueden instalarla.

En un futuro cuando añadan soporte a más dispositivos actualizare la app para tenerlo en cuenta.