¿Cómo evitar seams en lightmaps de UDK con geometría biselada?

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:

Archivo adjunto 186871
Archivo adjunto 186875

Este cubo tiene un smoothing group para cada cara:

Archivo adjunto 186872

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

Archivo adjunto 186873
Archivo adjunto 186874

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.

Archivo adjunto 186870

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.

-- IMÁGENES ADJUNTAS --
https://foro3d.com/attachment.php?attachmentid=186870
https://foro3d.com/attachment.php?attachmentid=186871
https://foro3d.com/attachment.php?attachmentid=186872
https://foro3d.com/attachment.php?attachmentid=186873
https://foro3d.com/attachment.php?attachmentid=186874
https://foro3d.com/attachment.php?attachmentid=186875

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.

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.

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.

Archivo adjunto 186883
Archivo adjunto 186884

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.

-- IMÁGENES ADJUNTAS --
https://foro3d.com/attachment.php?attachmentid=186883
https://foro3d.com/attachment.php?attachmentid=186884

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.

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.

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.

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.

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.

Archivo adjunto 186908

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

-- IMÁGENES ADJUNTAS --
https://foro3d.com/attachment.php?attachmentid=186908

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.

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.

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.

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:

Archivo adjunto 186949

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):

Archivo adjunto 186945
Archivo adjunto 186946

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: Archivo adjunto 186948, 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.

-- IMÁGENES ADJUNTAS --
https://foro3d.com/attachment.php?attachmentid=186945
https://foro3d.com/attachment.php?attachmentid=186946
https://foro3d.com/attachment.php?attachmentid=186948
https://foro3d.com/attachment.php?attachmentid=186949

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.

Cita:

---

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.

Cita:

---

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.

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.

Cita:

---

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?

---

La cosa no es así amigo, el especular siempre va a afectar al modelo, (excepto en ciertas gI) si no, no tendrías normal, el normal lo ves en gran parte por el specular si no nada, de todos modos en el 4 han quitado todo eso, el especular casi no esta.

Esos problemas nunca los he tenido con UDK, y llevo muchos años como technnical artist con UDK, a ver los he tenido y siempre se han arreglado, la cosa es que ningún modelo te va a pasar la prueba del algodón con una Shader blanco nuclear y tan pocos polígonos.

De ZB ni idea, no lo uso, yo los normal los saco del 3ds Max o del Mudbox, y los paso por ese programa cuando se ponen tontorrones, ahora no tengo instalado el UDK si no hacía una prueba.

Se me ocurre que desactives el oclusión del lightmass, igual se te está poniendo tontorron.

Y no le hagas mucho caso al UDN, si ves algunas cosas que cuentan lo flipas. Saludos.

Cita:

---

la cosa es que ningún modelo te va a pasar la prueba del algodón con una Shader blanco nuclear y tan pocos polígonos.

---

Tienes toda la razón. La verdad es que una vez que el modelo tiene el diffuse y eso, estas cosas apenas se notan. Yo lo planteo más que nada porque en un escenario modular las piezas puede acabar viéndose desde diferentes ángulos y en estos caso el problema es inevitable.

A ZBrush los dos problemas que le encuentro son que el normal que bakea queda demasiado plano y el método al no usar cage transfiere los detalles justo donde se encuentra la división. Esto es un plus en algunos casos, pero en otros es preferible hacerlo mediante cage. 3DS Max y xnormal bakean mejores Normal Maps. Yo personalmente uso xnormal porque se pueden cargar modelos de muchos polígonos sin que el programa sufra.
¿En ue4 se siguen usando lightmapsí Cuando apareció la elemental demo si no recuerdo mal leí que hasta habían quitado la opción de crearlos. Lo que pasa es que más tarde apareció otra noticia de que habían eliminado la iluminación que se usaba en esa demo porque consumía mucha potencia (real-time GI voxel cone-tracing) y para qué fuera más fácil portar juegos a smartphones. No sé si al final volvieron a poner la opción de crear lightmaps o no. Saludos.

Claro, la cosa es que con diffuse las guarradas se disipan, has probado a quitar el occ de las opciones del lightmass.

Cita:

---

y para qué fuera más fácil portar juegos a smartphones.

---

Estos no tendrían que ser smartphones tienes que ser NinjaPhones.

Por ahora la opción de lanzar Lightmaps continua, es cierto que la luz dinámica no mata tantos FPS como antes, y que la calidad de ahora no tiene nada que ver con la de antes, es otro mundo, pero la opción continua, voxels, eso sí que traga. Saludos.

Lo del Occlusion lo probé también, pero no dio resultado. Al final creo que la mejor opción va a ser dejarlo en 1 smoothing group y usar más geometría. Si total, cada vez los modelos son más complejos. Saludos.

Ya te digo, tu mete polígonos que no pasa nada, el otro día le meti, un tesellatión 4 a un terreno en unreal, pila polígonos tenía eso mesh blanco, a ver, bajo unos cuantos FPS, pero nada serio. Saludos.

Objetivo localizado y destruido. Misión completed.

Me he dado cuenta cual era el problema. Realmente se trataba de 2 problemas.

Uno tenía qué ver con lo que comente unos mensaje atrás. UDK además de crear los lightmaps añade otro specular en las partes de sombra del modelo para añadir realismo. El caso es que este segundo especular como que choca con el specular original y potencia las costuras que tenga el objeto. ¿La solución? Quitarlo. Solo se elimina este segundo especular, el original se mantiene, el objeto queda como cuando la luz es dinámica, pero con lightmaps creados. Realmente cuando iluminamos un objeto en una aplicación de 3d con un material estándar esto es lo que obtenemos (pero sin lightmaps claro).

Como este segundo especular ha sido quitado, el Shader baja en instrucciones y esto nos ofrece la posibilidad de añadir una textura de reflexión para añadir el realismo perdido.

El segundo problema tenía qué ver con los lightmaps. Al usarlos de baja resolución las zonas de cortes también se potencia, ya que no se sombrea bien del todo. La solución. O aumentarle la resolución o asegurarte muy bien de que hay el suficiente espacio entre las islas de las UVS.

Y así es como tenemos nuestro objeto libre de seams (o casi).

Conclusión, solo si estáis tan flipados como yo es recomendable hacer esto, porque la verdad es que el problema es mínimo, no sé si pasa con otros motores y cómo se dijo antes, los objetos cada vez son más complejos y cuanto más complejas son las geometrías menos problemas de seams en el normal.

Yo que soy un exagerado.

Lo del segundo especular no me ha quedado claro? Pero bueno, hay una opción para qué al Shader no le afecte el especular, yo se la quito siempre para FX, pero para otros modelos no, si solo tienes una luz solo tienes un specular, eso es así, ese segundo especular no se ande sale.

Si ves que no te cuesta publica una imagen a ver si sabemos lo que es ese segundo specular. Saludos.

Udque lo llama specular lightmap o algo así:

Archivo adjunto 187152

Yo diría que más que un especular es un efecto que le meten para simular reflejo. El caso es que potencia la seam. Saludos.

-- IMÁGENES ADJUNTAS --
https://foro3d.com/attachment.php?attachmentid=187152

Se nota menos, pero claro, te has cargado parte del especular, lo bueno es que investigas, eso está bien señor, y lo que has aprendido de los normal y de la luz, eh.

De todos ya te digo que ni un solo modelo pasa un Shader blanco, siempre se ve algo. Saludos.

La verdad es que esto si no se es tan exagerado como yo con el tema de las seams no hay que darle mucha importancia. Si no te paras a buscar seams ni te das cuenta. Saludos.

Hola Zero y Friz.

Llevo muy poco tiempo con el UDK aprendiendo por mi cuenta y tengo un problema con los módulos y sus uniones que me trae de cabeza y si no lo resuelvo no puedo avanzar. Los módulos son, uy sencillo, no quería complicarme en mí primeras pruebas, son de 4x4preguntaque he ido rotando para dar aletoriedad, las seams se notan un webo en horizontal y menos en vertical, no lo entiendo.

Me he visto varios tutoriales, he intentado desactivar la specular que comenta Zero y sigo sin eliminar las unioniones entre módulos. He subido la resolución del lightmap y nada, ahora la tengo a 128 y creo que tendría que ser suficiente, también he dejado entre islas 4-5 píxeles y las UVS del lightmass coinciden con la regilla de 128, en el ejemplo le he quitado el normal y el specular al material por si fuese de eso, pero tampoco. Suelo intentar quebrarme la cabeza antes de preguntar porque así se aprende, pero llevo ya tres días perdidos intentando mil cosas y nada por eso os pido alguna sugerencia o ayuda por favor. Os dejo un par de imágenes. Saludos.

-- IMÁGENES ADJUNTAS --
https://foro3d.com/attachment.php?attachmentid=189588
https://foro3d.com/attachment.php?attachmentid=189589

Por la imagen, diría que la seam no se debe al specular, es una línea negra y eso es problema de sombreado.

Lo que comente unos mensaje más atrás sobre quitar el specular en el material, pienso que es mejor olvidarlo, porque trae consigo un problema, si en la escena tienes luces que no afecta de forma dinámica a los staticmesh no existirá specular en él por parte de estas fuentes de luz. Así que mejor dejarlo. Siento haber confundido.

Esa línea negra puede aparecer o porque el segundo canal de UVS no sea correcto del todo o por un problema con los módulos y UVS. Que mejor te dejo este link seguro que lo ves más claro: http://worldofleveldesign.com/catego...-and-seams.php.

Creo que deberías de probar otra combinación con las UVS del segundo canal, porque en la esquina derecha superior se ve también una línea vertical negra y eso sí que deber ser problema de las UVS exclusivamente. Muchas veces, cuanto menos trozos tengas en este segundo canal de uvs, mejor. Aunque aún mejor pienso que es hacer pruebas, porque esto que digo también pienso que es relativo. Saludos.