Hola a todos:
Tengo una duda con los lightmaps. No puedo indexar ( eficientemente ) la malla porque los lightmaps nunca ( o casi nunca ) comparten coordenadas de textura. Como se arregla este problema?
Tengo otra duda respecto al filtrado de texturas. Si pego los lightmaps unos a otros, el filtro bilinear me coge los texels del lightmap de al lado y los parametros GL_CLAMP y GL_CLAMP_TO_EDGE no me ayudan...
Si alguien me puede ayudar ( Lord Trancos, pofavó! ), muchas gracias!
Adiooos!
Los lightmaps necesitan de un canal de coordenadas de mapeado exclusivo para ellos :)
Tras leer vuestras respuestas, a mi me salen más preguntas. Si no es posible reusar vertices debido a la coordenadas de textura de los lightmaps entonces:
1.- ¿Merece la pena indexar la malla y enviar la geometria mendiante vertex arrays? o ¿Seria mejor usar display list?.
2.- ¿Mereceria pintar usando multitextura o pintado en dos pasadas?, ya que si pintamos en dos pasadas podriamos construir dos arrays de vertices (uno con las coordenadas de textura, y otro con las coordenadas de textura del lightmap) que podrian reusar vertices y por lo tanto indexar eficientemente (incluso stripificar) la malla.
3.- Y por último, gracias.
Yo tambien habia pensado lo que dice jal. Separar las dos mallas y hacer dos pasadas. Vale que ( en teoria ) no iria tan bien como utilizar multitextura, pero de esta forma, podrias ordenar la "malla de lightmaps" por material, stripar, etc.
Esto es un jaleo :bbb
Ostias me has rayao con lo de las 2 pasadas... y yo q te iba a contestar algo xD DIOX eeeeeeeeeeee a ver son 2 pasadas y texturizas 2 veces?
Si es asi (q creo q lo he entendio mal pero weno...) pq no en tu array pintas una vez y OTRA ENCIMA y si le pisa la textura con el LM pos la pisa y asi solo tienes una haces unos IF y te quedas con 1.
Yo creo q lo he entedio mal pero lo mismo pillas la idea q te dicho y te sirve de algo.Pq dices q pintas 2 veces texturas para unas q le afecta la luz y otras las de la malla O_o no? y te quedan unas con LM y otras sin el, las superpones y con la mezcla de las 2 obtienes el resultado.Si es asi prueba lo q te he dicho sino pasa totalemnte pq no lo he pillao :D
MaSTeR lo que dices no se puede llevar a cabo, pues son dos mallas diferentes con la misma topologia. Es decir ambas mallas tienen un número diferente de vertices, aunque el mismo número de triangulos (y si stripificases la malla tendrias diferentes tiras de strip). Esto es debido a que un vertice con coordenadas de texturas del material puede ser utilizado por n triangulos pues eso n triangulos pueden tener la misma coordenada de textura para ese material, mientras que ese vertice con el lightmap tiene tantas coordenadas de textura como triangulos aparece, lo que obliga a generar n vertices diferentes (esto último es cierto si empaquetas los lightmap y añades un borde a cada lightmap dentro del lightmap empaquetador).
La conclusión que se saca de esto, y ahora me doy cuenta, es que no sirve de nada hacerlo en multipasada, pues en la segundas pasada estas enviando el mismo numero de vertices que enviarias si lo hicieses con multitextura (3*nº de triangulos), ya que el lightmap empaquetado con borde impide reuso de vertices. Así que la pregunta definitiva es: ¿Como se pueden generar lightmaps empaquetados cuyos vertices puedan compartir coordenadas de textura del lightmap?
Otra duda que tengo es: Los lightmaps se empaquetan en tiempo de creación o en tiempo carga. Personalmente creo que en tiempo de carga (para así reducir espacio) pero siempre viene bien un segunda (o tercera) opinión.
Ahm 2 mallas xD ya deca yo...
Jal, la pregunta es bastante buena porque es uno de los problemas más grandes con los que me he topado yo. Me gustaría que cada uno contara la solución que le dió al problema.
En mi caso lo soluciono desde el exportador, teniendo 2 opciones (checkbox):
- Preprocesar malla
Que define el modo a tratar de los objetos que tienen esa situación de tener el número de vértices no coincidente con el número de algun (o algunos) de sus canales de mapeado.
-Si no se preprocesa se construye la malla con numcaras*3 vertices para todos los canales (a saco, vamos), rompiendo todo el tema de índices y tal. Para reutilizar el código del motor (el dibujado de objetos siempre lo hago con indexed arrays) lo que se hace es construir una lista de índices con el contenido [1, 2, 3] [4, 5, 6] [7, 8, 9] etc.
Ventajas: Exportación/previsualizado inmediato
Desventajas: Poco óptimo
-Si se preprocesa la malla lo que hago es reconstruir una malla desde 0 generando los vértices necesarios para poder seguir usando indexed arrays. El código es bastante sencillo (por cada cara voy chequeando sus vértices, si todos los datos (vertice)+(UV1)+(UV2)+(UVn...) ya existe en la lista que voy generando, indexo, sino creo otro vértice nuevo). El problema es que tarda en función del número de caras del objeto a preprocesar por lo que para objetos con muchas caras puede tardar una verdadera burrada.
Ventajas: Malla óptima
Desventajas: Tarda mucho en generarse
Cuando se necesita visualizar rápidamente una escena que se está modificando desde el editor, se usaría la opción de no preprocesar mallas (sacrificando rendimiento). Para una versión final o para hacer un testeo de velocidad se usaría la opción de preprocesarlas.
Saludos.
Si pero con esto no solucionas el problema ya que como comento en el post anterior las coordenadas de textura de los lightmaps son únicas para cada vertice de cada triangulo, así cuando realizas el proceso de comprobar si un vertice ya aparece en la lista o no, descubres que ninguno está pues el test de comprobar si la coordenada de textura del lightmap es igual a la de un vertice de la lista siempre falla. Esto lo se porque yo realizo el mismo proceso que tú y al final obtengo tanto vertices como triangulos tengo multiplicado por tres.
Estoy pensando una alternativa, pero aun no lo tengo claro, y es generar una malla plana que represente la malla a original. Seria algo así como si "desplegases" la malla (por poner un ejemplo "como desenvolver un regalo" donde el papel de regalo representaria la malla original y una vez abierto y completamente plano sus posiciones serian las coordenadas de textura del lightmap). Aunque lo que realmente se necesita es una malla plana que contenga la misma conectividad que la malla original, pero como se consigue es una cosa que aun no lo se bien.
Yo obtengo una lista bastante más óptima, quizá haya algo que hagas mal. Ten en cuenta que los vértices que son compartidos por varias caras son muy _muy_ susceptibles de tener las mismas coordenadas de mapeado para cualquiera de dichas caras.
Te pongo un ejemplo práctico que he sacado del log.
Sin optimizar:
Building mesh skipping preprocess: 445 verts 492 tvdiffuse 492 tvbump 0 tvmap2 792 faces
Building done: 2376 verts, 2376 tvdiffuse 2376 tvbump, 0 tvmap2, 792 faces.
(Fíjate como el resultado es numvertices o numcoordenadasdemapeado = numcaras * 3)
Optimizando:
Preprocessing mesh: 445 verts 492 tvdiffuse 492 tvbump 0 tvmap2 792 faces
Preprocess done in 40.65 seconds: 475 verts 475 tvdiffuse 475 tvbump 0 tvmap2 792 faces
(El número de vértices generado es totalmente óptimo)
También puedes ver que ha tardado bastante en generarlo, aunque en este caso ha tirado de la versión debug que es mucho más lenta que la release.
Creo Ithaqua que no llegamos a entendernos. Así que antes de nada unas preguntas para aclararnos.
Lo primero, ¿Los lightmaps los generas o los exportas de una aplicación como el Max?.
Segundo ¿Empaquetas los lightmaps?.
Tercero: El proceso de optimización de malla los realizas con los ligthmaps empaquetados?.
Aclaraciones:
En mi caso los lightmaps los genero con un programa propio , y es en el proceso de EMPAQUETAMIENTO cuando se pierte la posibilidad de reusar vertices ya que he de añadir el BORDE a cada lightmap dentro del lightmap empaquetador (para evitar problemas con el filtro lineal).
Igual si se generan los lightmaps desde el MAX, éste genera las coordenadas de textura y empaqueta los lightmaps y de algun modo que no necesite añadir el borde a los lightmaps permitiendo reusar vertices.
O igual se si generan de forma propia, existe una manera de empaquetar sin necesidad de añadir bordes.
Por cierto si es posible generarlos desde el MAX o existe un plugin que alguien lo diga e del MAX o si existe un plugin y si calculan las sombras también.
Entonces tu problema no es a la hora de preprocesar la malla, sino a la hora de generar el mapeado. Por lo que dices lo generas de tal forma que no puedes aprovecharte de la redundancia que yo comento.
En general yo comentaba cualquier caso en el que se necesite mapeado (no solamente para lightmaps). Incluso puedes tener problemas con el mapeado standard (solamente un canal de mapeado), ya que el editor (en mi caso MAX) puede devolverte 500 vértices y 600 coordenadas de mapeado p.ej.
En el caso concreto de los lightmaps, yo siempre he usado plugins de MAX (Luminaire y Final Render concretamente), aunque el MAX5 ya trae por si mismo una utilidad para generarlos. Y sí, generan sombras :)
Esto deja más claro las cosa. Muchas gracias Ithaqua.
No hay que generar un lightmap para cada triángulo, lo que hay que hacer es agrupar los triángulos que sean mas o menos coplanares (según cierto umbral, o los que se proyecten sobre el mismo plano de mundo) y que además estén conectados entre sí, y usar el mismo lightmap para todo el grupo.
Luego empaquetar todos esos lightmaps de grupos de triángulos (que tendran tamaños dispares) en texturas de lightmap de por ejemplo 256x256 y posteriormente optimizar los vértices duplicados (en este caso sí que habra bastantes vértices compartibles) y crear las listas vértices y de caras para lanzarle a la tarjeta.