El Fin

Este blog llega a su fin, probablemente definitivo.

Empecé este trabajo en parte para obtener el D.E.A., y en parte para matar el gusanillo que tenía sobre programación en temas de imagen sintética y 3D. He cumplido ambos objetivos, y a partir de ahora dedicaré mis energías a la otra línea de investigación que inicié al mismo tiempo que esta.

Aquí queda el blog, que me ha resultado una buena herramienta como repositorio de mis experiencias, averigüaciones y diario de progresos y retrocesos. Espero que pueda resultarle útil a alguien algún día; y si no tampoco pasa nada, me ha gustado crearlo de la nada e irlo llenando poco a poco.

Nos vemos...

Óscar.

Prueba con otra PDA

Una de las dudas que quedaban con el avatar era si funcionaría "tal cual" en otro dispositivo, pensando en que la librería de Loquendo es propietaria y requiere de una licencia.

Hoy me han dejado una PDA (una Fujitsu-Siemens Loox 720) más moderna que la mía (una HP iPAQ 1940) para la otra línea de investigación con dispositivos móviles, y he copiado los ficheros binarios del programa y librerías necesarias, como la de OpenGL-ES y la de Loquendo.

La aplicación se ejecuta sin problemas, pero tal como se temía no funciona la librería de Loquendo, aparece un mensaje que indica que es necesario adquirir una licencia.

La parte gráfica sí que funciona, aunque curiosamente va algo más lenta, a pesar de que la PDA es más moderna y rápida que la que usaba yo. ¿Cómo es posible? Mirando las características de ambas resulta que la Fujitsu aunque es más rápida tiene una resolución VGA (640 x 480) mientras que la de la mía es la mitad (320 x 200). La CPU va aproximádamente al doble de megahercios (que tampoco significa mucho, los procesadores son diferentes), pero el número de píxeles es el cuadruple, así que es comprensible que le cueste más de hacer todos los cálculos, porque tampoco lleva aceleración gráfica por hardware. Lo que es de destacar es que la librería de OpenGL-ES (la Vincent Mobile 3D) haya detectado la resolución de la pantalla y haya adaptado a ella los gráficos de forma transparente, sin dar ningún problema ni ningún aviso.

Lo siguiente será probrarlo en un teléfono móvil (tipo Smartphone) que es para lo que se había pensado en un principio.

Demo

Le he enseñado el avatar funcionando a la profesora que me lleva el trabajo de la línea de investigación. Hasta ahora solo había visto algún vídeo del avatar en corriendo en el emulador, pero no en una PDA real ni con la síntesis de voz.

Antes he mejorado un poco el aspecto y usabilidad del programa. He programado que para cada botón de la PDA diga una frase diferente, y he añadido un menú flotante con varias opciones, entre las que están habilitar o deshabilitar la iluminación del modelo, ídem con el renderizado de polígonos ocultos, o elegir entre varios juegos de frases de demostración.

La demo en sí creo que le ha gustado bastante. Después hemos estado hablando sobre mejoras que podrían hacérsele, aplicaciones (p.e. como interfaz de usuario para un sistema de control domótico mediante teléfono móvil), posibilidades de publicar algo en alguna revista o congreso, y completar el report que le entregué en julio con lo último que había hecho con el programa del avatar.

Sincronización solucionada

Finalmente creo que he conseguido solucionar el tema de la sincronización. Para ello he utilizado la forma de reproducción tipo polling en el que se consulta en un bucle el estado de la reproducción del sonido, y se continúa con ella mediante la llamada a una función de lectura si no hubiera finalizado. Tras hacer varias ejecuciones de prueba se observa que en cada vuelta del bucle la función que hay que llamar para reproducir el siguiente sonido lee un fonema cada vez. Combinándolo con la función de callback antes mencionada que indicaba el código del fonema, se obtiene una forma precisa de controlar el momento en que se reproduce el sonido para poder intercalar la representación del gráfico del avatar correspondiente.

Al ejecutar el programa sobre el dispositivo real de pruebas la reproducción del sonido se oía entrecortada, debido con toda seguridad a que su CPU no tenía capacidad de proceso suficiente para renderizar el modelo en pantalla (recuérdese que no hay aceleración hardware) y generar la síntesis de voz con la velocidad suficiente como para que se oiga de forma fluida. La forma de solucionarlo fue simple: pintar el avatar en la pantalla una vez por cada N fonemas reproducidos. Si el valor de esta N es demasiado bajo la animación será más fluida pero el sonido se oirá entrecortado, y si es demasiado alto sucederá lo contrario, el sonido se oirá bien pero habrá menos frames por segundo para la animación y será menos fluida. Tras algunas pruebas en el dispositivo utilizado para el desarrollo este valor resultó ser de 3 o 4, es decir, de cada 3 o 4 fonemas generados se refresca la pantalla una vez, dando como resultado una animación que sin ser perfecta, es bastante decente.

Después de hacer estos ajustes en el programa y sus parámetros, el aspecto del log es como este (ver entrada anterior para saber qué es cada columna):



Como puede observarse, ahora las llamadas a la función pintarMalla están espaciadas más regularmente que antes y siempre después de que se han generado 3 o 4 fonemas indicados por sus códigos IPA.

Probando otra forma de sincronización

Vuelvo a retomar el avatar donde me había quedado. Antes de probar nada con lo threads (que me dan algo de respeto por haber trabajado poco con ellos, y menos en un entorno tan limitado) voy a probar otra cosa que se me ha ocurrido.

En una entrada anterior comentaba que con la librería de Loquendo hay dos formas no bloqueantes de reproducción del sonido. Una es la que ya había probado (TTSNONBLOCKING). El otro que voy a probar ahora es el TTSSLICE y consiste en que la reproducción se hace en un bucle. Mediante una función se sabe si ha terminado o no, y en el primer caso se continúa con ella llamando a otra función.

Reunión con David

Hoy he estado hablando con David, que pertence al Grupo de Informática Gráfica Avanzada donde estoy haciendo el trabajo. Él está trabajando en algo parecido a lo mío, un avatar que habla y mueve la boca de forma sincronizada, aunque sobre plataforma PC y haciendo por detrás más cosas que el mio, que solo habla y nada más.

Él también estaba teniendo problemas con la sincronización y hemos estado hablando sobre ello. En principio lo que le pasa a él y a mi son cosas diferentes. Él parece que tiene problemas con el interface de SAPI con la librería, y que se le retarda el sonido respecto a la animación. Lo mío, no es nada de SAPI (por que no existe para el Windows Mobile que yo uso) y más que retrasarse o adelantarse el sonido lo que me pasa es que no se muestran los frames en el momento que deberían.

Me ha dado alguna idea de cosas que podría probar, como usar buffers y threads de forma explícita (actualmente no lo hago, "confío" de alguna forma en los que maneja por debajo OpenGL y Loquendo).

Lo probaré a ver si mejora el comportamiento... pero antes me voy a tomar unos días de descanso, que después de lo del D.E.A y los días previos me vendrá bien desconectar un poco.

Prueba del D.E.A

Hoy al mediodía he tenido la prueba del D.E.A., que dado que estábamos mucha gente se ha hecho en dos días (ayer y hoy).

La impresión que me ha quedado no ha sido muy buena, aunque tampoco mala del todo. He explicado lo que había hecho durante el curso, y por las preguntas que me ha hecho después el tribunal me he quedado con la impresión de que quizás me haya centrado en mi exposición demasiado en el proceso de desarrollo y demasiado poco en el de investigación. O lo he transmitido así porque no he sabido hacerlo de otra forma, o realmente quizás el trabajo haya sido más de desarrollo que de investigación.

Luego además al final no he hecho ningún artículo para publicar sobre los trabajos, ni he ido a ningún congreso, ni "otros méritos", así que aunque no me de puntos negativos me dejará de dar positivos.

Pero bueno, ya está hecho, y de la mejor forma que he sabido hacerlo, así que por ese lado estoy tranquilo y satisfecho, alea iacta est. No creo que me suspendan, porque algo he hecho, aunque tampoco voy a tener una nota precisamente brillante.

A preparar el D.E.A

El problema de la sincronización sigue ahí, he hecho alguna prueba para intentar resolverlo pero no lo he conseguido (estas pruebas no tenían nada que ver con lo de los threads que comentaba el otro día).

Ahora dejaré el tema aparcado por un tiempo. El próximo lunes 17 es la prueba para el D.E.A. (Diploma de Estudios Avanzados). Hay que hacer una exposición oral de unos 10 a 15 minutos sobre los trabajos de investigación realizados en el curso. Toca preparar la presentación con el PowerPoint (o en mi caso con el OpenOffice Impress) y ensayarla de viva voz unas cuantas veces para asegurarse de que no queda muy corta ni muy larga, y de que se dice todo lo que se quiere decir sin hacer pausas ni que se trabe la lengua.

Problema de sincronización

He estado investigando el problema que tengo con la sincronización de la voz y la animación. Para comprenderlo mejor estoy guardando en el fichero de log de la aplicación la mayor cantidad de información posible, y para este caso concreto he añadido los milisegundos que lleva en ejecución el programa para ver los tiempos en los que se reproduce el sonido y se pinta la imagen.

Después de algunas pruebas he averiguado que es lo que pasa, pero todavía no se la razón. No es que la voz y la imagen estén desincronizadas, pasan dos cosas:

• Se generan más fonemas de los que se representan. Esto no es problemático, ya comentaba en una entrada anterior que solo se representaban seis visemas (las vocales y la eme).
• Por lo anterior, solo uno de cada dos o tres (pongamos tres) fonemas se pintan en pantalla.
• Observando el log y lo que se ve en la pantalla, parece que se reparte mal el tiempo dedicado a cada una de las dos cosas, y así, a veces se pinta cuatro veces seguidas un mismo visema y no se pronuncia niguno nuevo (dando lugar a un chasquido o microcorte en la reproducción del sonido), y otras veces pasa justo lo contrario, el sonido se oye con fluidez pero la animación queda paralizada.

Como ejemplo, pego aquí una imagen del log generado (clic para agrandar):


La relación entre el número de fonemas y las veces que se pinta la malla no es equitativa ni constante, y es por eso que la animación no va fluida ni sincronizada. Por ejemplo, entre el ms. 6184 y el 6640 se generan 15 fonemas, y el último de ellos (correspondiente a la malla 6) se representa en pantalla 3 veces seguidas. Lo contrario ocurre en entre el ms. 6472 y el 7577. En este caso se pronuncian solo tres fonemas, pero solo se pinta el último de ellos 4 veces. Lo ideal sería que los refrescos de pantalla sucediesen aproximadamente a intervalos regulares con respecto a los fonemas generados.

La solución que se me ocurre puede ser bastante complicada y no es seguro que funcione, pasaría por ajustar de alguna forma la prioridad de ejecución de los threads que se encargan del OpenGL-ES y de la librería de Loquendo. Cosa complicada a priori por dos razones: Desconozco cómo está ese tema en Windows CE y en eVC, y también desconozco si ambas librerías los utilizan y si es posible acceder a ellos.

Animación+voz implementada y un problema

Ya he hecho una primera implementación del avatar moviendo la boca mientras dice algunas frases.

Para esta primera aproximación solo se muestran en la animación unos pocos visemas, que son los de las vocales y la letra 'm', que coinciden más o menos con la posición de la boca de las mallas del avatar que tengo ahora mismo. Si funciona bien, se pueden añadir más.

La forma de hacerlo es con la función de callback que comentaba en la entrada anterior. Cada vez que se pronuncia un fonema se indica su código IPA y de esa forma puedo saber cual es. He programado que se registren estos códigos en el fichero de log de la aplicación, y después he hecho que pronuncie palabras solo con la letra 'a', luego con la 'e', etc. y así he obtenido los de las cinco vocales. Curiosamente para cada una hay dos códigos distintos, aunque no me he fijado bien si unas veces sale uno cuando va acompañado de consonante, o cuando empieza o termina una palabra, etc..

Conocido el fonema ya se la malla que hay que representar, y lo indico en una variable para que en el próximo refresco de pantalla se pinte.

El problema que me he encontrado es que la sincronización entre la animación de la boca y el sonido no es precisamente buena, baste decir que a veces coincide lo que suena con lo que se ve en la pantalla de la PDA.

Callbacks

La librería de Loquendo permite definir una función de callback, esto es, una función a la que se llama automáticamente cada vez que hay algún evento para hacer algo con él.

Entre estos eventos están por ejemplo: Comienzo de la reproducción del sonido, finalización, generación de un fonema, buffer de salida lleno, y similares. Estos eventos tiene un identificador de forma que en la función de callback podemos saber cual se ha disparado para hacer con él (si procede) lo que queramos. Uno muy interesante es el de la generación de fonemas. Cada vez que se genera uno se pasa a la función su código IPA y de esta forma se puede saber la forma de la boca que habría que dibujar. ¡En la propia documentación de Loquendo indica que de esta manera se pueden programar avatares!

Reproducción de voz bloqueante y no-bloqueante

He comenzado a incluir código para el TTS en el programa del avatar. De momento solo está la iniciación del sistema de síntesis de voz, y una frase que se dice al ejecutar la aplicación.

He estado mirando en el manual el tema de la reproducción del sonido bloqueante y no bloqueante. A mi la que me interesa es la segunda, que consiste simplemente en que la reproducción del sonido de la locución se hace en un thread separado del programa principal y de esa forma se pueden hacer otras cosas mientras.

Con las librerías de Loquendo hay dos formas de hacer esto. Una, la más simple, es usar un parámetro de la función que reproduce la voz, que hace que esta se ejecute en background hasta que termina. La otra forma consiste en hacer polling, es decir, se lanza la reproducción y a continuación se entra en un bucle en el que se va consultando si ha terminado o no.

Ahora tengo que ver cómo hago para que mientras suena la voz, se muestre la imagen adecuada del avatar con la boca en una u otra posición.

Problema con GLUT|ES. Solucionado

Me había quedado con un problema inquietante: Al compilar y ejecutar el avatar en el emulador del eVC, todo funcionaba perfectamente, pero al compilar para ejecutarlo sobre una PDA real, primero aparecían mensajes del linker, y cuando se conseguía generar el ejecutable no funcionaba como se suponía que debía hacerlo, es decir, el programa se abría pero no aparecía la imagen del avatar, aunque sí los menús.

Recordaba haber compilado el programa hace algunos meses para ser ejecutado en la PDA de verdad, y que había funcionado correctamente, así que como por suerte tenía alguna copia de seguridad las he utilizado para hacer unas pruebas. La más reciente era de justo el momento en que pasé de usar UG a GLUT|ES para los menús y las ventanas. La he compilado, y el resultado era el mismo que con el avatar, no se mostraba nada en la pantalla, aunque la aplicación se ejecutaba. He probado lo mismo con la copia más antigua, que era del momento justo anterior a que usara GLUT|ES, y al compilar el programa sí que ha funcionado.

Así que el problema parecía estar en esa librería. El día anterior probé varios ejemplos binarios descargados de la página de ZeusCMD para asegurarme de que funiconaba, y así era. Pero entonces he recordado los mensajes de advertencia del linker y todo lo que tuve que hacer para solucionarlos. Esos mensajes solo aparecían al compilar para ARM. He abierto los ejemplos de ZeusCMD y los he recompilado, copiándolos después a la PDA y ejecutándolos. Entonces se ha reproducido el error, la pantalla aparecía negra. Los ejemplos en formato binario que sí que funionaban ya venían compilados y linkados estáticamente, así que parece que el problema es la librería estática de GLUT|ES con la que se enlaza el ejecutable de mi programa al compilarlo.

De hecho, el mensaje de aviso que se muestra:

glutes_static.lib(seccook.obj) : warning LNK4078: multiple '.CRT' sections found with different attributes (40300040)
LINK : fatal error LNK1104: cannot open file 'LIBCMT.lib'

Al buscarlo en la ayuda del propio eVC, esto es lo que dice:

LINK found two or more sections that have the same name but different attributes.

Possible cause

An import library or exports file was created by a previous version of LINK or LIB.
Recreate the file and relink.


Es decir, para evitar que aparezca habría que recompilar desde los fuentes la librería de GLUT|ES, cosa nada fácil a priori.

He consultado la página de ZeusCMD, por si la forma de instalar GLUT|ES era incorrecta, y he encontrado un párrafo que había olvidado, que dice que al usar el binario o intentar recompilar los fuentes de la librería había personas que tenían problemas, y ofrece una versión recompilada de la susodicha librería estática. La he descargado y copiado en el lugar correspondiente, y una vez más he compilado el programa del avatar. Al ejecutarlo, ¡ha funcionado! Así que era eso, el binario de la librería estática de GLUT|ES para ARM no funciona bien con el Embedded Visual C++.

Después, solo por curiosidad, he deshecho los pasos que tuve que seguir para que no saliera el error del linker que he escrito antes, y he hecho de nuevo la prueba para asegurarme, confirmando el resultado:

• Con la librería glutes_static.lib para ARM original: Mensajes de error y warnings del linker -> Necesidad de modificar parámetros de compilación -> La aplicación no funciona como debería.

• Con la librería glutes_static.lib para ARM recompilada por ZeusCMD: No aparecen mensajes de error ni warnings -> La aplicación funciona correctamente.

Solucionado esto, espero poder ya de una vez integrar la librería de Loquendo en el programa del avatar.

Un avance y un retroceso

El avance: Me ha contestado el servicio técnico de Loquendo y me ha enviado otra licencia para activar su producto. La he instalado y he ejecutado uno de los pogramas de demostración, y esta vez ha funcionado como se esperaba. A continuación he compilado el programa de prueba, lo he ejecutado en la PDA y también ha funcionado, y he podido escuchar por el altavoz el texto escrito en el programa.

Con la síntesis de voz funcionando, he añadido al programa del avatar el código de ejemplo y de nuevo lo he compilado.

El retroceso: Al ejecutarlo en la PDA, la pantalla se queda de color negro y no sale la cabeza del avatar. En cambio, al ejecutarlo en el emulador funciona perfectamente. Al principio del desarrollo recuerdo que hice una prueba sobre el dispositivo real, y funcionaba. ¿Qué ha cambiado desde entonces? Lo único que se me ocurre es que para el manejo de las ventanas pasé de usar UG a GLUT|ES, así que he revisado este último.
No he encontrado nada raro. Para confirmar que funciona correctamente me he bajado algún ejemplo compilado de las lecciones de la página ZeusCMD y los he ejecutado en la PDA, todos correctamente.

Así que el problema tiene que estar en el código. Toca revisarlo, y no se por qué funciona bien en el emulador y mal en la PDA real.

Problema extraño compilando para ARM

Mientras me contestan de Loquendo por el problema con la licencia estoy revisando el código de lo que llevo hecho hasta ahora. He probado a compilar el programa generando código para ARMV4, con el fin de ejecutarlo en una PDA real en vez de en el emulador.

Al construirlo, me sale un error del Linker:

LINK : fatal error LNK1104: cannot open file 'LIBCMT.lib'

Como es habitual, he dedicado el par de horas siguiente a buscar información sobre el susodicho, y como es habitual no he encontrado ninguna solución clara. Leyendo de aquí y de allá y probando diferentes cosas al final lo he solucionado. No se exactamente cual es el problema, pero lo he arreglado siguiendo los siguientes nada-triviales y nada-intuitivos pasos:

- En Project -> Settings -> Link -> Input, donde dice Ignore libraries, añadir a lo que haya exactamente lo siguiente:

,libcmt.lib,oldnames.lib

Es decir, el nombre de las dos librerías que dan problemas separadas por comas, si se utilizan espacios como en otras opciones que hay en el mismo cuadro de diálogo no funciona.

Después de hacer eso el programa se compila correctamente y se copia por ActiveSync a la PDA, donde se puede ejecutar sin más contratiempos.

Problemillas con Loquendo

Me he encontrado con un par de problemas, aunque más que problemas yo diría que son inconvenientes o features:

- El ruido blanco que decía ayer que sonaba al ejecutar la aplicación de prueba en la PDA no era problema de licencia, sino de que usaba un formato de codificación de voz que no está disponible para la versión embebida del software. Sucede si se copia tal cual el programa de ejemplo que viene en la guía del usuario, en particular, hay que cambiar la línea de código

err = ttsNewVoice(&hVoice, hInstance, "Jorge", 16000, "l");

por

err = ttsNewVoice(&hVoice, hInstance, "Jorge", 16000, "loqmsx");

ya que según indica la guía para Windows CE:

the voice database encoding formats available are loqmsx (8 KHz and 16
KHz) and loq210 (16 KHz); linear, μ-law and a-law encodings are not
supported;

- El otro problema es precisamente el de la licencia. Tras hacer el cambio anterior una clara voz suena en el altavoz diciendo a los cuatro vientos que el producto necesita una licencia para funcionar. Mediante una utilidad obtengo un identificador de la PDA (con aspecto de dirección MAC), lo envío mediante la página del fabricante y me devuelve un txt y un exe. El txt contiene la licencia en formato 'registro de Windows', y el ejecutable al lanzarlo en el PC se conecta por ActiveSync a la PDA y un mensaje dice que lo registra correctamente. A continuación, vuelvo a lanzar el programa de prueba y la voz dice otra cosa diferente, pero sigue sin ser lo que debería. Esta vez dice que la licencia instalada no es válida para ese dispositivo. He mandado un mail al soporte técnico de Loquendo, y ahora estoy a la espera a ver si se puede solucionar.

Compilación usando Loquendo

He conseguido compilar y ejecutar un programa de prueba que usa la librería de Loquendo y casi-funciona sobre una PDA real.

Cosas que faltaban el último día para funcionar:

- Sobre el lío de arquitecturas ARMV4 y ARMV4i: La buena, la que funciona de verdad en mi PDA es la ARMV4, que según lo que ponía en el post anterior es la que se corresponde con PocketPC 2003 . La ARMV4i es más moderna, y se corresponde con Windows Mobile 5.0. No hay que cambiar a mano ningún parámentro con la arquitectura de salida, tal como se decía erroneamente en el susodicho post (*).

- Además de las voces (por ejemplo 'Jorge'), en la PDA hay que instalar también el SDK. En mi caso concreto, el fichero con extensión .CAB que hay dentro de Loquendo_Embedded_TTS_6-PPC2003_SDK_Distribution_6.6.17.zip

- El anterior instala unos ficheros en el directorio de la PDA \Archivos de Programa\Loquendo\Loquendo TTS. Dentro de él hay varias DLLs y pogramas de prueba. Por ejemplo, el que se llama LTTSDemoMSX permite seleccionar una voz, escribir un texto en la pantalla, y hacerlo sonar por el altavoz de la PDA. Como curiosidad, al no tenerlo licenciado en lugar del texto la voz dice que es necesario instalar la licencia antes de usarlo.

- Sobre el programa de prueba: Tras construirlo para ARMV4 (PocketPC 2003) se copia el ejecutable automáticamente al directorio raiz de la PDA. Si se intenta ejecutar sale un error que dice que no es posible hacerlo porque falta un componente. Mensaje completamente distinto al que decía que no es una aplicación válida PocketPC. Para que encuentre los componentes que le faltan (las DLLs, vamos) se puede copiar el ejecutable en el directorio de instalación de Loquendo mencionado en el punto anterior.

- Tras copiar el ejecutable donde están el resto de componentes, al hacer doble click con el puntero se ejecuta sin dar más errores. En lugar de una voz se oye un ruido blanco, posiblemente por el tema de la licencia que se mencionaba antes. Para conseguirla hay que ejecutar un programa llamado GetID, que devuelve un código que hay que enviar a Loquendo para que a su vez manden la licencia que permite hacerlo funcionar.

- Para averiguar lo anterior me ha venido muy bien una utilidad que tra el Embedded Visual C++ llamada 'Dependency Walker', situada en el subdirectorio Common\Tools de la instalación de eVC. Lo que hace es, a partir de un fichero .EXE, mostrar las librerías dinámicas y estáticas de las que depende. De esa forma, he podido ver que necesitaba una DLL llamada LOQTTS6.DLL que no se encontraba en mi PDA, y a partir de ello me he dado cuenta de que tenía que instalar el SDK.



(*) Entrada de la Wikipedia aclaratoria sobre los nombres de los sistemas embebidos de Microsoft: PocketPC
Diferencia entre ARMV4 y ARMV4i.

Loquendo y eVC

Llevo toda la semana luchando a brazo partido con la librería de Loquendo y el Embbeded Visual C++ para compilar un ejemplo sencillo que viene en la documentación.

Problemas que me he encontrado:

- Errores del tipo:

main.obj : error LNK2019: unresolved external symbol __imp_ttsDeleteInstance referenced in function main
main.obj : error LNK2019: unresolved external symbol __imp_ttsRead referenced in function main
(...)


Parece que no encuentra la librería para enlazar, a pesar de que está indicado en las propiedades del proyecto el directorio donde residen (Tools -> Options -> Directories). Dejan de producirse incluyendo en el código la siguiente línea:

#pragma comment(lib, "LoqTTS6.lib")

que especifica la librería concreta con la que quiero que se linke.



- Error del tipo:

corelibc.lib(pegwmain.obj) : error LNK2019: unresolved external symbol WinMain referenced in function WinMainCRTStartup


Que se soluciona en Project -> Settings -> Link -> Output, y cambiando el Entry-point symbol del valor WinMainCRTStartup a simplemente main



- Error del tipo:

LoqTTS6.lib(LoqTTS6.dll) : fatal error LNK1112: module machine type 'THUMB' conflicts with target machine type 'ARM'


Este ha sido más peliagudo. He encontrado esta página de un foro de Microsoft donde lo aclara un poco, abajo del todo dice esto:

You need to look at all of your compiler and linker inputs and outputs, and figure out whether you are being consistent in your code generation. Keep in mind that:

* PPC 2003 is ARMV4 --> linker switch/machine type = ARM
* PPC 5.0 is ARMV4I --> linker switch/machine type = THUMB

You can't mix and match compiled binaries for each platform. Thanks,

Así que, por probar, he ido de nuevo a Project -> Settings -> Link -> Output y en el cuadro de abajo donde sale la línea de comando del linker (Project Options) he buscado el parámetro /MACHINE y sustituido ARMV4 por THUMB. EDITADO:¡MAL HECHO!.

Después de eso el programa de prueba se puede construir (compilación + linkado) correctamente. La versión de la librería no se puede ejecutar en el emulador, así que copio el ejecutable a una PDA real. Lo lanzo y... error, dice que no es una aplicación para PocketPC válida.

Parece pues que la diferencia entre ARMV4 y ARMV4I es mucha, yo pensaba que no. Eso, o que me he pasado de listo al forzar la compilación. Creo que miraré a ver si hay alguna versión de la librería para ARMV4 "a secas".

Vuelta de vacaciones

He estado dos semanas de vacaciones y ya he vuelto. Ahora toca retomar el asunto del avatar, concretamente intentar hacerlo hablar.

Para ello voy a utilizar librerías comerciales de Loquendo, disponibles para varias plataformas. El Dpto. de la Universidad me ha proporcionado la forma de descargar una versión de evaluación.

Por cierto, he mirado en el expediente la nota que me han puesto en la línea de investigación y ha sido un 9'5, así que muy bien :-)

Documentación entregada

Finalmente no pude terminar la documentación para entregarla el viernes y la he acabado de escribir durante el fin de semana. Ya se la he mandado por mail a la profesora en PDF.

Después de dos semanas de documentación intensiva (entre esta Línea y la otra), ahora llega la calma.

Documentación de fin de curso

Iba a continuar mirando lo del Text to Speech, bien probando a recompilar la librería Flite o probando una versión de evaluación de Loquendo, pero estamos ya en julio y se aproxima la fecha de entrega de actas (el día 11). Tengo que ir ya redactando el informe de lo que he estado haciendo, y dejar esto de momento para seguir después, si procede.

La extensión en páginas es libre y también el formato, menos mal, porque las plantillas tipo artículo a dos columnas son muy feas. Ya tengo pensada la estructura, que será la típica: Introducción, estado del arte, elección de herramientas, proceso de desarrollo, trabajos similares, conclusiones y bibliografía.

A ver si lo tengo para el final de esta semana o como muy tarde para el lunes 9.

Interrupción

Estos últimos días apenas he podido dedicar un par de horas a trabajar en la línea de investigación. Han operado a mi hermano pequeño de peritonitis y me he pasado todo este tiempo en el hospital con él.

El impulso final que le faltaba al trabajo tendrá que posponerse, o quedarse tal como está.

A vueltas con SAPI

Me han recomendado que para hacer hablar al avatar prueba con SAPI, la librería de Microsoft para síntesis y reconocimiento de voz. Llevo varios días con ello y mis avances son pocos. Se hace dificil encontrar información sobre SAPI para PocketPC/Windows Mobile/Windows CE porque casi todo lo que encuentro se refiere a las plataformas de escritorio y de servidor.

Por otro lado, según lo que voy encontrando "parece" que los entornos de programación donde se usa son Visual Studio 2003 y Visual Studio .NET. Sobre el Embedded Visual C++ que venía utilizando hasta ahora no he encontrado nada.

Mucho me temo que hay un conflicto en ciernes: Si utilizo el eVC me funcionará la librería de OpenGL-ES pero no la SAPI. Si utilizo Visual Studio pasará lo contrario. Temo que tenga que volver a los problemas que ya tuve al principio de este trabajo.

Mientras tanto estoy descargando e instalando SDKs variados, a ver si acierto con el que necestio, porque hay tantos productos de Microsoft con nombres parecidos que ya no se cuál es cuál.

Intentado hablar

He buscado la forma de hacer hablar al avatar, y más en general a la PDA sobre la que estoy haciendo el desarrollo.

Por un lado, existen las librería SAPI de Microsoft, pero no tengo claro que me vayan a servir, ya que son "demasiado modernas" para el entorno que estoy usando.

He encontrado también Flite, que es una implementación ligera de un conocido programa de sintésis de voz llamado Festival. Hay disponible una versión precompilada para PocketPC y la he instalado en el mío para probarla. Es un ejecutable que al lanzarlo muestra una ventana donde se puede escribir un texto, y a continuación la PDA lo "habla" por el altavoz, hablando eso sí muy robóticamente y con la fonética del inglés norteamericano.

El programa puede ejecutarse pasándole como parámetros de la línea de comandos la frase que se desea decir. Podría hacer una prueba quick-and-dirty ejecutando desde el programa del avatar el Flite con las frases que quiero oir, aunque solo funcionará en una PDA "de verdad", porque para que funcionara en el emulador el programa tendría que estar compilado para x86 en lugar de para ARM

Algo tan aparentemente sencillo como ejecutar un programa (el Flite) desde otro programa (el del avatar) se ha convertido en una tarea imposible. En las ayudas del Embedded Visual C no he encontrado cómo hacerlo. Las funciones de C que se usan habitualmente para esa tarea, como exec(...), execve(...) o incluso popen(...) o system(...) no están disponibles en este entorno.

Lo malo es que no he encontrado ninguna forma de hacerlo, ninguna, ni bonita ni fea, y he estado toda una tarde con ese "detalle". De paso me he enterado que el emulador que viene con el Visual Studio 2005 sí que es un emulador real de ARM, y se le pueden instalar binarios que funcionarán, como (quizás) el Flite. Lástima que tuviera que abandonarlo porque no funcionaba la librería Vincent Mobile.

Primera aproximación

He hecho una primera prueba para ver qué tal queda la animación. Disponía de varios ficheros del modelo con la boca en posiciones diferentes, y simplemente he programado que se carguen todos (son siete) y luego se muestren de forma aleatoria durante el tiempo suficiente para que no vaya ni muy deprisea ni muy lento.

Queda bastante bien. No se hace ningún cálculo, en lugar de eso se ocupa memoria aunque no demasiada: La estructura de datos tiene un tamaño de unos 160 kb, así que los siete más la imagen del programa (unos 75 kb) no llegan a 1 megabyte.

La primera prueba ha sido hacer mover solo la boca de la cabeza, pero quedaba muy frío. Después he introducido un pequeño movimiento de uno o dos grados hacia los lados y hacia arriba/abajo, para que al hablar produjera un movimiento como de "cabeceo". Quedaba menos rígido pero entonces a reaparecido el problema de los polígonos que no se pintan bien cuando hay mucha concentración en una zona, provocando un efecto muy feo.

Lo siguiente que probaré será el habla, y juntarlo con esta animación. Si consigo las dos cosas, me dedicaré a refinarlo y hacerlo más elegante.

Ideas para la animación

El problema de los polígonos finalmente va a ser "rodeado". En vez de invertir tiempo en intentar solucionarlo con la programación o cambiando la librería, se van a usar mallas más sencillas para que no ocurra.

Hemos comenzado a pensar en la animación. De momento se quiere mover solo la boca y luego ya se verá cómo añadir sonido y sincronizar ambas cosas. Para hacer la animación se valoran dos aproximaciones:

- Animación de esqueleto: Definir una estructura de datos que representa los huesos, y asociar una malla a cada uno. Cada vez que se muevan, la malla lo hará con él. Esta forma es muy apropiada para personajes completos y con una estructura más o menos compleja, pero no parece muy adecuado para nuestro caso, donde solo hay una cabeza, sin apenas articulaciones.

- Deformación de malla: Se tienen dos modelos, uno con la boca completamente abierta y otro completamente cerrada. Han de tener la misma estructura geométrica, con los puntos y los polígonos definidos con los mismos índices de la lista. A partir de las diferencias de coordenadas entre ambos modelos, se pueden calcular interpolando los puntos intermedios y generar la animación. Más sencillo para animación facial.

Se va a optar por el segundo. Los problemas que pueden surgir son limitaciones de memoria (al tener que almacenar dos o más mallas) o de CPU (al tener que recalcular todo el modelo al variar las coordenadas de sus vértices). Si se da cualquiera de los dos, habrá que pensar en alguna forma de optimización para evitarlo.

Probando Hybrid Rasteroid

He estado intentado utilizar una librería de OpenGL ES alternativa a la Vincent 3D, y he probado Hybrid Rasteroid, que se menciona en los primeros tutoriales de la página de ZeusCMD.

La forma de utilizarla es similar a la que ya estaba utilizando, y consiste en copiar los ficheros que vienen en el archivo descargado (los Includes, los .lib y los .dll) a los respectivos directorios del entorno de desarrollo. Haciendo algunos pequeños cambios en el código he conseguido compilar sin problemas el programa del avatar, y hasta ahí he podido avanzar. Después de eso al cargar el ejecutable en el emulador no funcionaba, devolvía un error en el que decía que no era una aplicación válida o que le faltaba un componente. Después de buscar en páginas y foros apenas he encontrado nada de información, solo un "truco" para nada lógico ni intuitivo. Tras aplicarlo, he conseguido que la aplicación hiciera un "amago" de funcionar (llega a escribir algo en el fichero de log) pero entonces me aparecía una ventana de error en la PDA que venía a decir que GLUT|ES no podía iniciar las OpenGL ES. He vuelto a buscar en Google sobre este problema, pero no he encontrado ninguna solución. Así pues:

- Podría ser fallo de la librería GLUT|ES, lo cual es malo pero no desastroso porque en su defecto podría utilizar las llamadas similares que implementa la Vincent 3D, pero comencé a usar GLUT precisamente para evitar usarlas, así que no me habría valido de nada el cambio, y además con las Vincent 3D funciona bien.

- Podría ser fallo de la librería Hybrid Rasteroid, lo que es también malo, porque justamente las he probado como alternativa a la Vicent 3D por el problema que parece que tiene al pintar polígonos.

- Podría ser problema de la combinación GLUT+Hybrid, aunque teóricamente se han probado el buen funcionamiento de ambas a la vez.

Una solución un tanto chapucera que habría que probar para ver si funciona sería tratar de utilizar ambas librerías a la vez, la Vincent y la Rasteroid, y de la primera utilziar las funciones de acceso a las ventanas y al teclado y renderizar con la segunda.

O seguramente más sencillo y directo, utilzar un modelo cuya malla sea más simple y no tenga esos problemas, aunque no quedará tan bien.

Utilizando GLUT|ES

He modificado el código para que todo lo relacionado con la gestión de ventanas, teclado, ratón y alguna cosa más lo gestione la librería GLUT|ES en lugar de las funciones equivalentes que vienen con la librería Vincent 3D.

La razón es que GLUT es la forma "estándar" de manejar esas partes del entorno que se suele utilizar en OpenGL. De esta manera si se diera el caso se podrá usar otra librería diferente a la Vincent 3D sin tener que preocuparse porque deje de funcionar, por ejemplo, el teclado.

Esta modificación ha sido algo problemática, no tanto por cambiar las funciones de manejo del teclado y las ventanas (que tienen nombre similares y parámetros parecidos) como por la preparación del entorno de programación. Una vez más la web de ZeusCMD ha sido de enorme ayuda, ya que la página de la versión oficial de la librería GLUT|ES no es nada clara en cuanto al proceso de instalación (sobre todo en lo referente al uso del emulador) e incluso en algunas circunstancias se producen errores al compilar. Gracias a la labor de los usuarios de ZeusCMD he podido instalar y utilizar una versión modificada que funciona correctamente con el entorno de programación y el emulador.

Problema con los polígonos (III)

Sospecho que el problema puede ser de la librería que utilizo para programar en OpenGL ES, la "Vincent Mobile 3D Rendering Library". Es muy raro que los polígonos que no se pintan correctamente no sean siempre los miesmos y que solo lo hagan según el ángulo en que se gira el modelo. Si fuera problema del cálculo de las normales o de los triángulos que forman los polígonos cabe pensar que se verían mal siempre los mismos, y en cualquier posición. La forma ideal de comprobarlo sería utilizar otra librería alternativa, o solo como prueba usar la especificación completa de OpenGL (la que no es especial para dispositivos móviles).

Antes de eso, he estado mirando en los foros de la página de desarrollo de la librería Vincent Mobile, y he encontrado como segunda entrada del foro este comentario sin respuesta:

(...) right now i am runing a example on ZeusCMD using viccnet lib.
it address: http://www.zeuscmd.com/tutorials/opengles/22-Fog.php
it runs ok at v0.84 lib. but there are "white-noise" at the dege when the object rotate.
by the way,i used ppc emulator 2003. libGLES_CM.dll is directly copied from binary version.

He probado el ejemplo mencionado de la página de ZeusCMD y me sucede lo mismo, al girar el cubo se ve aparecer el ruido blanco que se menciona en el foro, pero solo sucede con la versión 1.0 de la librería; si se usa una algo más antigua (la 0.84) el cubo se muestra correctamente. Lo que he hecho a continuación es probar el avatar usando esa versión vieja de la librería, para ver que pasaba. El resultado es que el modelo sigue sin verse bien, incluso son más los polígonos que se pintan incorrectamente, también arbitrariamente según se gira el objeto.

Conclusión: Es un problema de la librería.

Opciones que tengo:

- Utilizar otra librería diferente, por ejemplo la "Hybrid's Rasteroid", que es una implementación comercial de OpenGL ES, que se puede utilizar de forma gratuita si no es con fines comerciales. El problema es que tendré que reconfigurar el entorno de desarrollo para utilizarla en lugar de la Vincent, y tendré que incorporar al programa otra librería, la GLUT-ES. Esta sirve para tareas auxiliares como creación de ventanas y captura del teclado y el ratón. Hasta ahora estaba usando funciones propias de la Vincent que se ocupaban de esas tareas, pero si la sustituyo ya no valdrán.

- La otra opción es ignorar por el momento el problema, seguir trabajando con un modelo más simple esperando que no pase lo mismo, y centrarme en el resto de aspectos del avatar, como la animación o el comportamiento.

Problema con los polígonos (II)

Sigo con el problema que hace que no todos los polígonos se pinten correctamente, dejando huecos a través de los que se ven lo que hay detrás. En el caso del modelo con el que estoy trabajando casi da miedo, porque en la zona de la boca falla especialmente y según cómo se gira se puede ver toda la cabeza y el rostro correctamente, en la zona de la mandíbula toda la hilera de dientes, como una calavera.

He estado probando la solución que se me ocurrio en la entrada anterior, pero no ha funcionado. La idea era multiplicar todos los puntos por un factor fijo para que estuviesen más alejados entre sí y que no se solaparan unos con otros al hacer los cálculos, pero no ha resultado.

Primero he probado con la transformación de escalado, dando el mismo valor en los tres ejes, y no se han notado mejoras. Después he modificado la función que lée el modelo del fichero 3DS y según leía las coordenadas de los vértices las multiplicaba por ese valor fijo, pero tampoco ha mejorado, incluso creo que ha empeorado.

Además de hacer las operaciones anteriores también he tenido que modificar la posición de la cámara (alejándola) y ampliar el espacio del escenario alejando más los planos que lo delimitan, ya que al multiplicar las coordenadas aumentaba también el tamaño del objeto, hasta que se salía de la pantalla.

Parece pues claro que no es problema de que los vértices estén demasiado juntos, o de que las normales estén mal calculadas, ya que los polígonos que no se dibujan no son siempre los mismos, sino que varían según el ángulo en que se rota el modelo. Tendré que pensar en otra solución...

Problema con los polígonos

En la entrada anterior se quedó pendiente un problema al pintar los polígonos del modelo que ya había surgido en la representación con color plano pero que al aplicarle la textura se hace mucho más evidente. Cuando se gira la figura en la pantalla alrededor de cualquier eje en algunos momentos hay polígonos que no se pintan, dejando entonces ver los que hay detrás de ellos, cosa que no debería ser así.

He estado toda la tarde mirando y probando funciones de OpenGL-ES que controlan el culling y el depth-buffer. Lo primero sirve para evitar que se calculen los polígonos que no se van a ver en la pantalla (por ejemplo, los que quedan en la parte de atras de la cabeza) para que el proceso de representación sea más rápido. Pensé que quizás en alguno de ellos se calculaba mal la normal y por eso unas veces se pintaban y otras no, pero no era nada de eso. El depth-buffer es la representación interna que utiliza la librería para saber que objetos están delante de otros y cuales hay que pintar o cuales no. Tampoco solucioné nada mirándolo por ahí.

Casi al final se me ocurrió otra cosa. Observé que eso solo ocurre en las zonas en la que hay varias 'capas' de objetos, o que los polígonos están muy juntos, como por ejemplo: La boca y los dientes que están dentro; o los globos oculares y las cuencas que los rodean. Seguramente al estar en esos sitios los puntos muy juntos si los cálculos no son suficientemente precisos (y podrían no serlo, algunos dispositivos usan aritmética de coma fija en lugar de flotante) puede dar como resultado que los que están más atrás se solapen con los de más adelante.

Para solucionarlo, se podría multiplicar las coordenadas de los puntos por un factor fijo y de esa forma estarían más alejados unos de otros. Eso se puede hacer de forma muy sencilla con la transformación de cambio de escala glScalef y valores apropiados. Hice una prueba rápida y, efectivamente el efecto desapareció casi completamente, aunque con el lógico resultado de que el modelo no cabía en la pantalla. Es necesario hacer algo para que entre todo en el campo visual, como alejar el punto donde se sitúa la cámara, o similar.

Representación con textura

Para pintar la textura es necesario asignar a cada vértice del modelo un punto de la textura, y de esa forma se aplica como se haría si se "empapelara" la jaula de alambre 3D con un papel pintado en 2D.

La información sobre las coordenadas de los puntos de la textura asociados a los vértices está contenida en el fichero .3DS, y es leída de él al cargar el modelo. Además de ello es necesario también cargar la imagen de la textura desde un fichero gráfico. En la página de ZeusCMD hay un tutorial sobre cómo hacerlo.

En él se explica además como sortear un pequeño problema que ya había tenido, que es el de las rutas absolutas de los ficheros. En el Windows Mobile/PocketPC si no se especifica la ruta completa del fichero que se quiere abrir toma por defecto el directorio raiz (/) en lugar de aquel en que reside el ejecutable, que es un comportamiento totalmente distinto al que estamos acostumbrados en otros sistemas. Lo que hay que hacer es tomar la ruta completa del fichero ejecutable (el parámetro argv[0] de la función main de C) y de ahí extraer el nombre del directorio, para luego ponerlo delante de cualquier otro archivo que se abra a partir de ese momento. Esto todavía no lo he implementado en mi programa, pero lo haré próximamente, de momento los fichero que necesita abrir (el .3DS del modelo, el .BMP de la textura, y el log) se guardan en el raiz, lo que es ciertamente poco limpio.

Después de incorporar la textura, el modelo queda así, mucho mejor:

Hay sin embargo algo que no está bien del todo, según cómo se gira el modelo hay polígonos que no se pintan bien. Esto ya lo había notado al hacer la representación con color plano y sombreado, pero es mucho más evidente al ponerle la textura:



A parte de que, según he visto ahora al poner aquí las fotos, se ve muy oscuro, hace falta más luz.

De ambas cosas me ocuparé en la próxima sesión de trabajo.

Sobre el uso de código ajeno

En lo que llevo hecho de proyecto estoy usando código básicamente de dos sitios: La página ZeusCMD y la de Spacesimulator. El objetivo es explorar las posibilidades y posibles inconvenientes de desarrollar avatares con gráficos avanzados en 3D para dispositivos móviles como teléfonos. Al tratarse de un trabajo con fines educativos (lo estoy haciendo en la Universidad) y sin ánimo de lucro (al menos inmediato) no estoy incumpliendo los términos de uso que hay en las mencionadas páginas.

Si el resultado fuese después utilizado por terceros para obtener un beneficio económico no podrían hacer uso del código fuente generado. Además, el mismo contiene las cabeceras originales de sus autores donde se indican su procedencia y términos de uso.

Tengo pensado cuando termine el trabajo enviar un correo de agradecimiento a los autores de ambas páginas por la gran ayuda que han supuesto, seguro que lo apreciarán.

Representación con color sombreado

Para representar el modelo con zonas de más o menos luminosidad según la incidencia de la luz (modelo de iluiminación de Gouraud) es necesario calcular las normales de los planos de los triángulos que forman la superficie del modelo.

De nuevo consultando los tutoriales de spacesimulator.net he encontrado un código en C muy bien documentado donde se hacen todas las operaciones necesarias. Lo he incorporado al programa y adaptado para que funcione con lo que ya tenía hecho, y el resultado ha sido el esperado; el busto tiene ahora apariencia de volumen.

Lo siguiente será aplicarle una textura para que quede todavía mejor, y después anirmalo.

Representación en color plano

Después de algún problema he conseguido por primera vez ver el modelo del avatar(una busto) representado en la pantalla del emulador.

El problema lo he tenido porque a la función glDrawElements que he utilizado para representarlo debía indicarle el tipo de dato de los indices de la lista de vértices de los polígonos. El tipo que le especificaba era GL_UNSIGNED_SHORT, pero el tipo que usaba el vector donde los almacenaba era int, por lo que cuando lo pintaba aparecía una forma que recordaba muy vagamente a una cabeza humana. En cuanto me he dado cuenta del fallo, simplemente cambiando el valor del tipo de los indices a unsigned short int se ha arreglado. Tras hacerlo, lo que ha aparecido en la pantalla sí que coincidía con lo que ya había visto con un visor de ficheros 3DS, solo que el color es totalmente liso, no hay sombras ni sensación de volumen. Para dárselo es necesario calcular las normales de los polígonos para que se pueda calcular el ángulo que forma el plano con respecto al punto de luz de la escena.

Limitaciones

En los últimos días he estado adaptando el código fuente de un cargador de ficheros 3DS para cargar el modelo del avatar. El fichero contiene la información de, entre otras cosas, las coordenadas de los puntos y de los polígonos que forman el modelo. Los primeros vienen como una lista de valores (x, y, z) y los segundos (que son triángulos) como una lista de referencias a los vértices que los forman.

Al hacer el programa que se ocupa de todas estas cuestiones me he encontrado con las primeras limitaciones que se esperaba surgieran en un proyecto de este tipo sobre un dispositivo de capacidades reducidas.

- La primera limitación es propiamente del entorno de desarrollo. En la función que carga el fichero 3DS se hace una llamada para averiguar el tamaño del mismo (filelength) que no está implementada en las librerías del Embedded Visual C++. Otras funciones similares tampoco funcionaban y he tenido que buscar otra forma de averiguar esa información utilizando solo funciones estándares.

- Algo similar me ha ocurrido con otra función de C, freopen, que quería utilizar para mandar la salida estándar a un fichero de texto de forma que pueda escribir en él mensajes de debug que me permitan saber qué está haciendo la aplicación cuando no se ve nada en la pantalla.

- Otra limitación ha sido de capacidad de proceso del dispositivo que utilizo para las pruebas (una PDA emulada). La función que carga el fichero 3DS escribe en la salida estándar cada chunk de información que va leyendo. Al ser muy numerosos el fichero de texto donde se iban escribiendo alcanzaba rápidamente un tamaño considerable para las prestaciones del aparato (más de 8 Mb). La solución en este caso fue simple, se limitó la información de salida a la estrictamente necesaria para saber si era o no correcto lo que se estaba leyendo.

- La otra limitación que he encontrado de momento es de la propia especificación de OpenGL-ES. Los tutoriales que estaba consultando para sabe cómo dibujar el modelo eran para la librería OpenGL original, y algunas funciones no existen en la versión para dispositivos móviles. Ejemplos de estas son glBegin, glEnd, o glVertex3f, que se usaban para construir los polígonos (triángulos) a partir de los vértices. En su lugar use otra función, glDrawElements, que también está disponible en OpenGL aunque parece que no es muy utilizada, a pesar de que es muy práctica ya que con una simple llamada se construyen todos los triángulos especificando únicamente una lista de vértices.

A raiz de lo que ocurrió en el último caso, he empezado a consultar la guía de referencia oficial de OpenGL-ES cada vez que tengo que usar una función nueva.

Malla del avatar

Me han pasado los datos de la malla del personaje/avatar, en formato .3ds y .max

He estado mirando ambos formatos por encima y el .3DS (de 3D Studio) parece más interesante para nuestros propósitos. He instalado un visor para ver qué aspecto tiene el avatar, y ahora lo siguiente será hacer un programa que cargue y visualice ficheros de este tipo en el dispositivo móvil. De momento basta con que carge el modelo de jaula de alambre; y después se hará lo propio con las texturas.

He encontrado varias páginas donde se explica con diverso grados de complejidad la estructura de este formato de fichero. Una de ellas que me ha gustado es la de tutoriales de Spacesimulator.net, contiene mucha información sobre gráficos, OpenGL y su aplicación a los videojuegos, explicado paso a paso en varias lecciones.

Por cierto, sobre librerías SAPI (conversión de texto a voz) para PocketPC y similares, no he encontrado nada, al menos que sea más o menos abierto.

Siguientes pasos

Después de estar aprendiendo unas semanas a programar con OpenGL-ES y el entorno de desarrollo del Embedded Visual C++ llega el momento de implementar algo. Se comenzará cargando una malla de un modelo no demasiado complejo y se comprobará si el dispositivo es capaz de moverlo con suficiente soltura (rotar, trasladar, etc).

Después, se estudiará la forma de animarlo para que hable, para lo cual será necesario también mirar si existe alguna librería tipo SAPI para dispositivos móviles.

Mobile Monday Barcelona: Juegos para el móvil

Mobile Monday Barcelona, el evento mensual sobre tecnologías móviles, se celebra este próximo lunes, 2 de abril y tratará sobre Juegos para el móvil. El evento tiene lugar en el Auditorio de la Universidad Pompeu Fabra, la asistencia es gratuita y hay sitio para unas 150 personas.

(Vía Microsiervos)

Reinstalando (V)

He instalado el Windows XP Professional en otra partición del disco de mi ordenador, y a continuación he hecho lo propio con el Embedded Visual C++ y el resto de componentes sobre los que ya escribí anteriormente.

Esta vez todo se ha instalado bien a la primera, sin dar ningún problema. Cuando he ido a instalar el Service Pack 4 del eVC he leído detenidamente los requisitios previos, y en una de las líneas decía:

Microsoft Windows® 2000 Professional SP2, Microsoft Window 2000 Server SP2, or Microsoft Windows XP Professional.

O sea, que es normal que no se instalara sobre Windows XP Home; eso me pasa por leer entre líneas en vez de con calma, aunque también podría haber puesto explícitamente que con la versión Home no funcionaría, en otros productos lo he visto.

A continuación he probado un ejemplo que ya intenté con el Visual Studio 2005, y esta vez ha funcionado correctamente al primer intento. Ahora podré empezar ya de una vez a mirar en profundidad la programación con OpenGL-ES.

Por cierto, me puedo responder a mi mismo a las preguntas que me hacía aquel día:

- ¿Uso el Visual Studio 2005 o el Embedded Visual C++?

El Embedded Visual C++, ahora está claro que con el VS 2005 no va a funcionar la librería.

- ¿Reinstalo el Windows de mi ordenador de casa, o uso el ordenador del trabajo?

Usar el ordenador del trabajo in situ tiene el inconveniente de que me puedo distraer fácilmente con cosas del propio trabajo. Intenté utilizarlo desde casa por Terminal Server, pero se producían constantemente microcortes que me impedían trabajar con comodidad. Finalmente he tenido que reinstalar Windows en el ordenador de casa.

Vincent Mobile y Visual Studio 2005

He estado buscando información y parece ser que "oficialmente" la librería solo ha sido probada en eVC 4.0 , y quizás en Visual Studio 2003, pero no el el 2005.

En este foro se dice que se ha conseguido compilar la librería para que funcione con VS 2005, y se proporciona un enlace para descargar los binarios. Lamentablemente está roto y no se pueden conseguir por esa vía.

Así que se si se quiere utilizar Visual Studio las opciones que veo que hay son:

1) Compilar la librería a partir de su código fuente. Aparentemente es complicado.
2) Descargar la ultima versión de desarrollo del CVS. La última estable disponible es de hace casi un año y se desconoce si va a salir alguna más.
3) Probar a utilizarla con Visual Studio 2003, pero tampoco es seguro que vaya a funcionar.
4) Olvidar el Visual Studio y utilizar el Embedded Visual C, que aunque sea más limitado que el VS es el entorno de desarrollo "oficial" de la librería y suficiente para este trabajo

Probando con Visual Studio 2005

He estado probando a compilar un programa sencillo que utilizase ya alguna función de OpenGL-ES. He ido siguiendo las indicaciones de la página de ZeusCMD, configurando las rutas a los ficheros de cabecera y de librerías.

Se puede hacer de dos formas: Una, es copiarlos a los directorios propios donde está instalado Visual Studio para que los encuentre al construir el programa. El inconveniente es que "ensucia" la instalación del programa.

La otra, por la que he optado, es configurar el proyecto para que busque cabeceras y librerías en los directorios adicionales indicados. Esta forma es más limpia que la anterior, pero más farragosa ya que para cada proyecto hay que volver a configurar las rutas.

Para hacerlo hay que ir al menú 'Tools' -> 'Options' -> 'Projects and Solutions' -> 'VC++ Directories'. Después, seleccionar en 'Platform PocketPC 2003 (ARMV4)' y 'Show directories for' 'Include files' y 'Library files'. Ahí se indicarán las rutas a los directorios de la Vincent Mobile 3D Library bin\ARM\Debug\ y include\.

Al compilar el programa salen unos errores en los que indica que no puede encontrar la función WinMainCRT. Después de buscar por Internet, parece que se debe a que en una aplicación windows la función main() del C 'de toda la vida' se llama así. Para cambiarla al valor habitual o a cualquier otro hay que ir a 'Project' -> 'Properties' -> 'Linker' -> 'Advanced' -> 'Entry point'. Después de eso ya se puede compilar el programa principal que hayamos hecho, que a continuación se enlazará con la librería.

El siguiente problema surge precisamente en ese paso. Al construir ('Build') el programa, después de compilar el fichero principal se ejecuta el linker, y aparecen cuatro líneas con errores que empiezan como la siguiente:

ug.lib(ug_win32.obj) : error LNK2019: unresolved external symbol

En 'Project' -> 'Properties' -> 'Linker' -> 'General' hay una opción para aumentar la cantidad de información que proporciona el linker mientras se ejecuta, y al observar la salida se ve que encuentra correctamente el fichero de librería ug.lib. Pruebo a cambiar las rutas para que tome otras librerías alternativas del mismo nombre, pero el resultado es el mismo.

¿Será que estas librerías están pensadas para ser usadas con eVC y el Visual Studio no las maneja bien?

Artículo del NYT sobre sistemas operativos en móviles

Visto en Barrapunto sobre un artículo del New York Times.

Según éste, el primero sería Symbian con un 66%, seguido por Windows Mobile con un 14% (algo menos que el año pasado), después BlackBerry con un 7% y a continuación Linux con un 6%.

Más o menos coincide con las cifras que obtuve cuando estuve buscando información sobre este tema (Symbian 67%, Windows 16% y Blackberry 7%).

Reinstalando (IV) y probando (II)

He instalado el eVC en mi ordenador del trabajo. Todo el proceso ha ido bien, se ha instalado todo correctamente a la primera sin que me haya encontrado con ninguno de los problemas que me aparecieron en el ordenador de casa. ¿Será por la versión del Windows XP (Home en casa y Professional en el trabajo? ¿Será porque tengo instalado algo que impiede que se instale como debería? ¿O será lo contrario, que no tengo instalado algún otro componente necesario?

Bien, después de instalar el eVC, he hecho lo propio con el SP4 y el kit de desarrollo para Pocket PC (los ficheros necesarios para que en el primero se puedan desarrollar aplicaciones específicas para Pocket PC, y no solo para el genérico Windows CE).

He creado un nuevo proyecto del tipo "Hola mundo" y bien, ha funcionado, ha compilado a la primera y se ha ejecutado en el emulador.

Luego he descargado la librería Vincent Mobile y le he intentado con uno de los ejemplos (samples) que trae. Esto ha costado un poco más, es necesario copiar varios ficheros de cabecera y librerías en los directorios donde está instalado el eVC, así como una dll que ha de copiarse en el propio dispostivo (PDA, Smartphone, o emulador).

Después de varias tentativas, finalmente lo he conseguido. Ha sido necesario copiar la DLL en la misma carpeta donde se generaban los binarios, porque copiándola en el directorio de Windows de la PDA no la encontraba. Después de hacer eso, he punteado en el fichero con extensión .exe y se ha abierto correctamente, mostrándome un cubo visto desde una de sus caras.

Para hacerlo funcionar me ha sido de mucha ayuda esta página que ya mencioné en otro post y que he añadido a los links de interés.

Ahora tengo varias dudas de ordén práctico:
- ¿Uso el Visual Studio 2005 o el Embedded Visual C++?
- ¿Reinstalo el Windows de mi ordenador de casa, o uso el ordenador del trabajo?

Continuará...

Utilizando Visual Studio 2005

No he tenido ocasión de instalar el eVC en otro ordenador, así que continúo trasteando con Visual Studio 2005. Se me hace cuesta arriba porque en los últimos años apenas he programado (me dedico a administrar redes y sistemas) y lo poco que he hecho ha sido bajo Linux con las herramientas de GNU (gcc, make, y editores de texto como el kate de KDE).

La primera impresión es que el entorno está un poco sobrecargado: hay "muchas" ventanas, con muchas opciones, y muchos botones, y la mitad de lo que pone en ellos no se lo que es. Además, no conozco la jerarquía de clases de Visual C++ ni de Windows. Así pues, decido empezar leyendo ayudas y modificando la aplicación de prueba que mostraba una ventana vacía con dos menús, para que haga "algo" más, por ejemplo mostrar un sencillo msgBox con alguna cadena.

Empiezo leyendo la ayuda, comenzando por algunos conceptos de C++ para refrescar la memoria. Después comienzo a mirar el código, y marco varias palabras clave para que la ayuda me diga para que sirven. Después de estar varios minutos consultándola y cambiando algunas líneas de código, no consigo progresar mucho.

Paso a buscar ejemplos en Google, y sigo haciendo más pruebas, hasta que finalmente consigo mostrar el cuadro de diálogo en la ventana vacía que corre en el emulador.

Conclusión: El sistema de ayuda puede que esté bien como referencia, pero como tutorial para iniciarse no sirve, es mejor recurrir a internet.

Reinstalando (III) y probando

Después de reinstalar el último día el Visual Studio 2005 procedo a instalarle el Service Pack 1 que ya había descargado en una ocasión anterior. Son 400 Mb, y le cuesta un buen rato, pero finalmente termina el proceso.

Después de eso uso un programa para limpiar el registro de Windows, reinicio, y reinstalo el Embedded Visual C++ 4.0. Cuando termina el proceso, lo ejecuto, y sigue saliendo el error de que no hay ninguna plataforma disponible. Pruebo de nuevo a instalarle el SP4, y tal como ocurrió la última vez me aparece el error de problemas con el ODBC. Lo dejo por imposible, y me pongo a mirar el Visual Studio. Los ejemplos que he visto por internet sobre el uso de la librería de OpenGL están todos pensados para ser usados desde eVC, así que cuando me ponga con ello seguramente lo pasaré un poco mal. Como último intento, copio los ficheros de instalación en una memoria USB con la intención de instalarlo en otro ordenador, uno del sitio donde trabajo, porque en casa no tengo más.

Abro el Visual Studio 2005 y creo un proyecto utilizando la plantilla "Win32 Smart Device Project". Le indico que utilice la plataforma "Pocket PC 2003" y que el tipo de aplicación a crear es "Windows application". Genera los ficheros necesarios y compruebo que se ejecuta lanzando el emulador (todo esto es lo que ya había hecho la vez anterior).

Miro el código, y viéndolo en general me hago una somera idea de lo que hace, pero entrando en detalles (llamadas a funciones, tipos, macros, constantes, clases) no entiendo nada. Pruebo un poco el sistema de ayuda: Seleccionando una palabra y pulsando F1 muestra información sobre ella si hay disponible (por ejemplo, si es una función de librería de las que vienen con VS). Pruebo también el debugger, poniendo algún punto de ruptura y cuando llega a él comprobando el valor que toman las variables, y continuándo la ejecución presionando repetidamente la tecla F5 hasta que se alcanza el siguiente punto.

Reinstalando (II)

Continúo reinstalando las herramientas de desarrollo.

Antes de reintentarlo hago de nuevo limpieza en el disco duro hasta dejar libres 2,4 Gb.

Inicio de nuevo la instalación de Visual Studio 2005, y voy siguiendo los mismos pasos que en la anterior ocasión. Llego hasta la barra de progreso del registro de componentes que puede tardar varias horas. De nuevo mientras ceno lo dejo trabajando y cuando vuelvo esta vez sí ha terminado con éxito. ¿Era pués cuestión de espacio? ¿Y por qué no avisó el instalador la vez anterior?

Lanzo la aplicación, y creo un proyecto del tipo "Win32 Smart Device Application", y al contrario que en la ocasión anterior, esta vez funciona. En las siguientes ventanas del asistente le indico que quiero hacer una aplicación para Pocket PC 2003 y que sea con una ventana vacia. Genera algunos ficheros de código, y le doy al botón de ejecutar. Al hacerlo compila el programa, y lanza el emulador. En la ventana aparece una imagen de una PDA y esta vez puede verse corriendo en ella el Pocket PC, y unos segundos después la aplicación que acabo de crear, que es una ventana en blanco con un botón de OK y otro de Help.

Reinstalando

He estado toda la tarde reinstalando los distintos componentes del entorno de desarrollo que ya mencioné en un post anterior.

Primero he tenido que liberar espacio de disco, me quedaban libres unos 600 Mb y no eran suficientes para descomprimir y luego instalar el Visual Embedded C++ 4.0 (eVC). Parece ser que no calcula muy bien a priori el espacio necesario para instalarlo y no se ha dado cuenta hasta que ha fallado porque se había quedado sin sitio.

He vuelto a iniciar la instalación pero diciéndole que descomprimiera los ficheros en un directorio de otra partición donde tengo más sitio (D:) y también le he cambiado los directorios de instalación para que lo haga en esa unidad de disco. Antes de instalar el entorno en sí me dice que no está instalado el "Platform Manager" y que va a proceder a hacerlo. Aparece la barra de progreso y al poco rato falla, y se interrumpe también la instalación original del eVC.

Me las arreglo para instalar de forma independiente el dichoso Platform Manager, entrando en las carpetas descomprimidas en el directorio temporal por eVC y ejecutando un fichero con extensión .msi (Microsoft Installer) en lugar del setup.exe que hay. Finalmente se instala.

Vuelvo a iniciar la instalación del eVC y esta vez termina bien. Lo ejecuto para probarlo, y me aparece el error de que no hay ninguna plataforma disponible y que seguramente se debe a que su carga falló durante la instalación (¿?).

Desinstalo, reinicio, y vuelvo a repetir todo el proceso anterior. Mismo resultado al ejecutar el entorno. Decido ignorarlo e instalar el Service Pack 4, esperando que con un poco de suerte machacará algún fichero que se haya instalado incorrectamente y solucionando así el problema. Aparece la barra de progreso, copia todos los ficheros, y cerca del final comienza a registrarlos. Entonces aparece una ventana de error, en la que dice que tiene un problema con los contraladores ODBC y algo relacionado con SQL, y que no se puede continuar.


La barra de progreso se mueve hacia atrás y se deshace todo lo que el programa de instalación había hecho. La instalación se ha abortado, y el eVC sigue dando el mismo error que daba al principio.

Decido dejar pues de momento la instalación del eVC y lo intento con el Visual Studio 2005. Pongo el DVD en la unidad e inicio el proceso. Selecciono los componentes a instalar y empiezan a copiarse. La barra de progreso va avanzando entre el ensordecedor ruido de la unidad de DVD girando a toda velocidad, hasta que termina la copia. El ruido cesa y aparece otra barra como la anterior mientras se registran diversos componentes del sistema, proceso que puede durar unos minutos o varias horas según reza el cartel. La barra va progresando lentamente hasta faltarle un trocito para el final, y en ese momento parece dejar de avanzar. Se hace la hora de cenar y lo dejo para que termine.

Cuando vuelvo más de una hora después, sigue exactamente en el mismo punto, no ha avanzado nada. Lo dejo un rato más, pero parece claro que no va a seguir progresando. El resto del sistema funciona bien, y en el task manager del Windows la aplicación no aparece como "bloqueada". Es extraño, le doy a cancelar e interrumpo el proceso.

Resultado: eVC instalado, pero no funciona y no se instala su service pack. Visual Studio 2005 no se puede instalar tampoco. Cuando instalé todas estas aplicaciones en la máquina virtual con la que inicié las pruebas no tuve ni un solo problema, y ahora que lo estoy haciendo sobre un PC real, no paran de surgir ¿qué estaré haciendo mal?

Virtualizar no funciona

Sospecho que la razón de todos los problemas pueda ser que estoy usando los entornos de desarrolo en una máquina virtual con VMWare. Eso de correr un emulador (el de PocketPC) dentro de otro emulador (VMWare) la verdad es que no suena muy bien.

Tras una rápida búsqueda por internet confirmo lo que me temía en esta página:

Emulator does not run on VMware

Visual Studio .NET 2003 does not support running the emulator in a VMware™ session.

Así que está claro, todo lo que he estado probando hasta ahora ha sido tiempo perdido. El siguiente paso será instalar de nuevo todas las herramientas en un Windows XP corriendo en un PC real.

Siguen las pruebas con Visual ...

Se me ocurre que quizás no haya tenido éxito en las primeras pruebas con los entornos de desarrollo por pensar "a la antigua usanza", es decir, suponer que un programa como el de "Hola mundo" funcionará mostrando el mensaje en una ventana tipo consola o similar. Seguramente no será así.

Decido saltarme ese paso y meterme de lleno a hacer pruebas con la librería de OpenGL-ES que nos habían mostrado anteriormente. Me descargo la librería Vicent Mobile y la descomprimo, pero no se muy bien qué hacer con ella. Bueno, sí lo se, tengo que incluir en el programa principal las cabeceras de la librería y decirle al compilador y al linker que la utilice cuando construya el programa, pero no se cómo hacerlo. Busco por internet y me encuentro esta página donde se explica cómo configurar el entorno para trabajar.

Hago lo que indica la página, que utiliza como entorno el Embedded Visual C++ 4.0 y tras varios intentos consigo compilar un programa de test, pero me sucede lo mismo que en las primeras pruebas, que al lanzar el emulador para probarlo se queda con la pantalla negra hasta que vence el tiempo.

Intento hacer algo equivalente con el Visual Studio 2005, pero por más que lo intento me resulta imposible, siempre termino con errores muy extraños o con el conocido pero no por ello menos frustrante "Must define a target architecture".

Artículo: A 3D Character Animation Engine for Multimodal Interaction on Mobile Devices

Resumén esquemático del artículo A 3D Character Animation Engine for Multimodal Interaction on Mobile Devices.

El artículo trata de la implementación de un motor para representar animaciones en un teléfono móvil. Al ser del año 2005 el trabajo no se utilizó el estándar OpenGL-ES, sino que se programó un sistema de representación en 3D partiendo de cero, sobre plataforma Symbian.

Lo más interesante de lo que habla es sobre una desconocida parte del estándar de animación MPEG4 (el que se usa en los vídeos DivX) que se centra en la animación de caras o bustos parlantes. Se parte de tres nociones básicas:

• Feature Points (FP): Son una serie de puntos clave de la cara para hacer gestos, como el centro de los ojos, los bordes de los labios y de las cejas, la punta de la nariz y de la barbilla, y así hasta 84.


• Rostro neutral: Es una cara de referencia, a partir de la que se describen los movimientos de los diferentes elementos. En el rostro neutral la boca está cerrada, la mirada dirigida perpendicular al plano de la pantaya, y las cejas perpendiculares al iris.


• Facial Animation Parameteres (FAP): Son los responsables de describir los movimientos básicos de la cara, tanto a bajo como a alto nivel. El estándar define 66 de bajo nivel y 2 de alto nivel.
  

A partir de estos tres elementos, se puede describir cualquier animación de la expresión de la cara especificando mediante los FAP los movimientos respecto a la cara neutral. Se pueden encadenar muchas de estas variaciones en un flujo que puede transmitirse haciendo un uso muy eficiente del ancho de banda. Al ser los puntos de referencia independientes del modelo de la cara, una misma animación puede servir para distintos personajes sintéticos.


La siguiente parte del artículo habla sobre la estructura interna del motor de animación, que básicamente viene a ser un decodificador de flujos FAP, dividido en varios bloques o módulos encargados de calcular la animación de la malla del modelo, representarla en pantalla y sincronizarla con el flujo de datos de audio.


A continuación en el artículo se hacen varias medidas de renidimiento, midiendo en distintos modelos de teléfono móvil el número de FPS conseguidos para modelos de varias complejidades (número de polígonos).


Para terminar, se propone una aplicación para el motor, que es un lector animado de mensajes SMS. El servidor que lo recibe decodificaría el texto en audio y en los gestos de la cara al pronunciarlo, y generaría un mensaje multimedia (MMS) con la animación completa.

Primeras pruebas con Visual Studio 2005

Como el Embedded Visual C++ me dió problemas (no se lanzaba el emulador de PocketPC) decido probar el Visual Studio 2005.

Nada más lanzarlo ya se nota que es menos espartano que el otro entorno, con ventanas más bonitas, asistentes e información actualizada que se descarga de internet.

Comienzo probando a hacer el primer programa de C que se hace siempre. Creo un nuevo fichero de tipo "C++ source" y escribo el típico:

#include

void main()
{
printf("Hola mundo\n");
}

Lo construyo, y me aparece un error:

Fatal error C1189: #error: Must define a target architecture. File: winnt.h. Line: 648

Comienzo a probar combinaciones de "Platform Solution" (PocketPC 2003 ARMV4, Smartphone 2003 ARMV4, Win32), "Target Device" (PocketPC 2003 SE Emulator, PocketPC 2003 SE Emulator VGA, y otros similares) y el "Configuration Manager". Me siguen saliendo errores similares, e incluso cuando pretendo construirlo como una aplicación Win32 aparecen extraños mensajes de que faltan símbolos en algunos ficheros de cabecera .h

Busco por internet, y encuentro algunas posibles soluciones, que pasan por poner #includes e #ifdefs también muy extraños y para nada intuitivos. Ninguna de ellas funciona.

Finalmente leo en varios sitios que lo de empezar con fichero sueltos no es muy buena idea, lo que hay que hacer es iniciar un nuevo proyecto del tipo "Smart Device Application". Así lo intento hacer, pero cuando elijo esa opción y le doy un nuevo nombre al proyecto, se queda todo el entorno como "parado" durante un par de segundos, y luego vuelve a la ventana donde se seleccionaba el tipo de proyecto. O sea, ¡¡¡está funcionando mal!!!

Me descargo de la web de Microsoft el Service Pack 1 para el visual Studio 2005 y lo instalo. El problema persiste, no soy capaz de crear un nuevo proyecto para dispositivos móviles :-(

Primeras pruebas con Embedded Visual C++

Las primeras pruebas no han dado muy buen resultado. Lo primero que he tratado de hacer es el típico programa que escriba "Hola mundo". Para ello creo un proyecto nuevo, selecciono que sea del tipo "aplicación para Pocket PC 2003", y que va a ser un ejemplo de programa que muestre "Hola mundo". Me crea el proyecto con unos cuantos ficheros con el código fuente, cabeceras y recursos. Elijo que la plataforma de destino sea el emulador de PocketPC 2003 y por fin voy al menú "Build" y le digo que contruya todo el proyecto. Lo compila bien todo y lanza el emulador para ejecutar el resultado. Aparece una ventana con una barra de progreso en la que pone que se está conectando con el dispositivo y otra ventana con una imagen de una PDA. La barra se va rellenando, y la pantalla de la PDA del emulador permanece en negro, no aparece nada, ni un error ni el sistema de la PDA ni ninguna ventana dentro de la del emulador. Finalmente, tras rellenarse 3 o 4 veces la barra de progreso se cierra, junto con la ventana del emulador y aparece un mensaje en la ventana de debug del compilador, que dice que hay un timeout y que no se ha podido conectar con el dispositivo.

Pruebo con otros tipos de proyectos de ejemplo más sencillos, e incluso hago uno programa en C sencillo, pero sin éxito, o se queda el emulador parado como he descrito o empiezan a salir errores extraños del compilador.

El próximo día probaré con el Visual Studio 2005 a ver si va mejor. Por ser este de pago y el Embedded Visual C++ gratuito, quizás esté más trabajado y funcione mejor.

Instalación de herramientas de desarrollo

Las herramientas que se van a utilizar son estas, y han de instalarse en este orden:

1. Embedded Visual C++ 4.0. Producto gratuito, descargable desde aquí.
2. Embedded Visual C++ 4.0 Service Pack 4. Parches para el anterior, descargables desde aquí.
3. PocketPC 2003 SDK. Kit de desarrollo para plataformas PocketPC, gratuito y descargable desde este link.
   
4. Optativo: Visual Studio 2005. Entorno de programación de Microsoft, no es gratis, es necesaria una suscripción al MSDN.

Esto son "solo" los compiladores de C/C++ y utilidades para el desarrollo, como emuladores y documentación. Sería necesario además añadir luego las librerías de OpenGL-ES que se vayan a utilizar, como la Vincent Mobile 3D Rendering Library de la que se habló en un post anterior.

De momento se van a hacer programas de prueba sencillos para familiarizarse con el entorno, pues nunca he trabajado con él y no se cómo funciona. Se ha hecho la instalación en una máquina virtual con VMWare para poder usarla desde el S.O. que utilizo habitualmente, y tambén para en un momento dado llevármela en un disco duro externo a otro ordenador si fuera necesario.

Links sobre OpenGL-ES y videojuegos 3D en teléfonos móviles

Una vez que se ha decidido utilizar el estándar OpenGL-ES para la programación del avatar, se buscan ejemplos de juegos y otros desarrollos para ver qué se ha hecho ya y saber un poco más acerca de sus posibilidades:

Videojuegos y OpenGL-ES

- Presentación de ATI en la Game Developers Conference. Resumen de características de OpenGL-ES 2.0. http://ati.amd.com/developer/gdc/2006/GDCMobile2006-Ginsburg-OpenGLES2.0.pdf Esta conferencia internacional cuenta con un apartado dedicado en exclusiva al desarrollo de juegos sobre teléfonos móviles. Además de la presentación anterior, es posible descargarse las actas (proceedings) de años anteriores.

- El grupo Khronos tiene una web con recursos para desarrolladores de OpenGL-ES. En ella hay tutoriales, documentación, kits de desarrollo, librerías, utilidades, etc. http://www.khronos.org/developers/resources/opengles/

- Mobile 3D World (http://www.mobile3dworld.com ). Portal dedicado a juegos 3D para móviles. Parece recien creado y no tiene mucha información, salvo un artículo sobre "10 tendencias en juegos móviles para el 2007" (la número 7 se refiere a juegos 3D): http://www.mobile3dworld.com/News/tabid/52/articleType/ArticleView/articleId/40/10mobilegamestrendsfor2007.aspx

- Entrada en un blog acerca de la aceleración en teléfonos móviles. Se mencionan varios juegos que usan OpenGL-ES (Splinter Cell, Quake, Need for Speed) y hay capturas de pantalla de los mismos. Incluye también una comparativa entre prestaciones de los chips aceleradores de NVIDIA y ATI. http://blog.aldeabit.com/2006-01-18/procesadores-3d-en-celulares

- En este foro se menciona que se está desarrollando un programa de benchmark para medir el rendimiento de OpenGL-ES en un dispositivo. http://pocketmatrix.com/forums/viewtopic.php?p=246425#246425

- Página cuasioficial de benchmarks de OpenGL-ES. Incluye lista de dispositivos disponibles comercialmente y sus puntuaciones. Se puede descargar previo registro gratuito. http://www.glbenchmark.com/index.jsp

- La consola PlayStation 3 implementa una versión ligeramente modificada de OpenGL-ES 1.0 que es casi la 2.0. http://www.noulakaz.net/weblog/2006/11/11/sony-playstation-3-released-in-japan

Desarrollo con OpenGL-ES

- Working Girl: 3D graphics. Parece ser el diario de un proyecto de programación en 3D que incluye móviles. Son Symbian, pero cuenta cosas interesantes que pueden servir. http://raeeka.blogspot.com/

- Entrada en un blog de un estudiante de Valladolid, que parece haber utilizado OpenGL-ES en su PFC. Contiene algunas reflexiones interesantes. http://blep.blogspot.com/2006/03/opengles.html

- Página sobre un curso de desarrollo con OpenGL-ES realizado en el SigGraph 2005. Contiene información sobre entornos, librerías, y herramientas. http://people.csail.mit.edu/kapu/siggraph_course/

- Yeti-3D. Librería para programar juegos con OpenGL-ES. Disponible para varias plataformas, con y sin aceleración. http://www.intuitex.com/yeti.html

- Mobiola 3D. Motor gráfico para crear juegos 3D, que implementa física, gráficos y sonidos. Necesita OpenGL-ES o Direct3D. En la página hay varios juegos que lo utilizan (simuladores de vuelo). http://www.warelex.com/games/engine.php

Ejemplos de videojuegos 3D programados con OpenGL-ES

- DoomGLES, el famoso Doom para PocketPC usando OpenGL-ES. En fase de desarrollo, hay también disponible otra versión no 3D que utliza la técnica del juego original para simularla (ray-casting). http://kokak.free.fr/DoomGLES.htm

- Quake III Arena programado con OpenGL-ES, corriendo en un teléfono Nokia N93 (uno de los primeros con aceleración gráfica) y en una PDA Dell Axim X51 (la primera en incluir aceleración gráfica). Incluye algunas capturas de pantalla. http://www.symbian-freak.com/news/006/12/quake3_n93.htm

- 3D Chopper Fight. Juego para PocketPC de simulación de helicopteros de radio control, que puede usar aceleración con OpenGL y Direct3D. http://www.omnigsoft.com/products/2005/ChopperFight/ChopperFight.html

- Jackpot Casino. Juego de casinos que puede utilizar la aceleración 3D de la Dell Axim X51. No menciona que utilice OpenGL-ES, pero parece probable al estar disponible para varias plataforms (PocketPC, Windows Mobile, Palm OS). http://www.mobile-stream.com/casino.html

- Emulador de la consola SNES para PocketPC que dispone de una versión para la PDA Dell Axim X51, con OpenGL-ES. http://leggnet.com/emulamer/

Videojuegos 3D que no usan OpenGL-ES

- CyberSarus. Motor 3D con efectos de iluminación; se puede ver en 'apaisado' en pantallas de 320x480; motor de audio 3D; enemigos con inteligencia artificial. http://www.darksungames.net/cbs.htm

- Head2Head racing. Simulador de coches 3D, que incluye física para controlar la suspensión y dirección del coche. Disponible para varios teléfonos (Nokia, Motorola, Palm) y resoluciones de pantalla. http://www.darksungames.net/h2h.htm

- Oval Racer. Otro simulador de carreras, con varios coches que corren al mismo tiempo con IA, física, y varias cámaras y posibilidad de cambiar el nivel de detalle. En la página hay un vídeo de demostración. http://www.oval-racer.com/index.html

Otros

- Visualización de datos en dispositivos móviles con aceleración gráfica. http://mobile.sdsc.edu