Árboles Y Scripts En Sandra Engine

[DraKKaR]

 Como ya hace tiempo que no os doy la brasa sobre el motor, voy a comentar algo de lo que he estado haciendo últimamente. En el trabajo tengo la misión de implementar una librería (¿no deberíamos llamarlo bibliotecas?) de manejo de árboles y bosques multirresolución. La idea es conseguir algo similar a lo que es SpeedTree pero implementado sobre modelos multirresolución contínuos, no discretos. Os dejo una captura de pantalla:



Lo que se intenta es que la biblioteca gestione internamente y automáticamente la geometría de cada instancia de árbol y ajuste su nivel de detalle acorde a una serie de parámetros relevantes. Quería poner un video para que se vea todo en movimiento, pero era demasiado pesado, así que os dejo con las imágenes (en la web hay un par más).

Ya he dicho antes que la biblioeca debe ser totalmente independiente del motor o aplicación que se ocupa del render, así para probarla he usado el Sandra Engine, tan válido como cualquier otro para probar esa separabilidad deseada.

Para crear el bosque me decidí por no usar código fuente en C/C++ sino en explotar un poco más la posibilidad de scripting del motor. Hace un tiempo le doté la capacidad de ejecutar comandos de consola, de forma que implementar nuevos comandos es crear una nueva instancia que herede de la clase sandra::ConsoleCommand e implemente la función Execute(). Esto tenia la limitación de ejecutar comandos que el uruarios escribe en la consola, así que para poder ejecutar scripts implementé un nuevo comando de consola ("run") que se encarga de ejecutar por orden todos los comandos contenidos en un fichero de texto. De esta forma, la cosa ya empieza a ser un poco más scriptable.

Os dejo con el script utilizado para crear el bosque para explicarlo un poco.

Código [Seleccionar] Expand

loadplugin lodtree.dll

skybox load texturas\skybox\sky_l.bmp texturas\skybox\sky_r.bmp texturas\skybox\sky_d.bmp texturas\skybox\sky_u.bmp texturas\skybox\sky_f.bmp texturas\skybox\sky_b.bmp

skybox display 1

create vector 100,10,100
set max
create vector -100,10,-100
set min


loadmesh terreno.3ds -
set terreno
create spaceobj
set spterr
prop spterr.displayobj terreno
world add spterr
prop terreno.lighting 1
prop spterr.scale 4,1,4


repeat i 18

 lodtree create lodtree.ini
 set arbol$i$

 rand min max
 set randpos

 create spaceobj
 set s
 prop s.displayobj arbol$i$
 world add s

 raymeshcol spterr randpos 0,-1,0
 set finalpos
 prop s.pos finalpos

 prop arbol$i$.lighting 1

endrepeat


repeat i 27 from 20

 lodtree create tilia.ini
 set arbol$i$
 rand min max
 set randpos

 create spaceobj
 set s
 prop s.displayobj arbol$i$
 world add s

 raymeshcol spterr randpos 0,-1,0
 set finalpos
 prop s.pos finalpos

 prop arbol$i$.lighting 1

endrepeat



# Habilitar iluminaci
world addlight 100,300,0
world addlight 0,400,200
world addlight -150,-450,0
world lighting 1
world lightmul 50000
world ambient 0.3,0.3,0.3


loadtexture GRASS2.JPG
set terrtex
prop terreno.material.texture terrtex
loadtexture normalmap.png
set normalmap
prop terreno.material.normalmap normalmap


Por ahora el scripting por comandos de consola es algo simple. Cada línea en el script representa un comando (la primera palabra de la linea es el comando y el resto los argumentos).

Lo que primero hace el script es cargar el plugin del motor que utiliza la biblioteca de árboles (esa dLL es el nexo de unión entre el motor y la biblioteca). Después se carga un cielo (skybox) y se hace visualizable. Después nos definimos 2 vectores (max y min) que utilizaremos para obtener posiciones aleatorias donde "plantar" los árboles. Max y min representaran los límites en cada dimensión para la posición de cada nuevo árbol aleatorio.

El comando "set" es el que puede marearos. Realmente es un "apaño" que hice para no complicar mucho el scripting inicialmente. Cuando ejecutas un comando de consola, éste puede devolver un valor (de cualquier tipo: malla, textura, vector...). Set se utiliza para coger el valor devuelto por la última instrucción y asociarlo a la variable que se le pasa como parámetro. Realmente un bloque de este tipo:

Código [Seleccionar] Expand

comando arg0 arg1
set res

debería traducirse (y se implementará en el motor dentro de poco) como:

Código [Seleccionar] Expand

res = comando arg0 arg1

El siguiente bloque de isntrucciones simplemente carga un terreno contenido en un fichero 3DS, le asocia una variable y lo escala.

Además de comandos también se pueden definir nuevas propiedades para tipos de objetos. De esa forma, el comando "prop" ejecuta la propiedad al lado derecho del "." asociada al tipo de objeto del lado izquierdo, pasándoselo como referencia para poder modificarlo. De esta forma añadir nuevas propiedades a objetos (incluso en otros módulos o DLLs) es muy sencillo.

La instrucción repeat fue una de las últimas que añadí y permite crear bucles de un número determinado de repeticiones. Su sintaxis es bastante sencilla. Repiten todas las instrucciones que haya entre el repeat y el endrepeat, y además sustituye la construccion $var$ por el valor que tenga esa variable en cada iteración dada.

Dentro del bucle, lo que se hace a grandes rasgos es:
1- crear un nuevo árbol (la instrucción "lodtree" no está implementada en el  motor, sino en la DLL que hemos cargado al principio, de esta forma módulos de terceros pueden registrar nuevos comandos aumentando la funcionalidad del motor).
2- generar un vector aleatorio entre (min,max) en 3 dimensiones. Ese vector representará la posición del plano XZ (horizontal) donde se plantará el arbol.
3- calcular la colissión del rayo vertical desde la posición aleatoria hacia el terreno para calcular el punto de implacto y obtener la posición final donde se plantará el arbol.
4- Añadir el arbol al mundo y habilitar la iluminación.

El siguiente bucle hace lo mismo que el anterior salvo cargando otro modelo de árboles.

El siguiente bloque simplemente crea 3 luces puntuales y configura la iluminación para el mundo. Y por último se carga la textura del terreno y el mapa de normales del mismo y se aplica sobre él.

Os puede parecer raro el rumbo de desarrollo que estoy tomando. La causa es que no programo el motor en mi tiempo libre (hago cosas no-informaticas para intentar no quemarme) ya que además mi trabajo ya me permite jugar con el 3D y los gráficos. Poir eso aprovecho la necesidad que me surge en el curro para añadir nuerva funcinoalidad al motor, como en este caso.
Estoy de enhorabuena, el próximo paso es implementar sombras arrojadas para los árboles y podré permitirme implementarlas en el motor. Había pensado en usar shadow maps ya que los árboles ya tienen mucha geometría y no quería complicarla añadiendo volúmenes de sombra geométricos para las stencil shadows.

Bueno, eso es todo, solo quería comentar como andaba un poco el estado del motor que hace tiempo que no comentaba nada.
Por cierto, estoy implementando la carga de recursos dentro de ficheros ZIP, cosa que ya tengo casi al 100% (implementando una interfaz virtual de lectura de ficheros), el problema con el que me he topado es que me gustaría meter DLLs dentro del paquete (ZIP) y poder cargarlas desde dentro del ZIP. Lo que pasa es que las funciones de Windows para cargar DLLs (LoadLibrary[Ex]) no permiten cargar el fichero de un stream en memoria sino directamente del disco. ¿Alguien sabe como resolver esto?

Gracias a los que habeis leido hasta tan lejos ;)

[zupervaca]

 reduce la imagen, yo tengo el escritorio a 1280 y se hace imposible leer el post, ademas de que quita las ganas de hacerlo :(  

[DraKKaR]

 Perdonad, el monitor de donde saqué la captura es una mala bestia. No me había dado cuenta que estaba muy grande... ¿mejor así?

[fiero]

 Muy buen trabajo DraKKaR  (ole) . ¿En qué empresa trabajas (si se puede saber)? ¿Haceis simulación o juegos?

un saludo

[Mars Attacks]

 ¿Qué tal va la cosa de rendimiento? ¿Necesita mucha máquina? ¿Hay algún tipo de gráfico de consumos o algo así?
Me he quedado con las ganas de verlo en movimiento, pero como de costumbre, menudo trabajazo  (ole)  

[AgeR]

 Muy buena pinta, sí señor, tanto los árboles como las posibilidades del Sandra Engine  (ole) .
Por cierto, la librería de los árboles, será gratuita o de pago? (supongo que de pago).

[DraKKaR]

 Gracias a todos por responder.

fiero: trabajo para la universidad de castellón, en un proyecto compartido por varias universidades. No hacemos ni juegos ni simulación, más bien investigación y herramientas entorno al 3D. Más concretamente en el apartado de geometría.

Mars: es una primerísima versión de la biblioteca y va bastante justo de rendimiento. Sobre todo al poner mmuchos árboles. Cada árbol tiene alrededor de 200.000 polígonos (contando hojas, tronco y ramas). Pero más problemático que pintar muchos polígonos (las tarjetas gráficas de hoy en dia son unas bestias) es realizar el cambio de nivel de detalle: extraer el nuevo nivel de detalle y aplicarlo subiendolo a la tarjeta. Hay que tener mucho cuidado con esto para que no haya trompicones. Además, hay muchas técnicas de visibilidad a aplicar para mejorar el rendimiento y minimizar la geometría a renderizar. Ya os iré enseñando cosas en futuras versiones.

Ager: pues no tengo muy claro si será de pago o gratuita, pero teniendo en cuenta que está siendo desarrollada por una universidad es posible que sea gratuito.

[Haddd]

 Yo estuve mirando el tema hace tiempo. Lo cierto es que es un campo muy interesante. ¿habeis planteado hacerlo para SM 4.0 donde puedes generar la geometría en tiempo de ejecución ? Creo que hay una demo de MS que hace eso exactamente. Eso os permitiría controlar el LOD, además de tener árboles totalmente diferentes.

Lo cierto es que el SM 4.0 cambiará totalmente la concepción, porque al poder generar vértices, podremos crear el terreno a partir de un displacement map con teselación adaptativa, podremos utilizando el mismo caracter crear múltiples enemigos diferentes ( recuerdo la demo de Matrox sobre su displacement mapping sobre personajes, era increible ) , podemos crear el sistema de partículas dentro del propio shader...Supongo que la normal también podrá calcularse por cara y no necesitaremos guardarla...

Creo que vamos a pasar directamente al Haddd 4  :lol:  

[DraKKaR]

 Exacto, cuando salga el SM4 cambiará totalmente las posibilidades del hardware gráfico, sobretodo por la posibilidad de generación de geometría por hardware. Estamos a la espera de que salga la primera tarjeta qeu soporte este API para empezar a investigar todas las nuevas posibilidades. Se podría construir un modelo multirresolución totalmente por hardware :o

[BeRSeRKeR]

 Aquí tenéis dos presentaciones que han salido recientemente sobre el nuevo DirectX y Windows Vista. Precisamente muestra el tema de los geometry shaders generando un sistema de partículas. Puede hacer que de una partícula nazcan más partículas, etc. ¡Todo en la GPU!. Eso sí, lo muestran en modo REF, o sea, emulado por software.

Recomiendo bajar lo que son los videos (la presentación, que ya lleva las diapositivas incluídas) y no sólo las diapositivas.

Saludos.

[zupervaca]

 el problema que le veo a todo esto es que ni siquiera el 2.0 es un estandar aun, la mayoria de la gente sigue con tarjetas graficas que soportan shaders 1.0 por software

[BeRSeRKeR]

 Al menos cuando salga Vista la norma sí que serán los shaders 2.0. Es la base de la que partirán.

Saludos.