Lightmaps UDK

[Zerouks]

Hola, a ver si alguien me puede echar un cable con el siguiente problema. Quisiera saber si lo que muestro a continuación es evitable o no.

Como se puede observar en la siguiente imagen, dispongo de un cubo con su correspondiente normal para biselar los bordes:




Este cubo tiene un smoothing group para cada cara:



También dispone de dos canales UVS, uno para las texturas comunes y otro para él lightmap:




Y ahora viene el trágico desenlace.

Resulta qué a este cubo cuando UDK le calcula la iluminación para la creación de los lightmaps.



Le aparecen malditas Seam.

Mi pregunta es: ¿es posible evitar esto y que se sombre bien? Hice una prueba en 3DMax, bakeando un lightmap allí, y pude ver que cuando se usan resoluciones muy pequeñas ocurre lo mismo, sin embargo, con resoluciones más altas no ocurre. En UDK en cambio si me ocurre con resoluciones altas también. Como mejor he podido comprobar que se muestra es cuando cálculo la iluminación sobre los vertex.

Las imágenes que he puesto, tienen la luz calculada con indirect normal influence bost a 0.

Otra cosa qué me llama la atención, es el tema de los mirrors y las seams en estos casos. Mirando la wiki de polycount sobre NormalMap me encuentro con lo siguiente: If the mirror seam runs along the surface of a continuous mesh, like down the center of a human face for example, then it will probably create a lighting seam.

In Epic GamesUnreal Engine 3 (UE3) their symmetrical models commonly use centered mirroring. Epic uses materiales that mix a DetailMap with the Normal Maps; these sem to scatter the diffuse/specular lighting and help minimize the obviousness of the mirror Seam. For their Light Mapped models they use a technique that can almost completely hide the mirror seam. Y dejan un link a este enlace: http://udn, epicgames.com/Thre/LightMapUnwrapping.html.

Yo por lo menos no he encontrado en el enlace que hable de una técnica para bakear correctamente los lightmap en los modelos mirror. ¿Alguien sabe algo sobre esto también? Gracias de antemano y un saludo.

[infograph3d]

Hola, en el mismo enlace que colocaste, tienes una solución. Al menos creo que tus problemas en el bakeo del ligthmap, puedan ser debido a qué tienes desplegado el objeto Box, con cada cara en un UV chart distinto, (como cuando usamos el Unwrap a saco con el desplegado automático flatten mapping, es lo mismo que lo que llaman UV islands, pero los chart son consecutivos en sus vértices, es decir, pueden coserse entre ellos) que quiere decir esto. Que deberías coser las caras contiguas unas a otras (con una caja es extremadamente sencillo si sabes como) eliminando la mayoría de costuras (seams) posibles.

Esto es para evitar en cierto modo el bleding de color entre costuras cercanas, al ir mapeado el efecto de oclusión, aunque intentamos aprovechar el espacio, a veces no dejamos suficiente entre islas distintas. En el editor de Unwrap, si seleccione las caras contiguas (control+A) y vas a los iconos de tu derecha, veras unos que ponen weld selected subobject, seams o any match selected, a veces no funcionan por que tienen que reorientar las caras para qué sus vértices coincidan y te hace un destrozo. Es mejor, ya te digo, si sabes moverte por el Unwrap, que muevas las caras y las coloques a mano, ayudante si quieres del Snap (tecla S) en max y luego control+S para activar el Snap en Unwrap, ojo, deja de ser guardar escena mientras estes dentro del editor de Unwrap y solo sirve para conmutar el Snap (el icono lo veras en la esquina inferior derecha del desplegable edit Unwrap).

Una vez tengas los vértices consecutivos o relacionados de cada cara una al lado de otra, (que suelen verse de color azul cuando están relacionados, aunque sean de caras distintas) seleccione todos y haces control+W (es lo mismo que ir al panel superior en tools y buscar control+W) esto suelda los vértices siempre que formen parte de la misma arista en tu objeto (recuerda se ponen azules) cuando sueldas estos, la nueva arista deja de ser un seams abierto (verde fuerte claro) y pasa a ser un verde más flojo, casi amarillo.

Otra historia, pueda ser que tuvieras un problema por lo mismo, en caso de que usaras un normal map (no manejo bien esta parte, pero hay quien bakea usando un chamfer en los bordes para evitar artefactos) y luego lo elimina para él objeto a exportar a udque como static mesh. Recuerda usar el UV map 1 en udque creo equivale al 0, para él ligthmap. Y el 2 para la textura. En http://www.gameartisans.org/forums/forum.php y http://www.polycount.com/forum/ vas a encontrar mucha información al respecto mejor de lo que te puedo explicar, ya que no entiendo mucho, aunque pueda parecer.

[infograph3d]

Continuo otro poco, con las cosas que me deje sobre el mirror en el normal map y el ligthmap. Otra solución, cuando un objeto se puede modelar de forma simétrica, también se puede mapear de forma simétrica, es decir, cada lado desde el eje, lleva las mismas texturas, esto puede ser una ventaja, y una desventaja dependiendo del modelo, que es que los detalles de cada lado en cuestión de textura evidentemente son idénticos. Otra es el ligthmap, que no funciona creo en objetos con geometría solapada en sus UVS (como sabrás al trabajar en simetría y mapear un lado de nuestro modelo, las caras simétricas comparten el mismo espacio UV por solapamiento, u overlap) la única solución de dos posibles, es separar las caras solapadas generando un segundo canal UV, donde estará desplegado todo el objeto, pero para bakear aquí nuestro ligthmap. El resto de texturas, continuara perfectamente en el otro canal, diffuse, normap, especular. Otra opción, que también funciona, es tomar las caras solapadas, en el Unwrap, funciona perfectamente la herramienta select overlapped faces en el menú superior select, teniendo únicamente el subobjeto polygon seleccionado, pues es lo único que reconoce por geometría solapada. Una vez tienes las caras en rojo indicadas como solapadas, las mueves a un chunque distinto fuera de las coordenadas 0,0 del Unwrap. (lo que es el recuadro azul de seguridad que enmarca la zona de despliegue de nuestro uv) y haciendo click en el icono inferior izquierdo que dice algo, así como adsolute relative type in (es un icono que parece un punto de mira) hacemos click en él y lo cambiamos a coordenadas absolutas. Ahora podremos desplazar las caras solapadas a un chunque distinto, en U. V,W, son las casillas contiguas a este icono. Si, por ejemplo, ponemos (nos movemos) en valores en el eje U, de -1, desplazamos esas caras al chunque consecutivo a la izquierda, si fuese 1 lo haría a la derecha. De este modo, aunque las caras salen fuera del recuadro original, recuerda qué el Unwrap también funciona por repetición en patrón de la textura qué colocamos aquí (tile) de hecho, es una herramienta más para texturar. Por lo que el ligthmap se colocara por igual a ambas geometría en tu simetría, pero sin tener overlap. Esto también funciona para mapas de normales, ya que, al ser un mapa qué aplica colores según coordenadas, es lógico que muestre artefactos, al invertirse dependiendo de su eje transversal y longitudinal sobre el objeto, por ello, si haces esto antes de bakear las normales, entenderá que son geometrías distintas sin problemas de solapamiento o bleding, y se bakeara bien. Aparte de que al soldar partes simétricas, no cambiara la orientación de los vértices a posterior (otra causa posible que se comenta, de por que se le va la pinza al normal map).

En algunas ocasiones, funciona invertir en 3dsmax o en Adobe Photoshop si sabes como, el canal verde, sobre todo con coordenadas tangentes.

Espero explicarme bien, un saludo.

[Zerouks]

Te has explicado perfectamente, es de agradecer la extensa explicación.

El caso es que lo que comentas ya lo había probado antes. Suelo romperme la cabeza antes de preguntar buscando soluciones y curiosamente obtuve más bleding cuando dejaba el cubo en una única isla, además, en teoría al aumentar la resolución con la que se creaban los lightmaps debería a ver sido suficiente para evitar el bleding y no daba el resultado esperado sin embargo.

El caso es que como en algunas de estas cosas un mínimo cambio te puede dar un mal o buen resultado, he optado por repetir la prueba de dos formas y el resultado ha sido.




Bastante mejor. Aún se pueden ver un poco las seams, pero no sé si eso ya es normal.

Más tarde comprobare si con un objeto mirror funciona así o da problemas. Un saludo.

[Zerouks]

He probado un objeto con mirror y no queda bien. Si es cierto que dependiendo de cómo este el objeto orientado a la luz, si tenemos normal influence bost a 0 no aparece seams en ciertos casos, pero depende de cómo este el objeto orientado y me he fijado en las zonas de sombra si se produce seam en la línea qué junta las dos mitades. Según tengo entendido es mejor no usar este tipo de mirror en statics mesh. Un saludo.

[Fiz3d]

Zerouks, muchas veces esto es más suerte que otra cosa, pero por si las moscas, mete todo en el mismo canal de suavizado, eso de suavizado automático no, hazlo manual, seleccione todas las caras y las metes en un solo canal y después lanza el normal.

Lo de los lightmaps mirror, ¿, ezo como es, es imposible hacer un lightmap con un mapeado mirror, quedaría una guarrada, será que ando muy espeso. Saludos.

[Zerouks]

No, si las caras del cubo están puestas así aposta para qué el normal se bake perfectamente. Lo hago así por diferentes razones. Lo malo es que parece que da problemas con los lightmaps. Aunque no debería.

Pensé que una solución podría ser calcular los lightmaps en el mismo objeto, pero con todo en un smoothing group y luego cargar el de las caras dura y aplicarle a este el lightmap ya creado antes, pero creo que esto no se puede hacer y dependiendo del objeto el sombreado podría quedar mal.

Por cierto, lo del mirror es en el canal 1 el de las texturas normales. Esto suele dar problemas, aunque en el segundo canal se tenga el objeto mapeado sin mirror. Un saludo.

[infograph3d]

Efectivamente, el overlap de caras, en este caso, de un objeto mapeado por simetría, da error de lightmap en udk. Tienes que generar otro template con un canal distinto donde si tengas desplegado todo el objeto (por ejemplo, es un metodo), para bakear el lightmap en el. Puedes perfectamente hacer este en udk, no necesitas hacerlo en 3dsmax.

[Zerouks]

Fiz, hice lo que me dijiste de meterlo todo en un smoothing group. Me he dado cuenta con esto que las seams no son por los grupos de suavizado sino por el lugar donde se encuentra la seam en las UVS del canal 1. Por alguna razón interpreta mal el sombreado, aunque el normal este bien hecho y la UV del lightmap también. No lo entiendo.



Alguna explicación debe de haber ¿no creéis? Saludos.

[Fiz3d]

Si la explicación es que los cortes siempre se van a ver, es imposible quitarlos, por eso se ponen en sitios que no se ven, o se tapan con normals de detalle.

No sé que pasos sigues, pero si lo has probado todo y no te funciona es que, algo tienes que estar haciendo mal, una cubo es muy simple, no te quiero ver con objetos complejos, si puedes reproducir los pasos uno por uno y en orden genial. Saludos.

[Zerouks]

A ver, iba a poner los pasos y demás, pero creo que mejor no sigo dando el coñazo.

Ya me las apañare. Gracias a ambos.

[Fiz3d]

No hombre, como vas a dar el coñazo, aquí se está para aprender.
Los seams no se pueden eliminar, en las UVS siempre habrá un corte, lo que se hace es disimularlas, en un modelo humano pues con los cortes de la ropa, o por la parte interna del brazo o de la pierna si el modelo no tiene ropa, en otros modelos pues o se viven con ellos o se colocan en sitios donde no se va a ver, hay técnicas para disimularlos, muchos pintan por encima del normal o suavizan con Adobe Photoshop, es algo guarro, pero si sabes puede quedar bien, otros meten mapas de detalle, eso rompe la línea del normal.

El caso de tu caja es un problema de suavizado, o sea, la normal original del modelo no tiene continuidad con la consiguiente con lo que se hace un lío al calcular la luz, si metes todo dentro del mismo grupo ese problema tendría qué desaparecer. Por eso digo que cuentes los pasos o me pases el modelo a ver si te podemos ayudar. Saludos.

[Zerouks]

Si es que lo que pasa qué eso que comentas ya lo sé. Si en realidad hay juegos en los que se ven muchas de estas cosas. Las seams siempre van a estar, pero se pueden minimizar mucho.

Las seams que de verdad cantan suelen ser problemas con el normal. Esto es lo que quisiera evitar. Meter todo en un grupo de suavizado funciona bien dependiendo de la topología del modelo. Por eso para una caja pienso que es mejor separar cada cara. Sino el smoothing group intentara suavizarlo como si fuera una esfera creando unos degradados que el normal intentara corregir, y no siempre queda bien. En realidad, hay una forma para qué las seams sean prácticamente invisibles con luz calculadas y todo. Y de esta forma seria metiendolo todo en 1 smoothing group y exportando con tangents y binormals:



La seam se vuelve prácticamente invisible. El método es este: http://udn, epicgames.com/Thre/XNormalWorkflow.html.

Lo que pasa con este método, que también tiene problemas, en este caso, con el suavizado a la hora de crear el normal, creando algunas manchas raras (esto creo que depende de la topología del objeto nuevamente):




Por otra parte, Si un normal se ve bien con luz dinámica, no debería verse mal con luz precalculada, al menos yo lo entiendo así. Lo lógico creo que sería qué se viera igual, ya que para crear el sombreado tiene en cuenta las normales que da la textura, y si estas son correctas, después de calcular luces también deberían de serlo. No sé que es lo que hará UDK para calcular las luces, pero dependiendo del caso, crea una ruptura donde se encuentran las costuras, aunque antes esa ruptura no se viera.

He seguido pasos diferentes para cada prueba. La qué he hecho con un único smoothing group ha sido:
1ºCreo objeto high en 3DS Max y detallo en zbruhs.
2ºCreo el low en 3DS Max a partir del high.
3ºMeto todo en 1 smoothing group en el low.
4ºCreo el primer canal de uvs, en el caso que puse, dejo todo en una única pieza con pocos cortes.
5ºCreo el segundo canal de uvs, en este caso, similar al primer canal.
6ºExporto el modelo low como (*.obj) (para bakear el normal) y fbx(para udk). En el FBX dejo desactivada la opción de tangents y binormals.
7ºBakeo el normal map en xnormal.
8ºAbro udque e importo el archivo fbx. Pongo el lightmap a 128 de resolución, indirect normal influence bost a 0 y production lighting.
9ºImporto el normal con la compresión bc5. Y creo un material con el normal, y dos constantes para diffuse y specular.
10ºCon luz dinámica se ve bien, al calcular luces, crea un corte que antes no se veía donde se encuentra la costura.

El archivo es este: Prueba.rar, el cubo lo borre ya. Pero si hace falta lo hago de nuevo. En el que he puesto no se ve mucho la seam, depende de cómo se oriente con respecto a la luz, lo digo porque a lo mejor no te resulta fácil verla al principio. Saludos.

[Fiz3d]

La diferencia es que yo los normal los creo dentro del Mudbox (ZB en tu caso), normalmente uso el de más bajo nivel o el siguiente.

Por eso para una caja pienso que es mejor separar cada cara.

Esto para un cubo puede funcionar, pero en un modelo orgánico no.

Sino el smoothing group intentara suavizarlo como si fuera una esfera creando unos degradados que el normal intentara corregir, y no siempre queda bien.

Cuando se calcula el normal esto ya se tiene en cuenta, por eso un normal tangencial solo funciona en el modelo para él que fue calculado.

Cuando un modelo se me resiste, y que conste que yo modelo entre poco y nada uso este software. http://www.handplane3d.com/ cada programa calcula los normal como les sale, nunca usé el Xnormal, y cada software le los normal como le apetece, un normal se puede ver bien en UDK y en Max quedar como el culo, este programa lo que hace más o menos es unificar toda esa información, tu le das el normal ya calculado, pero en modo objects space, le dices a qué software va dirigido, en tu caso a UDK, y el modelo de baja y el te hace los arreglos y te saca un tangencial precioso, a mí me ha solucionado ciertas cosas.
El software es gratis si lo usas sin fines comerciales.

La única diferencia qué veo es que usas el Xnormal, muy recomendable, pero nunca le he sacado la misma calidad que al Max o al Mudbox.solo usé un par de veces, eso sí, to dios lo usa. Saludos.

[Zerouks]

Handplane debe ser de las pocas cosas que no había probado. Gracias, aunque lo he probado y el problema persiste, quizás con menos intensidad (no he llegado a compararlos).

También debo decir que he probado normals bakeado en 3DMax. ZBrush no es nada recomendable para crear normals para videojuegos, ya lo he probado y tiene varias desventajas.

Cada vez creo más que se trata de un problema de udque con el tema de calcular luces. Cuando calcula las luces y crea el lightmap, en teoría la luz no está afectando al modelo y sin embargo, en este sigue funcionando su especular como si hubiera iluminación. No tengo ni idea qué es lo que hace UDK para hacer esto, pero creo que ahí reside el problema ¿No existe ningún parámetro en las luces u otro sitio para controlar esto?
Estuve mirando en polycount esto: http://www.polycount.com/forum/showthread.php?t=97434 ¿Alquien sabe que es eso de los 3 pointshader?
Fiz, lo que dices sobre los smoothing es verdad, pero tiene peros. Lo de separar los smoothing groups sirve para cualquier objeto y bien hecho puede ser visualizado en cualquier aplicación prácticamente igual. De verdad. Tengo este tema bastante trillado Si mal no recuerdo EarthQuake lo explica en este hilo: http://www.polycount.com/forum/showthread.php?t=81154.

En udn también hay algo sobre el tema, solo que su método es aún más bestia y detachan los smoothing groups (Detached Smoothing group method): http://udn, epicgames.com/Thre/NormalMapProcessing.html.

El problema ha llegado cuando udque ha calculado las luces. Con luces en tiempo real no pasa. Un saludo.