mundojava-develop Mailing List for Mundo Java

Puse en el repositorio una prueba para ver que tal funciona un sistema
elemental de obstáculos.

Para probarlo:

cd mundojava
svn update
cd Drafts/Walker
ant run-obs

Pueden controlar el personaje con las teclas: W, A, S, D, Q y E.
Presionando el botón izquierdo del mouse pueden mover la cámara. Con
el scrollwheel pueden acercar o alejar la cámara. Y con ESC salen del
programa.


-- 
Gerardo Horvilleur
ma...@si...
5282-3314
044 55 2709-0509

Es cierto que hay personas que ya saben usar otros programas de
modelado. De hecho, fue de lo primero que me dijeron unas personas al
anunciar el proyecto de Mundo Java en el Campus Party México.

Pero me preocupa la cantidad de trabajo que implique el estar
soportando las diferentes herramientas. Tal vez lo que podemos hacer
es empezar con Blender y, ya que tengamos algo básico funcionando,
evaluar que tan complicado es agregar el soporte para otras
herramientas. Al tener algo ya funcionando vamos a poder entender
mucho mejor que implica realmente ese soporte a otras herramientas.

Se me ocurre que, de la misma manera que estoy poniendo en el blog de
Mundo Java unos tutoriales acerca de cómo se emplea el jMonkeyEngine,
también tengamos dentro de ese mismo blog unos tutoriales para que la
gente pueda ir aprendiendo a usar el Blender. Para los tutoriales de
Blender yo creo que lo ideal es usar videos. Las descripciones en
texto de cómo usar Blender son difíciles de escribir y de leer.

Miguel, ¿tú crees que puedas encargarte de la parte de los tutoriales
de Blender en el blog de Mundo Java?

Por otra parte, también es importante ir contestando las preguntas
acerca del "look" que deseamos lograr. Tal vez una parte de eso se
conteste en base a los experimentos que hagamos y  donde veamos hasta
donde podemos llegar con el jMonkeyEngine. Pero también necesitamos ir
tomando algunas decisiones para poder crear próximamente el sitio web
de Mundo Java.

2009/12/2 Miguel Zuniga <mz...@ma...>:
> El 1 de diciembre de 2009 a las 6:13p, Gerardo Horvilleur escribió:
>>Yo creo que lo primero que hay que resolver dentro del proyecto de
>>Mundo Java es cómo le vamos a hacer para producir todos los assets
>>necesarios. Por assets me refiero a:
>>
>>* Modelos 3D
>>* Texturas
>>* Animaciones
>>* Artwork 2D
>>* Sonidos
>>* Música
>>
>>En particular, yo creo que la parte más compleja es la de Modelos 3D +
>>Texturas + Animaciones.
>>
>>Mi preferencia para hacer el modelado en 3D es que usemos Blender ya
>>que es software libre y funciona en los principales sistemas
>>operativos. Además existe un plugin para Blender, llamado 'hottbj',
>>que permite exportar los modelos a unos archivos XML que jMonkeyEngine
>>puede leer.
>
> Además de Blender, no estaría de más probar compatibilidades de los paquetes comerciales más difundidos (3ds max, maya, etc.) pues el aprendizaje, manejo y posterior dominio de un programa de modelado en 3d no es cualquier cosa, y si existieran voluntarios que supieran trabajar con estos programas, es una gran ventaja. Además, mucha gente tiene, al menos, la versión educacional de ellos. Personalmente, no me gustan los "meshes" creados por maya, pero si el script que los exporte puede lidiar con el hecho que a veces dichos modelos no están completamente cerrados, sería bueno incluirlo. Cuestión de probar.
>
>>Ya hice unas cuantas pruebas. Es posible crear un modelo en Blender,
>>texturizarlo (UV mapping/painting), crear su armature (esqueleto) y
>>animarlo para después exportar todo eso con hottbj y leerlo desde
>>jMonkeyEngine. Funciona (hay que tener un poco de cuidado sobre como
>>se define todo en Blender, pero si se siguen ciertas reglas funciona
>>sin problemas).
>
> Existen sitios con montones de texturas libres para utilizar. Sobre los sistemas de huesos, estaría muy bien ver si los sistemas de blender o 3ds max, por ejemplo, son compatibles, y hasta qué punto.
>
>>Creo que es muy importante que todos estos pasos se hagan dentro de un
>>script para poder garantizar que los podemos repetir automáticamente
>>cada vez que sea necesario. Así cuando un artista modifique algún
>>modelo en Blender, basta con que vuelva a exportar el XML y
>>automáticamente podemos volver a armar el .jme al que pertenece.
>
> De igual manera, antes de comenzar a trabajar personajes, sería muy provechoso definir ciertas líneas para que guarden entre todos ellos una cierta familiaridad. Si hemos de poner tutoriales sobre cómo modelar personajes, debe marcarse que, independientemente de si es un modelador principiante o experto, partir de una imagen 2d es vital para ahorrar tiempo y que quede un personaje coherente.
>
> Sobre el tipo de arte, definir qué tan realista o caricaturesco debe ser el personaje (proporción de la cabeza contra el cuerpo, p. ej., dan impresiones distintas y se pueden realizar distintas características cuando uno u otro), si debemos poner restricciones al número de polígonos, al tamaño de las texturas, etc.
>
> Para ello, el arte 2d es vital. El 2d necesario para ello no es necesariamente el del lápiz de un artista. En animaciones, un personaje compuesto por dos líneas para sus brazos y dos líneas para sus piernas, una para su tronco y un círculo para su cabeza es suficiente para denotar muchas características, pero es muy necesario establecerlo previamente.
>
> De igual manera con los escenarios. ¿En qué época se van a instalar? ¿Guardarán un estilo arquitectónico? ¿Los pueblos serán constantes en cuanto a la era, o intencionalmente convivirán pueblos medievales, contemporáneos y futuristas? ¿Se seguirán trazas urbanas? ¿De qué estilo?
>
> Como habíamos convenido previamente con Gerardo, iremos seleccionando tutoriales para alentar a quienes quieran contribuir con el modelado. Estoy a favor de blender como ingeniería para dichos tutoriales, pues es semejante tanto a 3ds max, a maya y a xsi en su proceder. ¿Cómo abordaremos estos temas? Se aceptan sugerencias.
>
> Les mando un cordial saludo. Espero estén excelentemente bien al leer este correo. Quedo de Ustedes.
>
> Miguel Zúñiga
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Mundojava-develop mailing list
> Mun...@li...
> https://lists.sourceforge.net/lists/listinfo/mundojava-develop
>



-- 
Gerardo Horvilleur
ma...@si...
5282-3314
044 55 2709-0509

Para que quede un poco más concreto este asunto del tool chain y los
scripts, agregué unos archivos y programas al repositorio. Están
dentro de mundojava/Drafts/Walker. Ahí hay un directorio 'assets' con
3 archivos:

1. man.blend: un modelo hecho en Blender con uv mapping, armature y
una animación

2. man.png: la textura para el modelo

3. man-jme.xml: el resultado de exportar el modelo con el plugin hottbj


Dentro del directorio 'src' hay 2 programas:

1. Xml2Jme.java: Lee el archivo 'assets/man-jme.xml', hace unos
cambios a los attributos de render y graba los datos en formato
binario dentro del archivo 'data/man.jme"

2. Walker.java: Lee el archivo 'data/man.jme' (y 'data/man.png que es
simplemente una copia de 'assets/man.png') y los usa para animar al
personaje caminando. Pueden controlar el personaje con las teclas: W,
A, S, D, Q y E. Presionando el botón izquierdo del mouse pueden mover
la cámara. Con el scrollwheel pueden acercar o alejar la cámara. Y con
ESC salen del programa.


Para probar los programas:

cd mundojava
svn update
cd Drafts/Walker
ant


2009/12/2 Gerardo Horvilleur <ma...@si...>:
> El DSL para los scripts es una de las primeras cosas en las que va a
> ser necesario trabajar. Todavía no sé si vale la pena crear un DSL o
> más bien usar un lenguaje que ya exista tal como jython o Groovy.
>
> Voy a ver si en los próximos dias puedo poner en Subversion un ejemplo
> de un modelo de blender con textura y animación, su export a XML, un
> programa que lee el XML hace unos ajustes y lo graba con .jme, y un
> programa que usa ese archivo .jme. Yo creo que eso puede ayudar a que
> todos tengan más claro lo que se necesita.
>
> 2009/12/2 Adrian Carrillo <squ...@gm...>:
>> Me parece muy importante todo esto, el script que tienes pensado usar se
>> hara despues? y que hay a cerca del dsl que estas pensando?,
>> personalmente no se mucho de modelaje en 3d pero para eso estamos aqui
>> para ir aprendiendo.
>>
>> El 01/12/2009 06:13 p.m., Gerardo Horvilleur escribió:
>>> Yo creo que lo primero que hay que resolver dentro del proyecto de
>>> Mundo Java es cómo le vamos a hacer para producir todos los assets
>>> necesarios. Por assets me refiero a:
>>>
>>> * Modelos 3D
>>> * Texturas
>>> * Animaciones
>>> * Artwork 2D
>>> * Sonidos
>>> * Música
>>>
>>> En particular, yo creo que la parte más compleja es la de Modelos 3D +
>>> Texturas + Animaciones.
>>>
>>> Mi preferencia para hacer el modelado en 3D es que usemos Blender ya
>>> que es software libre y funciona en los principales sistemas
>>> operativos. Además existe un plugin para Blender, llamado 'hottbj',
>>> que permite exportar los modelos a unos archivos XML que jMonkeyEngine
>>> puede leer.
>>>
>>> Ya hice unas cuantas pruebas. Es posible crear un modelo en Blender,
>>> texturizarlo (UV mapping/painting), crear su armature (esqueleto) y
>>> animarlo para después exportar todo eso con hottbj y leerlo desde
>>> jMonkeyEngine. Funciona (hay que tener un poco de cuidado sobre como
>>> se define todo en Blender, pero si se siguen ciertas reglas funciona
>>> sin problemas).
>>>
>>> Esos archivos XML que exporta el hottbj los quiero emplear únicamente
>>> como un paso intermedio. Para la distribución de la aplicación yo creo
>>> que los modelos deberían estar almacenados en el formato binario de
>>> jMonkeyEngine (extensión .jme) . Así serán son más compactos y se
>>> pueden leer más rápido.
>>>
>>> Para hacer esto, quiero tener dentro de nuestro proceso de build de la
>>> aplicación un paso donde se leen estos archivos XML y se generan los
>>> .jme. Pasar de XML a .jme no es la única razón para tener este paso
>>> dentro del build, hay varias más:
>>>
>>> * Existen muchos atributos posibles para los nodos de un scene graph
>>> de jMonkeyEngine que no se pueden definir desde Blender (parámetros
>>> para la aplicación de las texturas, manejo de transparencia, etc.)
>>>
>>> * Un scene graph de jMonkeyEngine puede tener Controllers. Lo
>>> controllers permiten tener animaciones sencillas predeterminadas que
>>> se ejecutan automáticamente de manera continua (por ejemplo, que estén
>>> girando las aspas de un molino). Y estos controllers también se pueden
>>> almacenar dentro de un archivo .jme
>>>
>>> * Probablemente vamos a modelar cada componente del mundo por separado
>>> y queramos tener un sólo archivo .jme de donde leemos el scene graph
>>> de una localidad completa con cada objeto ya colocado en su ubicación
>>> correspondiente.
>>>
>>> Yo creo que lo ideal es tener scripts, escritos en algún DSL (Domain
>>> Specific Language), en donde podamos definir para cada .jme que hay
>>> que generar:
>>>
>>> * Los archivos XML que tiene que leer
>>> * Parámetros extra que se le tengan que agregar/modificar a cada nodo
>>> * Controllers que se tengan que agregar
>>> * Como armar un sólo árbol de toda la localidad con todos esos XML
>>>
>>> Creo que es muy importante que todos estos pasos se hagan dentro de un
>>> script para poder garantizar que los podemos repetir automáticamente
>>> cada vez que sea necesario. Así cuando un artista modifique algún
>>> modelo en Blender, basta con que vuelva a exportar el XML y
>>> automáticamente podemos volver a armar el .jme al que pertenece.
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Join us December 9, 2009 for the Red Hat Virtual Experience,
>> a free event focused on virtualization and cloud computing.
>> Attend in-depth sessions from your desk. Your couch. Anywhere.
>> http://p.sf.net/sfu/redhat-sfdev2dev
>> _______________________________________________
>> Mundojava-develop mailing list
>> Mun...@li...
>> https://lists.sourceforge.net/lists/listinfo/mundojava-develop
>>
>
>
>
> --
> Gerardo Horvilleur
> ma...@si...
> 5282-3314
> 044 55 2709-0509
>



-- 
Gerardo Horvilleur
ma...@si...
5282-3314
044 55 2709-0509

El 1 de diciembre de 2009 a las 6:13p, Gerardo Horvilleur escribió:
>Yo creo que lo primero que hay que resolver dentro del proyecto de
>Mundo Java es cómo le vamos a hacer para producir todos los assets
>necesarios. Por assets me refiero a:
>
>* Modelos 3D
>* Texturas
>* Animaciones
>* Artwork 2D
>* Sonidos
>* Música
>
>En particular, yo creo que la parte más compleja es la de Modelos 3D +
>Texturas + Animaciones.
>
>Mi preferencia para hacer el modelado en 3D es que usemos Blender ya
>que es software libre y funciona en los principales sistemas
>operativos. Además existe un plugin para Blender, llamado 'hottbj',
>que permite exportar los modelos a unos archivos XML que jMonkeyEngine
>puede leer.

Además de Blender, no estaría de más probar compatibilidades de los paquetes comerciales más difundidos (3ds max, maya, etc.) pues el aprendizaje, manejo y posterior dominio de un programa de modelado en 3d no es cualquier cosa, y si existieran voluntarios que supieran trabajar con estos programas, es una gran ventaja. Además, mucha gente tiene, al menos, la versión educacional de ellos. Personalmente, no me gustan los "meshes" creados por maya, pero si el script que los exporte puede lidiar con el hecho que a veces dichos modelos no están completamente cerrados, sería bueno incluirlo. Cuestión de probar.

>Ya hice unas cuantas pruebas. Es posible crear un modelo en Blender,
>texturizarlo (UV mapping/painting), crear su armature (esqueleto) y
>animarlo para después exportar todo eso con hottbj y leerlo desde
>jMonkeyEngine. Funciona (hay que tener un poco de cuidado sobre como
>se define todo en Blender, pero si se siguen ciertas reglas funciona
>sin problemas).

Existen sitios con montones de texturas libres para utilizar. Sobre los sistemas de huesos, estaría muy bien ver si los sistemas de blender o 3ds max, por ejemplo, son compatibles, y hasta qué punto.

>Creo que es muy importante que todos estos pasos se hagan dentro de un
>script para poder garantizar que los podemos repetir automáticamente
>cada vez que sea necesario. Así cuando un artista modifique algún
>modelo en Blender, basta con que vuelva a exportar el XML y
>automáticamente podemos volver a armar el .jme al que pertenece.

De igual manera, antes de comenzar a trabajar personajes, sería muy provechoso definir ciertas líneas para que guarden entre todos ellos una cierta familiaridad. Si hemos de poner tutoriales sobre cómo modelar personajes, debe marcarse que, independientemente de si es un modelador principiante o experto, partir de una imagen 2d es vital para ahorrar tiempo y que quede un personaje coherente.

Sobre el tipo de arte, definir qué tan realista o caricaturesco debe ser el personaje (proporción de la cabeza contra el cuerpo, p. ej., dan impresiones distintas y se pueden realizar distintas características cuando uno u otro), si debemos poner restricciones al número de polígonos, al tamaño de las texturas, etc.

Para ello, el arte 2d es vital. El 2d necesario para ello no es necesariamente el del lápiz de un artista. En animaciones, un personaje compuesto por dos líneas para sus brazos y dos líneas para sus piernas, una para su tronco y un círculo para su cabeza es suficiente para denotar muchas características, pero es muy necesario establecerlo previamente.

De igual manera con los escenarios. ¿En qué época se van a instalar? ¿Guardarán un estilo arquitectónico? ¿Los pueblos serán constantes en cuanto a la era, o intencionalmente convivirán pueblos medievales, contemporáneos y futuristas? ¿Se seguirán trazas urbanas? ¿De qué estilo?

Como habíamos convenido previamente con Gerardo, iremos seleccionando tutoriales para alentar a quienes quieran contribuir con el modelado. Estoy a favor de blender como ingeniería para dichos tutoriales, pues es semejante tanto a 3ds max, a maya y a xsi en su proceder. ¿Cómo abordaremos estos temas? Se aceptan sugerencias.

Les mando un cordial saludo. Espero estén excelentemente bien al leer este correo. Quedo de Ustedes.

Miguel Zúñiga

El DSL para los scripts es una de las primeras cosas en las que va a
ser necesario trabajar. Todavía no sé si vale la pena crear un DSL o
más bien usar un lenguaje que ya exista tal como jython o Groovy.

Voy a ver si en los próximos dias puedo poner en Subversion un ejemplo
de un modelo de blender con textura y animación, su export a XML, un
programa que lee el XML hace unos ajustes y lo graba con .jme, y un
programa que usa ese archivo .jme. Yo creo que eso puede ayudar a que
todos tengan más claro lo que se necesita.

2009/12/2 Adrian Carrillo <squ...@gm...>:
> Me parece muy importante todo esto, el script que tienes pensado usar se
> hara despues? y que hay a cerca del dsl que estas pensando?,
> personalmente no se mucho de modelaje en 3d pero para eso estamos aqui
> para ir aprendiendo.
>
> El 01/12/2009 06:13 p.m., Gerardo Horvilleur escribió:
>> Yo creo que lo primero que hay que resolver dentro del proyecto de
>> Mundo Java es cómo le vamos a hacer para producir todos los assets
>> necesarios. Por assets me refiero a:
>>
>> * Modelos 3D
>> * Texturas
>> * Animaciones
>> * Artwork 2D
>> * Sonidos
>> * Música
>>
>> En particular, yo creo que la parte más compleja es la de Modelos 3D +
>> Texturas + Animaciones.
>>
>> Mi preferencia para hacer el modelado en 3D es que usemos Blender ya
>> que es software libre y funciona en los principales sistemas
>> operativos. Además existe un plugin para Blender, llamado 'hottbj',
>> que permite exportar los modelos a unos archivos XML que jMonkeyEngine
>> puede leer.
>>
>> Ya hice unas cuantas pruebas. Es posible crear un modelo en Blender,
>> texturizarlo (UV mapping/painting), crear su armature (esqueleto) y
>> animarlo para después exportar todo eso con hottbj y leerlo desde
>> jMonkeyEngine. Funciona (hay que tener un poco de cuidado sobre como
>> se define todo en Blender, pero si se siguen ciertas reglas funciona
>> sin problemas).
>>
>> Esos archivos XML que exporta el hottbj los quiero emplear únicamente
>> como un paso intermedio. Para la distribución de la aplicación yo creo
>> que los modelos deberían estar almacenados en el formato binario de
>> jMonkeyEngine (extensión .jme) . Así serán son más compactos y se
>> pueden leer más rápido.
>>
>> Para hacer esto, quiero tener dentro de nuestro proceso de build de la
>> aplicación un paso donde se leen estos archivos XML y se generan los
>> .jme. Pasar de XML a .jme no es la única razón para tener este paso
>> dentro del build, hay varias más:
>>
>> * Existen muchos atributos posibles para los nodos de un scene graph
>> de jMonkeyEngine que no se pueden definir desde Blender (parámetros
>> para la aplicación de las texturas, manejo de transparencia, etc.)
>>
>> * Un scene graph de jMonkeyEngine puede tener Controllers. Lo
>> controllers permiten tener animaciones sencillas predeterminadas que
>> se ejecutan automáticamente de manera continua (por ejemplo, que estén
>> girando las aspas de un molino). Y estos controllers también se pueden
>> almacenar dentro de un archivo .jme
>>
>> * Probablemente vamos a modelar cada componente del mundo por separado
>> y queramos tener un sólo archivo .jme de donde leemos el scene graph
>> de una localidad completa con cada objeto ya colocado en su ubicación
>> correspondiente.
>>
>> Yo creo que lo ideal es tener scripts, escritos en algún DSL (Domain
>> Specific Language), en donde podamos definir para cada .jme que hay
>> que generar:
>>
>> * Los archivos XML que tiene que leer
>> * Parámetros extra que se le tengan que agregar/modificar a cada nodo
>> * Controllers que se tengan que agregar
>> * Como armar un sólo árbol de toda la localidad con todos esos XML
>>
>> Creo que es muy importante que todos estos pasos se hagan dentro de un
>> script para poder garantizar que los podemos repetir automáticamente
>> cada vez que sea necesario. Así cuando un artista modifique algún
>> modelo en Blender, basta con que vuelva a exportar el XML y
>> automáticamente podemos volver a armar el .jme al que pertenece.
>>
>>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Mundojava-develop mailing list
> Mun...@li...
> https://lists.sourceforge.net/lists/listinfo/mundojava-develop
>



-- 
Gerardo Horvilleur
ma...@si...
5282-3314
044 55 2709-0509

Me parece muy importante todo esto, el script que tienes pensado usar se 
hara despues? y que hay a cerca del dsl que estas pensando?, 
personalmente no se mucho de modelaje en 3d pero para eso estamos aqui 
para ir aprendiendo.

El 01/12/2009 06:13 p.m., Gerardo Horvilleur escribió:
> Yo creo que lo primero que hay que resolver dentro del proyecto de
> Mundo Java es cómo le vamos a hacer para producir todos los assets
> necesarios. Por assets me refiero a:
>
> * Modelos 3D
> * Texturas
> * Animaciones
> * Artwork 2D
> * Sonidos
> * Música
>
> En particular, yo creo que la parte más compleja es la de Modelos 3D +
> Texturas + Animaciones.
>
> Mi preferencia para hacer el modelado en 3D es que usemos Blender ya
> que es software libre y funciona en los principales sistemas
> operativos. Además existe un plugin para Blender, llamado 'hottbj',
> que permite exportar los modelos a unos archivos XML que jMonkeyEngine
> puede leer.
>
> Ya hice unas cuantas pruebas. Es posible crear un modelo en Blender,
> texturizarlo (UV mapping/painting), crear su armature (esqueleto) y
> animarlo para después exportar todo eso con hottbj y leerlo desde
> jMonkeyEngine. Funciona (hay que tener un poco de cuidado sobre como
> se define todo en Blender, pero si se siguen ciertas reglas funciona
> sin problemas).
>
> Esos archivos XML que exporta el hottbj los quiero emplear únicamente
> como un paso intermedio. Para la distribución de la aplicación yo creo
> que los modelos deberían estar almacenados en el formato binario de
> jMonkeyEngine (extensión .jme) . Así serán son más compactos y se
> pueden leer más rápido.
>
> Para hacer esto, quiero tener dentro de nuestro proceso de build de la
> aplicación un paso donde se leen estos archivos XML y se generan los
> .jme. Pasar de XML a .jme no es la única razón para tener este paso
> dentro del build, hay varias más:
>
> * Existen muchos atributos posibles para los nodos de un scene graph
> de jMonkeyEngine que no se pueden definir desde Blender (parámetros
> para la aplicación de las texturas, manejo de transparencia, etc.)
>
> * Un scene graph de jMonkeyEngine puede tener Controllers. Lo
> controllers permiten tener animaciones sencillas predeterminadas que
> se ejecutan automáticamente de manera continua (por ejemplo, que estén
> girando las aspas de un molino). Y estos controllers también se pueden
> almacenar dentro de un archivo .jme
>
> * Probablemente vamos a modelar cada componente del mundo por separado
> y queramos tener un sólo archivo .jme de donde leemos el scene graph
> de una localidad completa con cada objeto ya colocado en su ubicación
> correspondiente.
>
> Yo creo que lo ideal es tener scripts, escritos en algún DSL (Domain
> Specific Language), en donde podamos definir para cada .jme que hay
> que generar:
>
> * Los archivos XML que tiene que leer
> * Parámetros extra que se le tengan que agregar/modificar a cada nodo
> * Controllers que se tengan que agregar
> * Como armar un sólo árbol de toda la localidad con todos esos XML
>
> Creo que es muy importante que todos estos pasos se hagan dentro de un
> script para poder garantizar que los podemos repetir automáticamente
> cada vez que sea necesario. Así cuando un artista modifique algún
> modelo en Blender, basta con que vuelva a exportar el XML y
> automáticamente podemos volver a armar el .jme al que pertenece.
>
>    

Yo creo que lo primero que hay que resolver dentro del proyecto de
Mundo Java es cómo le vamos a hacer para producir todos los assets
necesarios. Por assets me refiero a:

* Modelos 3D
* Texturas
* Animaciones
* Artwork 2D
* Sonidos
* Música

En particular, yo creo que la parte más compleja es la de Modelos 3D +
Texturas + Animaciones.

Mi preferencia para hacer el modelado en 3D es que usemos Blender ya
que es software libre y funciona en los principales sistemas
operativos. Además existe un plugin para Blender, llamado 'hottbj',
que permite exportar los modelos a unos archivos XML que jMonkeyEngine
puede leer.

Ya hice unas cuantas pruebas. Es posible crear un modelo en Blender,
texturizarlo (UV mapping/painting), crear su armature (esqueleto) y
animarlo para después exportar todo eso con hottbj y leerlo desde
jMonkeyEngine. Funciona (hay que tener un poco de cuidado sobre como
se define todo en Blender, pero si se siguen ciertas reglas funciona
sin problemas).

Esos archivos XML que exporta el hottbj los quiero emplear únicamente
como un paso intermedio. Para la distribución de la aplicación yo creo
que los modelos deberían estar almacenados en el formato binario de
jMonkeyEngine (extensión .jme) . Así serán son más compactos y se
pueden leer más rápido.

Para hacer esto, quiero tener dentro de nuestro proceso de build de la
aplicación un paso donde se leen estos archivos XML y se generan los
.jme. Pasar de XML a .jme no es la única razón para tener este paso
dentro del build, hay varias más:

* Existen muchos atributos posibles para los nodos de un scene graph
de jMonkeyEngine que no se pueden definir desde Blender (parámetros
para la aplicación de las texturas, manejo de transparencia, etc.)

* Un scene graph de jMonkeyEngine puede tener Controllers. Lo
controllers permiten tener animaciones sencillas predeterminadas que
se ejecutan automáticamente de manera continua (por ejemplo, que estén
girando las aspas de un molino). Y estos controllers también se pueden
almacenar dentro de un archivo .jme

* Probablemente vamos a modelar cada componente del mundo por separado
y queramos tener un sólo archivo .jme de donde leemos el scene graph
de una localidad completa con cada objeto ya colocado en su ubicación
correspondiente.

Yo creo que lo ideal es tener scripts, escritos en algún DSL (Domain
Specific Language), en donde podamos definir para cada .jme que hay
que generar:

* Los archivos XML que tiene que leer
* Parámetros extra que se le tengan que agregar/modificar a cada nodo
* Controllers que se tengan que agregar
* Como armar un sólo árbol de toda la localidad con todos esos XML

Creo que es muy importante que todos estos pasos se hagan dentro de un
script para poder garantizar que los podemos repetir automáticamente
cada vez que sea necesario. Así cuando un artista modifique algún
modelo en Blender, basta con que vuelva a exportar el XML y
automáticamente podemos volver a armar el .jme al que pertenece.

-- 
Gerardo Horvilleur
ma...@si...
5282-3314
044 55 2709-0509