mundojava-develop

[Mundojava-develop] Assets ToolChain

[Gerardo H. <ma...@si...>]

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

Re: [Mundojava-develop] Assets ToolChain

[Adrian C. <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.
>
>    

Re: [Mundojava-develop] Assets ToolChain

[Gerardo H. <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

Re: [Mundojava-develop] Assets ToolChain

[Gerardo H. <ma...@si...>]

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