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.

-- IMÁGENES ADJUNTAS --

[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.

-- IMÁGENES ADJUNTAS --

[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.

-- IMÁGENES ADJUNTAS --

[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.

-- IMÁGENES ADJUNTAS --

[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.

[Fiz3d]

Hay gente que tiene cosas raras en la cabeza, pero el colega usaba trucos, el tenía unos normal de referencia, sabía qué hacer para simular 45 grados, o 90 grados. La verdad es que se los curraba bien.

Bueno supongo que, lo sabes, el color rojo y verde son vectores, uno da información sobre el eje Y y el otro sobre el eje X, al juntar esos dos ángulos, te da el ángulo exacto de hacia donde apunta ese normal, por así decirlo definen un punto en el espacio tridimensional, el Azul es la tangencial, si quieres aumentar la potencia de tu normal, por ejemplo, en UDK, (forma chapucera) tienes que multiplicar por un vector 3 donde X e Y conserven el valor 1, y el Z o sea el azul tiene que ser inferior a 1, no te puedes pasar mucho porque sale una chapa, pero para levantar un poco el normal te vale, para sumar dos normal en UDK, igual de chapa, tienes que descomponer en canales con component mask, por un lado puedes sacar X y Y y sumar el otro normal igualmente descompuesto en canales, hay gente que descompone los 3 pero yo no noto diferencia, después con append lo juntas todo, el la componente azul, vale el de los dos mapas, pero si uno está sacado en referencia a un modelo de alta y el otro es un simple detalle plano, es mejor que uses el sacado de un modelo de alta, si ver que guarrea mucho puedes usar un normalice, o subir el valor Z (azul). Saludos.

[Zerouks]

Eso último que comentas de sumar dos normals me interesa muchísimo. Hace meses miraba en halo reach como al hacer zoom en determinados objetos se podían ver nuevo detalles minúsculos, en ese momento no tenía ni idea cómo hacerlo, ahora se que se hace mediante un detail normal map repetido. Pero hace poco me di cuenta de una cosa aún más interesante, que se pueden enmascarar dos texturas. No lo he probado aún, pero es que, así incluso teniendo un Shader repetido varias veces pueden tener aspecto diferentes. Me alucinan esos trucos. Y desde hace unos días me pregunto si esto se puede hacer en 3DS Max y luego ser exportado a udque ¿o es mejor hacerlo teniendo e base udk? Me pasa exactamente lo mismo con el terreno, sé que se hacen con diferentes texturas pintando encima, pero no sé si esto se puede hacer en 3dstudio y exportarlo a udque o Unity. Lo digo teniendo en mente una demo reel, el video queda mejor renderizado en 3DS Max, pero creo que sería interesante llevar el escenario a Unity que con su webplayer puedes moverte por dentro. La otra opción es grabarlo directamente desde el motor. Vi en la web de un usuario del foro que tiene uno así y mola un montón. Saludos.

[Fiz3d]

Si amigo, el normal de detalle de toda la vida, de hecho, yo tenía echa la función en UDK, una caja donde por un lado pinchabas el normal del modelo, en otra el normal de detalle y unos valores para intensidad, tamaño, y rotación este último se lo quité porque una rotación se come un montón de instrucciones.

Eso de hacer cosas en uno y después render en 3dsmax, no se puede, no puedes pasar un Shader de UDK a max, hay un plug que te pone trasforma el editor de materiales de max en algo parecido al de UDK, pero soy muy generoso con lo de parecido. Saludos.

[Zerouks]

¿Cómo sabes si un material tiene demasiadas instrucciones? Supongo que todo dependerá del resto. ¿Hay algún límite por escena o algo así para una consola actual? También me pregunto cuantos polígonos y mb de texturas se usan actualmente como norma general.

He probado a poner en el canal alfa de un normal map un height map para hacer parallax, pero no funciona por como hay que conectar los nodos. Para qué funcionara tenía qué copiar la textura de nuevo para qué quedará bien. Estaría bien poder ponerlo en el canal alfa para optimizar más, a ver si lo miro de nuevo.

Lástima qué no se pueda pasar shaders de uno a otro. Si mal no recuerdo vi un vídeo de luminous studio que estaba integrado en Maya y lo que hacías en Maya podías verlo en tiempo real en el motor. Estaría bien que epic hiciera algo así con ue4.

Por cierto, lo de mezclar dos texturas me refería a algo así .

Lo que pasa qué estaba lelo y no había pensado que eso supone aumentar el número de polígonos de objetos que a lo mejor se pueden representar con un único cuadrado. Supongo que es preferible usar esto en objetos que requieran de más polígonos. Aunque imagino que también se puede hacer mediante máscaras. Saludos.

[Fiz3d]

Las instrucciones te la dice el editor de shader, en la esquina superior izquierda. ¿cuántas son muchas? Pues depende del objeto, y de cómo usemos ese shader, si lo usamos en un sistema de partículas con transparencia, pues hay que tener cuidado porque el overdraw es, por así decirlo, lo que más recursos come, imagina un emiter que suelte 100 partículas, que en un momento dado 20 partículas se ponen en línea una detrás de otra, o una encima de otra, como son trasparentes tu ves a través de ellas, ahora imagina qué el Shader que usan tiene 40 instrucciones, pues para calcular ese sistema, tiene que calcular 40 instrucciones, (operación matemáticas) multiplicadas por las 20 partículas, por el número de píxeles que ocupen en pantalla, por el número de frames que te esté dando el juego, y eso si solo tienes un shader, imagina qué ese sistema de partículas tiene varios emisores, por ejemplo, uno para fuego otro para humo otro para refracción otro par chispas, pues lo mismo con cada shader, esto se nos pone en algunos casos en millones de operación matemáticas por cada frame, y todo empieza desde las instrucciones del shader.

Por eso, en muchos juegos cuando vemos muchos efectos en pantalla la cosa empieza a ralentizarse.

Cosas a tener en cuenta, valor de plano, cuando más ocupe el Shader en pantalla, más píxeles a calcular, si el objeto es pequeño o esta a lo lejos, pues nos preocupamos menos, si es el personaje en tercera persona pues cuidado que además el skin se puede calcular por GPU, con lo que podemos tener una bajada de rendimiento muy grande, un efecto de posproducción, lo mismo, estos se pintan en casi último lugar con lo que es mejor no cargarlo mucho.

En estos casos el número de polígonos pues como mucho nos come memoria de video, y algo de GPU, hay que ser Discretos, pero vamos, con las herramientas que tenemos hoy, no tendría que ser un problema dejar la escena con un número de polígonos que no nos afecte al rendimiento.

He probado a poner en el canal alfa de un normal map un height map para hacer parallax, pero no funciona por como hay que conectar los nodos.

Tu no puedes, por así decirlo, realimentar un bitmap con información de dicho bitmap, por ejemplo, si tienes un normal, no puedes sacar de ese mismo normal información que afecte al ese normal, tienes que copiar el normal y hacerlo desde la copia, casi da igual porque en memoria ocupa lo mismo.

Por otro lado, si pones un alfa en un normal tienes que importarlo con la compresión NormalMap alfa si no, pasara del alfa.

Por cierto, lo de mezclar dos texturas me refería a algo así http://www.youtube.com/watch?v=7UNpThobAkY.

Eso es un vertex color, en el Shader tienes puestos los dos o tres bitmap distintos, pones un lerp (interpolación linear) y en el alfa pones un canal del vertex color, en A y B los distintos bitmaps o los shaders completos, después pintas con la herramienta como ves en el video.

En el UDN tienes unos cuantos tutoriales sobre el tema. Saludos.

[Zerouks]

Fiz ¿cuándo vas a publicar un manual de udk? Lo digo porque sabes de todo incluso cosas que no te afectan directamente en tu trabajo.

UDN está genial, viene de todo. Tenía qué haber mirado antes de decir nada. A veces es que me guardo páginas y cosas así, y como estoy haciendo otras cosas, pues se me olvida mirar luego.

Los lerp he visto que se pueden hacer con texturas como alfa qué definan que se ve de una y de otra. Vamos, que no es necesario el Vertex Paint, no entiendo que ofrece vertex color que no se pueda hacer así, porque para usarlo hay que tener objetos con un determinado número de polígonos. Saludos.

[Fiz3d]

El vertex color te crea la máscara de transición, por eso al pintar lo que hace es darle a ese alfa qué metes en el Lerp un valor superior a cero, el tipo que se curró ese Shader le ha dado mil vueltas para no necesitar una malla con muchos vértices, creó un sistema de transición para qué no quede cutre, con estoy puedes hacer que un objeto se deforme de forma interactiva, por ejemplo, al dispararle, imagina disparar a un objeto de metal, y que la malla se redefina y se deforme, a parte de cambiar el color, esto lo hice, hay un ejemplo de cómo llegar a esto en el UDN.

Fiz ¿cuándo vas a publicar un manual de udk? Lo digo porque sabes de todo incluso cosas que no te afectan directamente en tu trabajo.

Qué va hay un montón de cosas que se me escapan, de animtre ando pez total, de editar BSPs soy lento con ganas, hay varias cosas que me gustaría controlar, pero no tengo tiempo, conozco a un par de fieras que podrían enseñar a los de Epi, c, sobre todo uno. Saludos.

[Zerouks]

Supongo este es ejemplo: http://udn, epicgames.com/Thre/Devel...formation.html Aunque para eso hace falta dx11. Mirare a ver si se puede hacer mediante World Position Offset. Para casos así sí, pero si lo que se quiere es mezclar dos texturas (como el vídeo que puse), no le veo mucho sentido aumentar la malla poligonal para mezclar dos texturas si se puede añadir un alfa a una de ellas que defina el recorte.

El BSPs de todos modos no se suele usar, ¿no? Pudiendo importar los objetos de otros programas 3D. Saludos.