Parálisis de análisis

Al empezar cualquier proyecto, lo primero que se busca es «ver algo». Uno empieza a teclear código como loco, hace algo que «medio funciona» (o no), y luego se da cuenta que no puede mantenerlo y lo tira a la basura (o lo rediseña desde cero). Para evitar esta tentación, lo mejor es empezar por donde se debe: un buen análisis de las necesidades y la arquitectura de la aplicación.

Pero refugiarse en el análisis tiene justo el peligro opuesto: uno se puede quedar bloqueado tratando de determinar cuál es la mejor arquitectura para la aplicación, cuáles las mejores librerías, o incluso tratando de determinar si lo que se pretende hacer es siquiera posible… y así, dejar pasar el tiempo sin decidirse a comenzar. Es lo que se llama «parálisis del análisis«, y es lo que me temo que estoy padeciendo yo.

Así que para desbloquear esta situación, elegiré una dirección y empezaré a moverme, aun a riesgo de tener que desandar todo lo andado después. Voy a escoger la librería ChefX3D (de la que ya he hablado aquí anteriormente) porque proporciona un soporte bastante completo para la edición (está pensada para eso), y voy a intentar añadirle la única característica que le falta: la edición directa en la ventana de 3D, que actualmente sólo se usa para previsualizar el resultado. Procuraré también establecer unos objetivos concretos y una planificación algo más detallada de lo que he venido utilizando hasta aquí, ahora que hay un objetivo y una meta concreta que cumplir. Espero que no sea demasiado tarde… :S

Decisión crucial

Aunque lo parezca, no se trata del nombre de la última película del forzudo de turno, ni del telefilme «basado en hechos reales» del domingo. Se trata más bien de cuestionarse algo que he tenido claro desde el principio: el uso de Xj3D como base de la arquitectura. Últimamente he estado concentrado en tratar de retocarlo a mi gusto, sin pensar que quizá ni siquiera con esos retoques se adapte a lo que necesito… por eso, los siguientes pasos deben consistir en hacer una prueba sencilla de manejo del conjunto Xj3D + SAI, y en hacer la misma prueba sencilla con otras librerías, como CyberX3d. Esta otra alternativa podría suponer más trabajo, pero quizá sea más sencillo de hacer que modificar Xj3D. Eso es lo que voy a intentar averiguar.

Posibles nuevos nodos

En el post anterior proponía dos nuevos nodos de Xj3D para exponer la funcionalidad necesaria del núcleo de Xj3D a un editor: un nodo que permitiera saber en qué posición y con qué orientación se encuentra el usuario, y qué objetos está apuntando con el cursor, para poderlos seleccionar.

Como la primera parte puede resolverse mediante un «truco» con un sensor de proximidad muy grande, y el tiempo sigue pasando, he considerado prioritario el segundo tipo de nodo: exponer las operaciones de picking que se realizan cuando se mueve el ratón mediante un nodo externo. Y me he encontrado con un problema de implementación: esas operaciones se hacen a nivel del componente que se esté utilizando para renderizar (que pueden ser varios en Xj3D, aunque ahora se use principalmente el motor OpenGL), pero esos nodos seleccionados a tan bajo nivel no tienen idea de a qué nodo de alto nivel (nodo X3D) corresponden. Actualmente, los nodos X3D sí saben a qué nodo de bajo nivel corresponden, pero no al revés, así que ando ahora estudiando la manera de implementar un enlace en el otro sentido. No parece cosa fácil…

Otra forma de NO hacer una bombilla (o un editor con Xj3D)

En el post anterior decía que para que un browser Xj3D pudiera ser utilizado para crear un editor hacían falta ciertos datos que, tal y como está, no se podían obtener fácilmente, a pesar de lo triviales que pudieran parecer:

• dónde estamos (la posición del observador)
•  hacia dónde miramos (la orientación del observador)
• en qué dirección apuntamos el ratón (el usuario está señalando en 3D en una línea definida por su posición y la posición en la que apunta con el ratón)
• si hay algún objeto en la dirección en la que apunta (para escoger un objeto, lo que se denomina «picking»)

Las tres primeras partes se pueden obtener tan sólo usando características de X3D. No es inmediato, hay que recurrir a crear un mundo con un juego de sensores especialmente dispuestos para obtener todas esas coordenadas. Y encontré una forma de obtener toda esa información… salvo por el último punto: ni siquiera con las últimas adiciones al estándar (que incluyen capacidades de picking) se puede detectar la intersección del punto que señala el usuario con cualquier objeto de la escena.

Lo frustrante es que esa información realmente existe y se calcula en el interior del browser Xj3D; bastaría con hacerla visible al exterior de alguna manera. En principio pensé en trastear con el código y crear algun método que me permitiera acceder a esa información directamente. Pero viendo la página web de un producto basado en X3D, me he dado cuenta de que las compañías, cuando tienen necesidades que el estándar no cubre, las solucionan creando nuevos nodos que se puedan incluir en las escenas para obtener la información necesaria. De esta manera, la nueva funcionalidad queda accesible no sólo para una aplicación en concreto a través de parches o agujeros, sino para todos los usuarios de X3D a los que pudiera interesar.

No obstante, implementar un nuevo nodo no parece ser exactamente trivial, sobre todo porque tendría que definir primero qué información quiero conseguir con esos nodos y estructurarla de forma que pudiera ser útil en general. Así que para averiguar qué información necesaria se puede hacer accesible a través de nuevos nodos y de dónde se puede sacar, la siguiente tarea será analizar cómo se controla internamente en Xj3D la posición y orientación del usuario.

Un mundo nuevo (y útil)

Descubrir que mi aplicación puede comunicarse con el browser X3D me reafirmó en la idea inicial de hacer que el propio browser se encargara de todo lo que fuera posible. De esta manera, todo lo relativo a la gestión de la escena tridimensional y su visualización ya estaría implementado en el propio browser, y mi aplicación sólo tendría que encargarse de la creación de nuevos nodos y de modificar los existentes (que, por otra parte, es todo lo que tiene que hacer un editor… ;-), sin necesidad de volver a implementar toda la gestión de la escena desde cero.

Pero dado que el acceso externo sólo se puede hacer a través de las propiedades de los elementos de la escena, para poder obtener información útil del mundo que está experimentando el diseñador es necesario crear un entorno inicial que ya tenga preparados ciertos objetos, que serán los que utilice la aplicación para obtener la información que el browser no proporciona directamente.

Como los servicios que está obligado a proporcionar un browser estándar son bastante escasos, obtener información tan necesaria como la posición y orientación del diseñador, o la dirección en la que apunta con el ratón, requiere la colocación estratégica de algunos elementos (visibles o no), sólo para que la aplicación pueda leer esos datos a través suyo.

Ese mundo inicial está disponible en sus sucesivas versiones en el repositorio, en forma de archivo X3D, visualizable con cualquier visor de X3D, aunque yo estoy usando para el desarrollo la versión Xj3D-2-M1-DEV-20071214 de Xj3D. Más información sobre posibles visores X3D en sucesivos post. Permanezcan atentos a sus pantallas…

Nota mental: leerse el estándar

A menudo consideramos que los estándares oficiales son largos y aburridos, y que están pensados sólo para referencia y para crear implementaciones concretas; para acercarnos a algún tema solemos preferir cualquier tutorial que nos lo de ya mascado. Pero eso tiene sus inconvenientes: la mayoría de los tutoriales, en aras de la sencillez, sacrifican aspectos del tema en cuestión que nos pueden resultar útiles, o, como es el caso, inspiradores.

En mi caso, tuve el proyecto prácticamente parado durante bastante tiempo, porque me empeñé en que mi aplicación debía ser una versión del navegador Xj3D modificada para que se comportara como yo quería, y las pruebas que hice indicaban que modificarlo hasta ese punto iba a ser incluso más difícil que implementar un editor desde cero. Pero al leer el estándar me encontré con que las especificaciones de X3D incluyen la posibilidad de crear un navegador incrustado en una aplicación externa que además (y eso es lo interesante) puede comunicarse con él, registrando el interés de la aplicación sobre ciertos valores de la escena que se está viendo. Esta posibilidad me inspiró una dirección nueva para trabajar, eliminando la necesidad de modificar el navegador para poder concentrarme en una aplicación externa que colabore con él.

Procuraré recordar para la próxima vez que la verdad verdadera sólo se puede encontrar en un sitio: en el estándar.  😉

Herramientas gráficas para el análisis de librerías

Intentando entender la estructura y funcionamiento de las librerías que quiero usar en el proyecto, me dí cuenta de lo difícil que resultaba hacerse una idea de los principios generales a través del Javadoc, que es en la mayoría de los casos la única documentación de que se dispone (al menos en Java resulta fácil de generar automáticamente 😉 ).

Los ejempos son de mucha ayuda cuando sólo se pretende utilizar la librería. Pero cuando se busca mejorarla o ampliarla de algún modo, hace falta una comprensión más profunda de su estructura y funcionamiento interno, y entonces se ve uno obligado a ir clase por clase y analizar cientos de líneas de código sólo para hacerse una idea.  Por eso se me ocurrió que tal vez estaría bien buscar alguna aplicación capaz de hacer alguna representación gráfica de una librería a partir de su código fuente. Y alguna cosa encontré.

Nuevos problemas, nuevas soluciones, un poco de ayuda

Quizá me esté equivocando, pero ante la opción de desarrollar un entorno completo de edición en 3D desde cero o utilizar algún explorador X3D y modificarlo, sigo inclinándome por intentar reutilizar todo lo posible, ya que el plazo de desarrollo no es mucho, y ya llevo acumulado bastante retraso…

Y el desarrollo previo que más parecía ajustarse a mis necesidades era la librería ChefX3D, diseñada justo para lo que necesito: se trata de una herramienta de creación de editores en X3D. Sin embargo, tras lograr ejecutar la aplicación de prueba y husmear un poco, ví que tenía una deficiencia grave para usarla en mi proyecto: la edición sólo se podía hacer en la ventana 2D, en la vista tridimensional no se podía modificar nada.

La solución ideal parecía pasar por implementar una vista tridimensional que fuera modificable, pero ¿cómo saber si me iba a resultar más costoso que crear el editor desde cero? ¿Había intentado alguien algo similar? ¿Qué problemas había tenido?

Para buscar algo de luz, abrí un hilo en el foro de Xj3D alojado en Web3d.org, comentando lo que quería hacer y preguntando cómo de difícil sería hacerlo. Y la respuesta fue casi inmediata y acogedora: desde el foro, los mismos desarrolladores de Xj3D me aconsejaron usar ChefX3D, y al exponerles el problema que tenía, me han dicho que implementar esa vista tridimensional editable es algo que su código necesita desde hace tiempo, e incluso pueden darme alguna indicación de cómo abordar la tarea. Espero más noticias suyas…

Propósitos de año nuevo

Este año querría:

• Prestar más atención al blog: postear contando todo lo que pasa, a diario si puede ser. Si algún día no hay novedades sobre el proyecto, hablar del tiempo. 😉
• Dejar de darle vueltas a la elección de la librería, el diseño de la aplicación… y escribir (¡por fin!) alguna línea de código (¿qué tal algún commit para empezar bien el año?)
• En definitiva: avanzar, aunque sea poco a poco.

Ahí me lo dejo colgado, más que nada para referencia propia… Espero poder cumplir alguno de esos propósitos, y os deseo a todos que este año nuevo vea la culminación de todos vuestros proyectos profesionales, informáticos y personales.

¡Feliz 2008!

ChefX3D: ¡A veces insistir funciona!

Cada vez que pensaba en la cantidad de cosas que tendría que implementar si partiera de cero me daban ganas de volver a intentar hacer funcionar los ejemplos de la librería ChefX3D. Me parecía muy raro que un fallo que haga que ni siquiera llegue a mostrar la pantalla principal se les hubiera pasado a los desarrolladores… Así que, a base de insistir, al final logré encontrar el fallo. Y solucionarlo.