casi que lo más sencillo y práctico que puedes hacer es crear funciones (o usarlas si ya las tienes) que comprueben colisiones entre cajas, esferas y polígonos (todos con todos). No hace falta que los modeles, porque son imaginarios, a menos que quieras verlos para depurar o por curiosidad. Sencillamente basta una matriz para describirlos, porque en ella tienes la posición, la orientación (para el caso de las cajas) y la escala.

A cada objeto le asignas uno u otro bounding, excepto a los que colisionen por póligonos que serán aquellos que requieran precisión y no sean demasiado complejos, por ejemplo los muros, para estos tendrás que pasar a la función de colisión la geometría del propio modelo.

Tendrás a veces que asignar varios, de manera que se aproxime a su entorno. Para un coche pueden servir un par de cajas, y para un humano una esfera para la cabeza, y unas cajas para tronco y extremidades.

Cuando ya tienes las funciones implementadas y los boundings asociados a cada modelo o a cada parte del modelo. Ahora para cada par de objetos que compruebes usa las funciones correspondientes. Por ejemplo, para comprobar la colisión entre la cámara y el muro, se deberá usar la función que comprueba entre la esfera y una serie de polígonos (los mismos que componen los muros).

O si quieres saber si hay colisión entre una espada con un personaje se comprobaría el BoundingBox que tiene asociado la espada con cada uno de los boundings que componen el personaje. Si le has definido con 50 esferas por poner un ejemplo, pues se sabrá con bastante exactitud en qué parte del cuerpo ha colisionado. Si no hace falta mucha precisión pues basta con una esfera.

Pero no hace falta que hagas la esfera, simplemente objetos asociados de una clase (CBoundingSphere) que describa su posición y su radio o una matriz 3d, y que tenga las funciones de comprobación con otros tipos de boundings o con series de polígonos.

vaya charla, espero que te sirva de orientación.

Está claro que donde más puedes ganar es indexando vértices.

Por ponerte un ejemplo, una malla de 10x10 tiene 200 triángulos, por lo que sin indexar serían 600 vértices e indexada se quedaría en 100, por lo que es un coste 6 veces mayor. En el caso de la chapa todos comparten la misma normal y casi se podría considerar como una malla deformada donde multitud de vértices de diferentes triángulos están repetidos.

Entonces para indexar:

- Creas una lista de índices del mismo tamaño que el número de triángulos x 3.

- Creas otras sin tamaño fijo (se desconoce) donde añadir las nuevas listas de vértices, normales, etc.

- Recorres la lista de triángulos a indexar y vas añadiendo cada componente de vértice a las nuevas listas, excepto si está en la misma posición o en una muy próxima que otro que se haya añadido ya, lo que significaría que está duplicado y se puede descartar.

- Si se ha agregado un nuevo vértice, añades a la de índices la posición en la lista a la que apunta dicho vértice.

- Pero si está duplicado, entonces añades a la de índices la posición que apunta al vértice existente (el primero que se añadió).

Más o menos es así. Si usas normales, o coordenadas de textura, deberás tener varias listas temporales (además de la de posición vértice) a las que ir añadiendo cada componente, todas serán del mismo tamaño.

Al final esas listas las metes en un buffer o creas otras de tamaño fijo, o lo que más te convenga.

Si tuviéramos un superordenador, capaz de simular a la perfección todo tipo de partículas y su física, en cantidades inmensas, y con esas partículas construyéramos un cerebro virtual idéntico a uno humano que funcionase y se comportase exactamente igual. ¿tendría conciencia?.

Quiero aclarar que con glVertexPointer y similares los datos no suben realmente (al menos hasta que no empiece a dibujar) porque lo único que se le pasa es el puntero al array que está en la memoria de sistema. Aunque imagino que al dibujar subirán todos, volverán a "bajar" al desactivar el ClientState.

Para que residan permanentemente en memoria de vídeo local hay que "Bindearlos" en un buffer object al principio del programa con glBindBuffer (como las texturas). y rellenarlos con glBufferData con la opción GL_STATIC_DRAM. de esta manera los apuntadores a glVertexPointer y similares en lugar de apuntar al array memoria local, lo harán al buffer actualmente activado (que en este caso residirán en la memoria de vídeo) por lo que el puntero deberá ser 0.

Requiere la versión 1.5 por lo que si lo usas deberías dejar opción con un if/else para que la tarjeta pueda tomar los datos desde el VBO activado, o desde el puntero al array si no los soporta.

Es sencillo, en resumen sería así:

En lugar de glBegin hay que usar glEnableClientState según los componentes de vértice que vayas a usar, que los tendrás empaquetados en arrays.

usas glVertexPointer, glNormalPointer, glTexCoordPointer, etc. para subir los datos.

Dibujas los grupos de vértices que desees tantas veces como quieras con glDrawArrays,  o puedes usar glDrawElements si lo tienes indexado.

y terminas con glDisableClientState para cada componente que hayas activado.

Viene muy bien toda esta info. Aunque se podría ampliar un poco más concretando en lo que nos suele interesar por estos foros.

Normalmente querremos usar algunas librerías, bien para cargar un tipo archivo, usar físicas, sonidos 3d, etc. Donde el código correspondiente puede ser un 1% de todo el programa, y por tanto sería absurdo que el resto de código principal quedase "contaminado".

Entonces, ¿lo mejor para esto son las licencias LGPL verdad?, ¿se pueden comercializar programas que usen porciones de código con esta licencia sin más problema y preocupación?.

Aprovechando el hilo queria hacer otra pregunta relacionada: merece la pena implementarlo de tal manera que en caso de que un objeto algunas caras las tenga con materiales trasparentes y otras no, se pinte por partes las caras, para que las solidas se pinten con todo lo solido y lo trasparente despues? Osea, que pasaria si tengo un objeto solido y trasparante a trozos? es frecuentes esto? Tal como lo tengo implementado seria bastante coñazo tener que soportar ese caso, si no se suele dar casi que lo dejo asi, pero si es frecuente encontrar modelos asi lo tendre que hacer.

Lo ideal sería subir todos los vértices del modelo, y luego dibujar cada parte por su material mediante índices (interior, chapa, neumáticos, etc). Los trasparentes al final y con el depthwrite desactivado (tal vez puedas evitar el tener que ordenarlos)

y si le añades una segunda textura con un mapa de entorno a las partes reflectantes te quedará perfecto.

Estoy haciéndolo como dije, es bastante rápido, 40 muestras de shadow volumes fusionadas, sobre un fondo negro voy pintando de tono gris (40/1) fuera de la sombra del volumen actual. Después para que no quede negra la parte más oscura le aplico un clareado mezclando una quad encima.

¿Que os parece?, con esto casi me doy por satisfecho, aunque con la modificación de las proyecciones del volumen se obtienen diversas formas.

Esta obtenido de un cilindro a partir de una única luz pero tengo pensado que se puedan fusionar las que sean necesarias.

pues yo creo que debería funcionar el X8R8G8B8, tiene el mismo tamaño estructura, que es lo que importa. no creo directx vea ninguna diferencia con una A8.... al aplicar el alpha.

¿y no te sirve usar D3DFMT_X8R8G8B8?

Lo quieres en tiempo de ejecucion? Porque si no lo mas facil seria recurrir a la radiosidad precompilada :P

Vaya casualidad, en el mismo minuto  :o

Lo quiero en tiempo de ejecución pero sin tener que actualizar en cada frame.

¿De qué va la radiosidad precompilada? supongo que tendra en cuenta el entorno, pero de momento lo que quería era crear mapas individuales al principio para cada objeto y punto de luz para luego "pegarlos" en el suelo, y con lo antes mencionado parece que obtengo lo que deseo.

Bueno, creo que ya lo conseguí.

Parece que lo mejor es tomar y fusionar la proyección de decenas de sombras de volumen con el origen circundando al punto de luz.

¿Alguien sabe qué es lo mejor para generar shadow maps de calidad?. Sin shaders, y en un tiempo que sin ser necesariamente rápido, tampoco se tire demasiado tiempo.

Lo que quiero es calcular al principio y luego no tener que hacer más operaciones (como mucho regenerarlas de vez en cuando), simplemente blendear la textura de la sombra generada sobre el plano para que quede más o menos así.

Para eso creo que lo mejor es GL_DECAL que dibuja la textura encima del color pero la mezcla dependiendo del valor alpha. Deberías entonces poner la textura superior con alpha a 0 y el resto a 1.0

Para acelerar el asunto de las sombras puedes dibujar simultáneamente las caras delanteras y traseras del volumen, desactivando el CULL FACE.

Para ello hay que usar unas extensiones que sirven para indicar que haga la operación de stencil correspondiente (incrementar o decrementar) para los polígonos traseros y delanteros de manera independiente.

Abajo de esta página hay un código muy completo, que sirve para las ATI y para las Nvidia y para las tarjetas que no soportan el "single pass". Incluso tiene posibilidad de usar el z-fail.

http://www.gamedev.net/community/forums/topic.asp?topic_id=265278&whichpage=1&#1625370