Sugerencias con la pesadilla de los normal maps

[Zerouks]

Desde que empecé con los Normal Maps, he tenido una pesadilla continua. No encuentro forma humana para lograr una proyección en condiciones sin tener que retocar luego los Normal Maps o hacer otros trapicheos (no en todos los casos, pero si en algunos), he hecho 3 trillones de pruebas. Y nada, siempre, siempre hay algún problema. Y ya entre locura y desesperación y haber leído otros 3 trillones de workflow etc. Me decido a preguntar, porque esto no es normal (nunca mejor dicho).

Uso xnormal para las proyecciones. Tengo entendido que se puede importar lo necesario para qué la proyección se haga correctamente, por eso de que cada programa usa una forma de calcular los Normal Maps. Y bueno, en teoría así es. Yo hago la proyección y luego en el visor de xnormal se ve perfectamente. El problema viene cuando lo llevo a otra aplicación.

En este caso en concreto, hablo de udque y este workflow: http://udn, epicgames.com/Thre/XNormalWorkflow.html Supuestamente siguiéndolo, cómo se importa del objeto original con lo necesario (no estoy seguro si el nombre es tangent basis, normals & binormals o como), el resultado debería ser similar al del visor de xnormal. Sin embargo, no es así. Algunas veces parece quedar mejor y otras peor, pero nunca bien, se nota sobre todo cuando le añado specular al objeto y como, por ejemplo, si lo que he hecho es un cubo, las caras parecen no ser lisas (algo como el ejemplo antiguo del mismo workflow del enlace).

Y yo me pregunto. ¿Qué es lo que pasa aquí?
Y también me pregunto. ¿No hay una maldita forma de proyectar un normal que sirva para cualquier aplicación? :/ He tenido Normal Maps que funcionan prácticamente igual en varias aplicaciones si antes he hecho un smoothing group separando caras diferentes en vez de dejarlo todo en 1, el problema de esto es que no siempre me funciona, y la mayoría de veces me quedan unas seams horribles dónde está la división entre cara y cara suavizada.

En fin, que esto parece una lotería. A ver si alguien me puede iluminar. Gracias y saludos.

[Fiz3d]

Pues no sé yo no suelo tener problemas.nunca usé el Xnormal, los normal los saco del 3ds Max o del Mudbox en modo tangencial y punto, antes me mataba con el suavizado de normales, creaba un grupo donde metía todas a 0, ahora nada, como viene, ya se encarga el normal de dejarlas bien.

Incluso si el objeto de destino es un plano, no pierdo el tiempo en proyecciones, pillo el de alta y creo un mapa de alturas a mano, un gradiente blanco y negro en un mapeado plano en Y, y después hago un render desde la vista TOP, con eso tengo un mapa de altura qué se lo paso al CrazyBump, y el me hace un normal supermajo.

Eso sí, siempre que calcules un normal que se tangencial, es lo único, cuando importes el normal usa TC NormalMap, NormalMap uncompress o Simple light vector, la mejor es normalmap, para qué se vea, como es lógico, tienes que tener especulares si no, nada de nada.

Si pones imágenes de cómo se ve tu normal, como es el modelo de baja y como es el de alta igual podemos saber qué falla. Saludos.

[Zerouks]

No sé cómo se sacan los normals en Mudbox, pero en ZBrush, según las pruebas que he realizado, es el que me da los peores resultados de todos si se trata de un modelowpoly. Como no se crea una proyección de un modelo high a uno low mediante una cage, sino que se usa el mismo modelo, con la misma topología, calculando las divisiones de cada polígono. A veces no queda muy exacto y se producen deformaciones o no se sombrea nada bien los bordes. Un horror XDAparte de ZBrush y xnormal también he estado probando 3Dstudio, pero al final acabo teniendo los mismos problemas que con xnormal. Modelos y normals maps usados en las pruebas: Prueba.rarEl último ejemplo (queda igual si se hace en 3dstudio) lo conseguí ayer mismo. Y es el que mejor resultados me da, por absurdo que me parezca si en las UVS corto cada cara del cubo no se ven las seams y sin embargo, si lo dejo como en los ejemplos anteriores, la misma proyección del normal me crea una Seam. Por otra parte, funciona bien en las aplicaciones que lo probé. Solo hay un problema, y es que cuando cálculo las luces en UDK, tiene en cuenta los distintos smoothing groups y me crea Seam. En el ejemplo que he puesto no se nota mucho, pero hice la prueba con una esfera, poniendo 1 smoothing group para cada mitad, y se notaba un montón. ¿Hay alguna solución a esto? Fiz, ¿sería mucho pedir que hicieras un workflow? Para ver con más detalle que haces exactamente. Es que sino voy a acabar pensando que hay cámaras ocultas en mí cuarto y me están gastando una broma o algo así Por cierto, suena interesante ese modo que usas para crear Normal Maps en superficies planas, saludos.

[Fiz3d]

El tema es que yo uso Mudbox y no me da problemas, tampoco he probado con objetos tan simples, la única diferencia entre lo que tú haces y lo que hago yo es que yo hago el modelo de baja en max lo paso a Mudbox lo modifico y después exporto el nivel uno o cero a max, así como esta lo mapeo, no toco más, después ese mismo objeto lo exporto a Mudbox (FBX) y le digo al Mudbox que lo use como modelo de baja, en las opciones le digo que lo haga como si fuese a ser usando en 3dsmax, ya que si le digo que es para Maya la lía parda, la cage la hace automáticamente dependiendo de un par de parámetros.

Una vez terminado me llevo ese normal a Crazybump y ahí le saco un poco más de chicha, así nunca he tenido problemas de invertir un eje ni nada.

Por cierto, lo usar uncompress mola, pero no te acostumbres, normalmente los programadores o los encargados de que el juego no se quede sin memoria, les salta una alarma en su cabeza cada vez que alguien usan un normal uncompress, si vas hacer algo transparente y se ve mucho ok, pero si no, hum el resultado se nota, pero se te come toda la memoria, y si se queda sin memoria, una consola lo que hace es bajar la resolución de los bitmap, así, sin contemplaciones.

Es normal que se vea mejor si las caras están separadas, al no estarlo el programa qué calcula el normal tiene que hacer una media entre todas las normales (dirección de las caras tomada de la media de sus vétices) por eso te hace esos degradados tan feos. Al separar esas caras se crean nuevas normales apuntando correctamente, ya que a esa arista qué une las caras le corresponde una normal de 45 grados (la media de dos de 90 º) pero si esas caras están separadas cada arista tendrá su normal correcta (esta es una explicación un poco perra ya que las aristas no tienen normales) creo que si haces un mapeado como el de arriba, pero le haces un break a las caras en el mapeado, te dará mejor resultado, aunque es complejo quitar ese línea negra,
Ya sabes, las caras juntas, pero sin compartir aristas.

Miraré lo de hacer un workflow pero no creo ser el más indicado ya que yo no me dedico a modelado, mi curre son los FX, lo que pasa qué ahora estoy en medio de un deadline y no tengo tiempo ni para respirar, ups me toca, de todos modos este tema es como andar en bici, llega un momento que aprendes y no sabes cómo ha sido. Saludos.

[Zerouks]

He hecho lo que me comentaste de hacerle el break, pero. El bitmap del normal queda mejor (como comentas, hace el cálculo de cada cara en vez de tener en cuenta todo el conjunto), lo que pasa qué una vez que lo aplico el resultado es muy parecido. Es como dices, el normal procura corregir el smoothing group, pero es que, después no se ve como debería el resultado. Es un poco raro, sobre todo teniendo en cuenta que el normal lo bakeo en 3dstudio, e incluso en los primero planos en 3dstudio se visualiza mal.

Dejo otro ejemplo del último método. Que la verdad estoy bastante contento con los resultados que da, me estoy dando cuenta que cuando calculaba las luces y salían seams era más problemas del lightmap que de otra cosa.



El corte para las UVS es el mismo del smoothing group y la verdad es que, así queda bien, incluso casi no se nota el corte de las Seam. Vamos, que parece que después de todo, las pruebas y todo lo que he hecho han servido de algo. Aparte de mis pruebas, le debo bastante del resultado a lo que comenta el creador del hilo al final del primer mensaje de este link: http://www.polycount.com/forum/showthread.php?t=81154 El truco está en crear una cage con 1 solo grupo de suvizado y cortar el objeto en el mapeado por el corte de los diferentes grupos de suavizados.

Fiz, si no tienes tiempo no te preocupes, de verdad. De todos modos, parece que he dado con la solución a mis problemas. Se agradece igualmente la intención. Saludos.

[Fiz3d]

Amigo ese normal es de todo un profesional al final vas a ser tu el que haga un tutorial.

Lo del normal es como un filosofía, tienes que pillarle el truco, puedes leer mil cosas y hacer mil tutoriales, que hasta qué no le pilles el truco después de mil prácticas y objetos tirados, no vas a aprender hacerlo bien.

Ya te digo que ando liado, pero como el Unreal se toma las cosas con calma para compilar shaders pues entre compilación y compilación me paso por aquí, pero veré lo que se puede hacer. Saludos.

[Zerouks]

Muchas gracias. Es así, mil pruebas. Más de un día que me he levantado y he intentado buscar la solución, me digo bueno, voy a mirar un ratio a ver si consigo solucionar esto. Cuando me he dado cuenta han llegado las 9 de la noche y ahí seguía haciendo pruebas.

Lo que pasa también que muchas veces te encuentras información por internet incompleta o que por alguna razón no funciona igual. Es como lo del workflow para UDK usando Xnormal. No sé si es que hay algo que han pasado por alto o que simplemente no funciona todo lo bien que yo pensaba. Al final hay que probar y probar.

Dejo esta imagen también del mismo hilo que puse antes, que me parece que es bastante interesante para comprender bien los normals maps.



La figura central y la de la derecha tienen el mismo número de polígonos y la derecha queda mejor que la del medio. A pesar de que la lógica dice que si biselas los bordes debería quedar mejor (al igual que la figura high), por la forma de proyectarse los normals es mejor usar la figura de la derecha. Saludos.

[Fiz3d]

Supongo que habrás leído esto, es como una mini biblia del Normal Map. http://wiki.Polycount.com/Normal Map/ saludos.

[Zerouks]

Si, gracias, ya la estuve mirando. Está muy bien.

Por cierto ¿Los Object-space normal map no se usan nunca? Es que esos eliminan el problema qué tenía al principio aparte de ofrecer un poco más de rendimiento. Y llevo un tiempo preguntándome si son usados en objetos fijos que no son deformados ni nada.

Lo ideal sería poder convertir un object-space en tangent sin tener que recurrir al modelow. Saludos.

[Fiz3d]

Puedes hacer normal en lo que te de la gana, los world funcionan muy bien, pero necesitan convertirlo en UDK, la verdad es que son los que mejor quedan, pero la instrucción transform de world a Tangent te come muchas instrucciones, una burrada con lo que no merece mucho la pena.

Lo bueno de esto es que hay mil opciones donde elegir, yo tenía un compañero que para cosas simples, los hacía a mano, tu veías el normal hecho por CB o ZB Max lo que sea, y el que se curraba el, y el suyo era mil veces mejor. Saludos.

[Zerouks]

Vaya, pero pintarlos es una locura ¿Qué consigue más detalle? Yo lo que si he hecho ha sido crear normals con montajes de algunas proyecciones simples. Pero eso de pintarlos es demasiado.

A ver si miro lo que comentas de usar otros tipos de normal en udk, que nunca he mirado de probar ninguno que no sea tangent. Saludos.

[Fiz3d]

No, pero había cosas que con proyección no quedaban bien, era imposible o tenía qué meter polígonos en la de baja, con lo que si lo hacía a mano sí quedaba con tenía qué ser, pero te hablo de objetos simples como un armario tipo taquílla, con la rejilla de ventilación. Saludos.

[Zerouks]

Ah ya comprendo. Aunque, si he entendido bien, hay una forma de proyectar el normal bien en modelos muy low. Usando un modelo high con la misma estructura del low. Por ejemplo, en vez de usar un cilindro high (como el de la imagen que puse) para proyectar los bordes biselados en uno muy low. Se puede usar uno como el low pero con bordes biselados (con todos los polígonos que haga falta para los bordes). En fin. Es lo que dices, hay muchas formas de hacerlo, que es lo bueno. Saludos.

[Fiz3d]

Justo y una cosa que no hay que olvidar es que un normal no es un bitmap, se representa como bitmap por comodidad y porque es la manera más fácil, pero la verdad es que un normal es un archivo de datos, o sea, no podemos andar editando un normal a loco, yo vi chapuzas como reordenar unas UVS y en vez de lanzar de nuevo el normal, reordenar el normal para hacerlo coincidir con el nuevo mapeado, te puedes imaginar lo que se veía después. Y por qué falla me decía. Saludos amigo.

[Zerouks]

Si, no se pueden rotar porque entonces los colores que definen una cosa pasan a otro lado y se produce el desastre Por eso me sorprende lo de hacer normals a mano, no tiene que ser nada fácil.