Tamaño textura

Buenas. Tengo una duda sobre las texturas para motores de juegos.

En el caso de tener que texturizar una casa pequeña, ¿es mejor hacer una sola textura grande de 4096 px, con varios objetos metidos en ella como muros, ventanas, puertas, o separarla en texturas más pequeñas de 1024 o 512 para cada objeto? Supongo que cargando una grande el motor funcionara mejor ya qué manejara una sola textura para varios objetos y necesitara cargar menos ficheros, pero no lo tengo claro. La única ventaja qué veo en separar cada objeto con texturas más pequeñas es que, por ejemplo, una ventana se podría usar por separado en otros modelos. En mi caso tengo una casa con unos muros en los que necesitaré una textura de 4096 o 6144 para qué se vean bien y me queda sitio para meter más cosas, me parece un desperdicio dejar ese hueco libre sin aprovecharlo para otros objetos. ¿Usar texturas de 6144 o 8192 es una burrada o se pueden usar algunas (pocas) para nex-gen? Muchas gracias. Saludos.

Si te sirve de ejemplo, yo utilizo UDK, y tengo que usar texturas de 512, porque es la única forma qué he conseguido que funcione. Hace tiempo leí que el UDK solo podía usar texturas de ese tamaño o menos, pero desconozco si han acutalizado a 1024. Si te aseguro que 4096 no funciona. Un saludo.

Si te sirve de ejemplo, yo utilizo UDK, y tengo que usar texturas de 512, porque es la única forma qué he conseguido que funcione. Hace tiempo leí que el UDK solo podía usar texturas de ese tamaño o menos, pero desconozco si han acutalizado a 1024. Si te aseguro que 4096 no funciona. Un saludo.

No amigo, UDK siempre ha podido usar texturas de 4096, que es un límite teórico en un montón de motores, no sé dónde has leído que no puede, pero no es cierto, yo he usado texturas de 4096 en UDK, otra cosa es que tú gráfica no lo soporte, o que lo tengas limitado en el ini, de hecho, el tamaño medio es de 2048.

Respecto a qué es mejor, esto puede tener ríos de literatura técnica, depende de muchas cosas.

Si es para consola cuanto menos mejor, excepto la nuevas, la 360 y la Ps3 tiene una memoria muy limitada, en resumidas cuentas serían unos 256 megas para todo el apartado gráfico, modelos, texturas, partículas, animaciones, te aseguro que es muy poco, para PC es otra cosa, sigue existiendo un límite, pero la gráfica más tonta tiene 1 Gb de memoria, ahora no es raro encontrarlas con 2 incluso 4 Gb, y sobre todo, también existe la Ram donde se usa para intercambiar.

Hace unos años, no muchos, se usaba una técnica llamada atlas, más o menos es lo que tú describes, esto consistía en, imagina qué tienes un pueblo, con sus casas, todas más o menos distintas, sería una pena tener que crear texturas de 512 para cada casa, al final te haces con un montón de texturas a una resolución muy baja, lo que se hacía era crear una textura enorme con Tejados, otra con paredes, otra con suelos, con 4 texturas de 2048, y unos alfas para hacer mezclas que cambiasen color o distribución, podrías tener 30 casas y no notabas que fuesen iguales, se podía añadir mapas de suciedad, además vertex color para hacer más aleatoria la mezcla, tienes que tener en cuenta que una textura de 1024 es 4 veces mayor que una de 512, y en una de 4096 entran 16 de 512, ahí se gana resolución, de hecho, Nvidia, tenía una herramienta para hacer atlas, no era para usar en UDK claro, pero le dabas 30 texturas de 512, y te las metía en un par de 4096, y remapeaba, el mapeado era un desastre, pero funcionaba, supongo que, miraría el color del textel y en función de eso creaba la textura.

Lo que se suele hacer ahora es lo que se llama Tileset, tienes un montón de objetos ventana, 4 o 5 distintos, cada uno con su textura o no, o usando muchas, también tienes un montón de paredes, puertas, todo para componer el pueblo, y lo montas, la cosa es que como todo siempre tienen quemantener un estilo, todo se distingue así, modelos hi-tech, pues tiene un motón de objetos de ese estilo, o góticos, o modernos, o no sé, el diseño que se le ocurra al concept.

El tema qué planteas no se suele plantear en una producción porque en un juego normal la optimización es más globalizada, o sea, no se piensa en un solo prop, porque la gente ya es lo suficientemente profesional para saber que usar, la cosa se basa en el nivel entero, en lo que vamos a tener cargado en memoria en X momento, y ahí es donde se optimiza, imagina una papelea en una calle, solo se usa en un sitio, esa papelera carga 3 texturas y modelo y no llena nada, ahora imagina un banco de la calle, tenemos 250 sembrados por todo el nivel, pues esas 3 texturas y ese modelo es correcto, pero la papelera qué no se usa ocupa lo mismo en memoria qué ese banco, tenemos dos opciones, o llenamos el nivel de papeleras o la borramos y nos ahorramos unos megas.

También tienes que tener en cuenta una cosa, aunque tengas una textura de 4096 no siempre va a mostrar esa resolución, los motores usan mipmapping, el formato de texturas, le pases lo que le pasas TGA (*.jpg) PSD, da igual, siempre va a ser DS, este formato tiene cosas interesante, una textura de 1024 siempre va a ocupar lo mismo, y otra son los mip, lo que hace el motor al convertir a este formato es guardar versiones pequeñas de la textura, si le pasas una 1024, te va a guardar dentro del mismo archivo, una versión de 512, otra de 256, 128, 64 y 32, y usara dependiendo de la distancia una u otra.normalmente la máxima se usa si estas pegado al modelo.

Si haces una sola casa, y es un simple prop pequeño en pantalla, los artistas técnicos y los programadores te pueden morder si usas una 4096, mejor usas 1024, con algunas máscaras, un Shader chulo para qué mezclar bien, un mapeado correcto y esas cosas vas bien, por ejemplo, en vez de hacer todo el tejado en la textura, metes la cuarta parte y lo tileas en las Uvs, para eliminar el Tile usas una máscara de suciedad o lo que sea, con esto ganas 4 veces de resolución.

Hay que ver cómo es el nivel para saber que técnica usar, las texturas siempre se reutilizan, y con los nuevos motores y toda la potencia a nivel de shaders que tienen, incluso el UDK, casi puedes trabajar en procedural, y con nada te creas unos Shader con las mismas texturas que puedes usar en un montón de sitios y que parezcan distintos, si a todo esto añadimos los instance shaders del UDK, pues la variación es infinita con muy pocas texturas.
Otra cosa es que el specular map puede ser de menos resolución, y meter el glosines dentro del alpha del spe, c, yo he llegado a meter, porque hay un límite de texturas a usar en un Shader (16) cada color del normal (rojo y verde) en el alpha qué tenía vació en el diffuse, cada cada color en un diffuse, (terrain material) componerlo y sacar la tangencial a mano (azul).

Otra cosa qué has dicho. 6144 no creo que lo soporte, no por tamaño que creo que tampoco si no porque tiene que ser potencia de 2, las texturas tienen que ser, 32, 64,128,256,512,1024,2048,4096, otra cosa de dice que no, 8132 ya te digo que no lo sé porque nunca lo he necesitado, me parece una locura, yo uso un 4096 para él dome del cielo, o para terrenos, meter 4 veces eso en un objeto no se hace, estas hablando de 66 megas de textura, mover esa cantidad de datos ya lo veo forzar mucho, estoy casi seguro por no de decir al 100% que nunca se ha usado esa resolución en un modelo, creo que el Motor TEch5 es el único que pude con texturas de hasta 32k, pero por otro lado, también estoy seguro que lo que hace partirlas en trozos.

Yo ahora uso Unreal4 en ningún ejemplo, y mira qué viene cosas impresionantes como ejemplo, se usa ese tamaño. Saludos.
¿veis? Ya os dije que sobre esto se puede discutir mucho.

Vaya, está claro que sabes más que yo. Se nota qué acabo de empezar con UDK. Lo de las texturas a 512 lo leí hace un tiempo no sé dónde (y está claro que quien lo escribió sabia tanto como yo) y lo di por valido. Muchas cosas de las que hablas me cuesta pillarlas, pero me has aclarado sin quererlo bastantes dudas, así que, gracias.

En serio usas Unreal4? Vaya, que envidia.

No te preocupes amigo, para eso estamos en los foros para aprender y compartir.

Que no te de envidia no, desaprender 7 años de curre con un software para casi aprender un montón de cosas de nuevo, no mola tanto, pero bueno, es para mejor eso seguro. Saludos.

Seguro que para bien si. Pero tanto cambia el asunto para tener que desaprender lo que sabes? Por lo poco que llevo por aquí, he visto que controlas muy bien el UDK, una lástima qué eso se pierda.

No, a ver, si controlas de UDK o del 3, tienes gran parte recorrida, pero para los artistas técnicos se puede decir que el cambio es más grande, creo que para mejor, pero bueno, siempre piensas, vaya, esto en el 3 lo tendría en 2 minutos. Saludos.

Hola, muy interesante y nutritivo el post. En mi caso uso Unity, y recientemente vi esta empresa. Supongo que estarán trabajando para integrarlo en UDK. Parece que la barrera de las texturas se la han cargado.
[url]http://amplify, pt/Unity/[/url].
o Drag & drop integration, no coding required.
o Multiple virtual textures up to 2M x 2M, or 4 Terapixel.
o New real-time WYSIWYG editing mode with improved workflow.
o New high-compression, high-performance texture compression.
o Spherical page detection system, for fast view rotations.
o Static batching support.
o Light-map and Displacement-map support o Unity Terrain support.
o Anisotropic filtering.
o High dynamic range (HDR) texture support.
o World Machine, MARI and MODO integration.
o Oculus Rift/VR support.
o Hardware sparse texturing support.
o Mobile suppor.

Y eso, más leña. Saludos.

Muchas de esas cosas ya están incluidas en el Unreal, por ejemplo, eso, [URL]http://amplify, pt/Unity/amplify-color/[/URL] yo los conozco como LUT, es muy útil en postproducción, haces una captura de pantalla, en potochó dentro de la misma imagen capturada metes la imagen de referencia qué te proporciona EPi, c, modificas la captura, color, contraste etc, hasta tener algo que te guste, dicha modificación le afecta también a la imagen de referencia, al aplicarsela después en postproducción dentro del motor tendrás la misma corrección que hiciste en photoso, p, o más o menos. Después los desenfoques también están, como las manchas lumínicas, aberración de color, fallos en las lentes, ajuste de la pupila, de hecho, si no lo quieres lo tienes que desactivar que por defecto esta activado.

Por otro lado, el Unity me parece un pedazo de motor, mucho más abierto que el UDK, eso sí, tienes que ser mucho más técnico con Unity si quieres buenos resultados, creo que están destinados a proyectos distintos, los de Unity han sabido pillar el nicho que Epic dejó, y la verdad es que no sé porque ha desaprovechado ese tipo de negocio, me refiero a pequeños proyectos, smartphones y esas cosas, UDK es muy bueno, y si lo optimizas bien, lo puedes meter en un terminal de gama media alta sin problemas, incluso de gama media. Pero Unity les ha ganado de calle, y como continúen así, no me extrañaría dentro de unos años ver un triple A super ventas hecho en Unity, poco a poco los grandes del sector, sobre todo técnicos, están mirando mejor a Unity de lo que lo hacían hace unos años. Saludos.

Gracias por vuestros comentarios, me han sido de ayuda para tener un poco más claro este tema.

Os dejo un link a una web en la que se comenta qué una textura de 512 px, para qué se vea bien en UDK sin falta de resolución tendría cubrir como mucho 3 o 4 metros, más o menos la altura de una planta. En la web hay algunos tutoriales que tienen muy buena pinta. [url]http://www.chrisalbeluhn.com/Texture_Density_Tutorial.html[/url]. Saludos.

A ver, estamos un poco anclados en el pasado, un technical puede hacer que un par de texturas de 512 luzcan más que una de 4096, ahora ando liado para leer el link ha puesto el compañero Karlitros, pero no se puede medir la calidad de una textura en area, una 512 funciona bien hasta un tamaño de 4 metros, depende de dónde esté el observador, ¿no? Es que en videojuegos no existen tamaños fijos, puedes tener tu objeto que mide 4preguntacuadrados en el último plano que ocupa un 1% de pantalla y los 512 te sobra por todos lados, pero ten ese mismo modelo ocupando un 99% de pantalla, podemos ver los píxeles como camiones, aunque está afirmación sea cierta, tampoco lo es del todo porque nos falta un dato, la resolución al que tenemos el juego, si nuestra resolución es muy alta las texturas nos cantaran más que si es baja.

Todo se resume en una frase, el tamaño de la textura depende de lo que esté haciendo, nada más, hay cosas como el terreno que tienen que tener un tamaño grande, o el dome del cielo, otras cosas como un pájaro que está lejos pues no, lo que no podemos hacer es, cómo se suele ver en algunos juegos, tener texturas de alta mezcladas con texturas de baja, o ya lo peor, un mapeado que hace ciertas partes del modelo tengan demasiada resolución frente a otras que se ven pobres, en serio, si pilláis un modelo de un juego nuevo como el último COD, yo lo jugué a tope, las texturas dan asco, pero eso sí, todos los modelos están a la misma resolución, todo pega con todo, no hay nada qué sobresalga del resto, otra cosa es que la parte de arriba de un tanque, zona qué tiene un gran valor de plano, la tengan echa un cristo, con una resolución de juegos de los 90. (todo para qué entre en las nuevas consolas, seguro).

Para dominar este tema hacen falta muchos años, se nota cuando un modelo está bien mapeado, todas las Uvs correctas, con resoluciones de texturas adecuadas, menos mal que no me encargo de eso, porque es complejo con ganas, yo hago la parte diver. Saludos.

Que interesante. Esta siendo muy educativo este mensaje. La verdad que el tema de texturas es una movida seria. Considero que en consolas el trabajo es más arduo puesto que la limitación de la memoria, supongo que, debe ser un auténtico quebradero de cabeza. Supongo que en PC hay más margen.

Oye Fiz3d, si puedes decirme, esto que pones más arriba los mip, lo que hace el motor al convertir a este formato es guardar versiones pequeñas de la textura, si le pasas una 1024, te va a guardar dentro del mismo archivo, una versión de 512, otra de 256, 128, 64 y 32, y usara dependiendo de la distancia una u otra., sabes si esto que comentas, se refiere en UDK a los LOD? O se me están mezclando mucho las cosas.

Por añadir algo más de información (hey, Fiz, cuanto tiempo), a bajo nivel se presentan varios problemas:
-Muchas tarjetas gráficas (sobre todo en dispositivos móviles) no aceptan texturas cuya anchura y altura no tengan un número de píxeles que sea potencia de dos. En las tarjetas grandes (de PC) se las comen de todos los tamaños haciendo una preconversión interna por hardware.

Muchas tarjetas gráficas (sobre todo en dispostivos móviles) no aceptan texturas de más de 2048x2048 por simple falta de memoria. En PC suelen tener considerablemente más, pero tampoco mucha más (y no suele hacer realmente falta).

Una de las partes más lentas en el dibujado en pantalla corresponde al cambio de textura para dibujar cosas; cuantos menos cambios de textura tenga qué hacer la tarjeta, mejor será el rendimiento.

Como comenta Fiz, es cuestión de experiencia y buen gusto el aprender a reutilizar al máximo texturas con un tamaño que no exceda unos 2048x2048, y aplicarle todo tipo de trucos sucios para qué luzca.

En cuanto al distinto tamaño de texturas que preguntas, es lo que se denomina mipmapping y es efectivamente el LOD de las texturas. No es específico del motor, tiene más que ver con que el formato de textura lo soporte.

Ostia Mars, qué bueno leerte de nuevo por aquí, he visto en estos días que andas más activo, me alegro.

Toda la razón en lo que dice Mars, aunque de Smartphones no sé demasiado, tienen infinitamente más limitaciones que una consola y que por supuesto el PC, en UDK casi no puedes usar shaders complejos, los alfas con cuentagotas etc.

En cuanto a gráficos lo que más pesa en UDK es el overdraw, en FX el overdraw se usa sí o sí, esto consiste en tener un plano con alfa y a través de él ver otro y después otro y otro, esto consume mucho ya que tiene que calcular ese píxel varias veces tantas como planos super puestos, el cálculo se multiplica por X, eso pasa sí o sí en los efectos de partículas como humos y esas historias, ahora no pasa tanto, pero antes si te metías dentro de un humo los frames bajaban escandalosamente.

Trucos sucios he usado bastantes, el más usado es el multicanal, en FX se usan muchos ruidos, (noise) para varias cosas, dar aleatoriedad, se pueden usar para alterar las UVS, hacer distorsión, pero tener siempre el mismo ruido canta, los ruidos suelen ser mapas en blanco y negro, y claro, un bitmap normal tiene 4 canales, RGB y A, es una pena usar una textura para solo un canal, y un poco lío usar un diffuse o lo que sea para meter un ruido en su alfa, además de ser bastante desordenado, cosa mala en este trabajo, pues para ahorrar, ser ordenado y que todo quede bien, hacemos 4 ruidos, distintos, y dentro de Photoshop metemos cada uno en un canal (RGB. A,) en un solo bitmap, esto ocupara lo mismo en memoria y tendremos 4 ruidos dsitintos, casi cualquier sistema de shaders te permite sacar los canales de una imagen, UDK también, esos ruidos los puedes mezclar o lo que sea para generar aleatoriedad.
Después como comenté antes, he tenido que aprovechar los alfas de dos bitmaps para meter los dos canales R. G de un normal y después componerlo y sacar la tangencial (Z) que cómo era un simple plano es azul (128 128 256), eso sí que es un truco guarro, pero no había otra forma, hay un límite en el número de bitmaps que se pueden usar en un shader, 16 distintos.

El mip mapping es lo que comenta Mars, es como un LOD controlado automáticamente por el motor, en versiones Unreal se puede controlar dentro del Shader qué nivel de mipmaping quieres que se use, esto no es para ahorrar ni nada, es simplemente un truco para hacer desenfoques, a ver, qué ahorras seguro porque cargas una textura de baja, pero no he visto a nadie usarlo con ese fin, yo, por lo menos, solo he usado para desenfoques, por otro lado, hay veces que no te interesa qué se haga mipmaping, sobre todo en FX, imaginad que tenemos un bitmap para hacer polvo, formado por puntos muy pequeños o un ruido muy pequeño, con variaciones entre píxeles, si el LOD nos elimina 1 de cada 4 píxeles, tendremos un flickeo muy incómodo, o de ser puntos de polvo pasa a ser una mancha cuando nos alejamos, en estos casos se fuerza para qué no haga mipmaping y siempre nos muestre el de más calidad, aunque esto nos puede traer problemas con lo que tendremos que cambiar el filtrado (antialiasing) por uno un poco más caro.

El problema de esto es que, siempre te tienes que estar pegando para qué usando los mínimos recursos saque la máxima calidad, en consola es el infierno, no sé en la PS4 o en la XBONE, creo que la cosa anda más alegre, pero aun así las cifras no son para echar cohetes y dudo mucho que estas aguanten tanto como las de la anterior generación, a no ser que NV y ATI frenen mucho en cuanto a sus dispositivos para PC, o metan caña a los studios para qué el contenido de PC no sea tan vistoso yo he visto cosas en un PC normal, funcionando a 35 FPS, para caerte de culo, pero eso no se podía meter en consola con lo que no vera la luz, y menos ahora con las nuevas consolas que tienen que parecer mejores que un ordenador. Saludos.

Muy bueno el hilo, lo acabo de leer y es muy instructivo. Yo en las pruebas que he hecho con udque con respecto a eso de las texturas, recalco que con texturas pequeñas bien usadas se puede conseguir una calidad incluso superior que usando una grande. La cosa es usar trucos para qué no se note el tiling, udque por lo menos te da muchas posibilidades a la hora de crear los shaders y eso ayuda enormemente.

Este tema me parece muy interesante. A ver si cuando tenga algo hecho lo subo y comento los trucos que he usado o que se podrían usar, seguro que con la de expertos que hay en el foro, no parecen gran cosa, pero bueno, algunos me parecen curiosos y son muchas las posibilidades, mi recomendación es que se hagan pruebas. Saludos.

Para iPhone el límite máximo de textura es 1024x1024 píxeles.

Nosotros estamos usando hasta 4096x4096 en compresión PVR para iPad3 en adelante, así que, esa afirmación no es del todo correcta. Sin compresión (o mejor dicho, con compresión png), 2048x2048 aguanta bien en todos los modelos que Apple sigue manteniendo a día de hoy, aunque siempre es recomendable el PVR (donde el balance calidad/compresión sea favorable) para optimizar en memoria gráfica.

Usamos ese tipo de megatexturas principalmente para juegos con atlas de sprites (spriteshets de toda la vida) en juegos con animaciones 2D y menús, limitando el número de cargas y la fragmentación de memoria.

Pues venga amigo, ya tardas en subir cosas. Saludos.

Oye, pues no se cómo, me ha tragado una de 2048x 1024, y funciona y tal.



Es normal o se le va la olla? Porque otras veces que ha dicho que no cuela.

Y esos trucos para lucir texturas de menor tamaño, que salgan de paso.

-- IMÁGENES ADJUNTAS --

¿Por qué no iba a poder? Es potencia de dos. La limitación de ser cuadrada sólo es para compresión en PVR.

Ojo, que hay una ambigüedad con lo de ser cuadrada. A veces se usa para decir que su ancho y alto sean potencia de dos, pero no necesariamente iguales.

Se puede usar perfectamente 1024x2048, no hay problema en que no sea cuadrada, creo que te va a guardar 2048x2048 con franjas negras, es lo que dice Mars.

A ver si tengo tiempo y busco algún Shader de esos. Saludos.

Traducido de la web de UDK:
Resoluciones de la textura son considerablemente más altos para él futuro plataformas PC y de la consola, por lo que esperan los artistas tienen que pasar más tiempo per-textura. En PC, Epic esta utilizando texturas que son aproximadamente el doble de la cantidad de consolas de nueva generación. Como se ve en las Unreal Engine 3 demos, Epic espera vender con la mayoría 1024x1024 texturas DXT1 comprimida en consolas y 2048x2048 texturas en PC.

También se habla de los millones de tris máximos, algo que me está rondando y no tengo claro.
Épico esta utilizando 1-2 million mallas de triángulos durante gran parte de su contenido, pero se puede elegir fácilmente a no usar este nivel de detalle para todas sus mallas.

Link original de la traducción: [url]http://udn, epicgames.com/Thre/DevelopmentKitContentCreation.html[/url].

En este hilo de Polycount un tío dice que UDK puede manejar unos 2 billones de polígonos en una escena. [url]http://www.polycount.com/forum/showthread.php?t=99738[/url]. Saludos.

Consejo número 1, algo principal a todos los usuarios de UDK, el UDN no se actualiza, o sea, es muy raro, a no ser que existan quejas de los licenciados, que Epic cambie algo no importante del UDN, la ayuda es algo orientativo, no hay que tomárselo al pie de la letra, si les algo y no te funciona, muy posiblemente el fallo esté en la ayuda no en ti.

Para muestra un botón.

Me habéis hecho instalar el UDK vagos, :o) en casa no tengo un 4096*4096, pero un 4096*2048 se entiende, no sé cuál es el límite, pero anda qué no he metido yo texturas de 4096, y hace años de eso, fijaos donde pone Ps3 o XBox, in-game size no pones nada de límites, la carga entera, otra cosa es que el scale level, te permita esa resolución, normalmente a la consola la capas como a un toro viejo.



Sobre los polígonos, UDK no tiene el límite de 68000 polígonos por objeto que se arrastra desde hace siglos y que aún hoy la mayoría tienen, el número de polígonos en pantalla, yo he he tenido 6 o 7 millones en udk, he visto escenas de 120.000 objetos, (40% de instancias) usando 6 Gb de RAM, y millones de polígonos, creo que eran 20 millones, eso sí, no era en el 3, pero bueno la cosa se movía más o menos bien.

En este hilo de Polycount un tío dice que UDK puede manejar unos 2 billones de polígonos en una escena.

Los Billions yanquis equivalen a millardos, (miles de millones), no a nuestros billones, (millón de millones) el tipo se refiere a 2.000 millones, a ver, no lo sé porque no lo he probado, hay mucho límite teórico en cuanto a los bit del procesador, 32 o 64, la gráfica etc. Saludos.

-- IMÁGENES ADJUNTAS --

Que gusto da leer información así. Gracias.