Texturizar con jpgs

[elGordo]

Hola a todos, he leído en el foro del increíble y prometedor Project:lemon que uno de sus ilustres conductores texturizaba con tgas. Yo llevo haciéndolo mucho tiempo con jpgs, y he aquí mi duda, ¿es mejor hacerlo con tgasí, y ¿por qué?
Muchas gracias por adelantado y un saludo.

[essmigol]

Yo creo que es porque sencillamente tiene más calidad e información una imagen en (*.tga) que un jpeg, en que caso es o no mejor ya no lo sé. De hecho, casi todas las secuencias de película se digitalizan en tif o tga.

Luego el uso de un formato u otro también me gustaría saberlo.

[SHAZAM]

En Hash Inc, me dijeron hace mucho que es mejor utilizar tga por que con (*.jpg) el procesador debe calcular las compresiones y eso retrasa el proceso de render. Supongo que lo mismo pasa con todos los programas, particularmente sigo esa norma no solo en a:m sino también en Blender y 3ds Max. Saludos.

[essmigol]

Gracias por la información Shazam.

[Caronte]

El formato jpeg es un formato de alta compresión, pero con pérdida, por lo tanto solo es bueno para mostrar una imagen final, pero no para postprocesar dicha imagen.

Imaginemos que cargamos en un software de 3d una imagen de fondo en jpeg y después hacemos render, el resultado será que esa imagen de fondo tendrá menos calidad (dichosos píxeles en los bordes contraste y pérdida de tonalidades en los degradados), y si el resultado lo volvemos a guardar en (*.jpg), todavía perderá más y si además de esto después hacemos postproducción y volvemos a guardar, pues ya no te quiero contar.

El tga es un formato con baja compresión (solo RLE) pero sin perdida y además con posibilidad de canal alpha.

El tif también es sin perdida y tiene una mejor compresión (lzw).

En general yo suelo usar (*.jpgs) al 100% de calidad (aunque un jpeg siempre pierde) en texturas que no son mías y ya están en (*.jpg), pero para texturas hechas por mí, uso normalmente tga o tifs.

Siempre uso tga para entregar trabajos, sobre todo de animación.

[alberizo]

Esa duda también la tenía yo. En los motores gráficos de videojuegos después de hacer muchas y muchas comprobaciones de tiempo, mi respuesta es: depende para lo que quieras, velocidad o compresión puesto que en memoria luego ocupan igual, ciertamente el tga tarda menos a la hora de descomprimir, y los jpgs evidentemetne tardan más, los tga te dan más calidad, en los videojuegos es muy desagradable cuando se ven los píxeles típicos de los jpgs con las franjas. La única pega de los tga es que se comprimen menos. Yo me decantaría por los tga si no hay problemas de espacio físico (Hd, CD).

[juansolo]

Y (*.png), nadie usa png? Tengo entendido que puede tener tanta calidad como el (*.tga), y con menos tamaño, es esto cierto?

[Caronte]

En Hash Inc, me dijeron hace mucho que es mejor utilizar tga por que con (*.jpg) el procesador debe calcular las compresiones y eso retrasa el proceso de render. Supongo que lo mismo pasa con todos los programas, particularmente sigo esa norma no solo en a:m sino también en Blender y 3ds Max.

Esto es cierto, pero solo es válido si las texturas están animadas, porque si son texturas simples, el software las carga en el momento de hacer el primer render, las descomprime en memoria y ya trabaja con ella descomprimida durante todo el tiempo.

Si alguien tiene dudas, puede hacer la prueba cargando una imagen, haciendo un render y después borrando la imagen del disco duro y repitiendo el render sin ningún problema.

De todas formas, un jpeg tarda tan poco en descomprimir, que es muy posible que tarde más un tga en cargar del disco, debido a que ocupan mucho más.

[Caronte]

Y (*.png), nadie usa png? Tengo entendido que puede tener tanta calidad como el (*.tga), y con menos tamaño, es esto cierto?

Se me olvidaba ese formato.

Si, el (*.png) es muy bueno, tiene alta compresión similar al (*.jpg) y no tiene perdida, además de que puede contener también el canal alpha.

Yo lo he usado poco, porque no tiene tanta solera como los otros formatos, pero supongo que, hoy en día, ya todo software lo soporta.

[juansolo]

Pero supongo que, hoy en día, ya todo software lo soporta.

Si menos la mier, del interné jexplorer, que no admite las transparencias del png.

[Nanomix80]

El (*.png) además de poder contener canal alpha, puede contener también más información, como material_id, z, objet_id, normal, node_ender_id, transparencia y más cosas, (según tengo entendido eh).

[elGordo]

Vaya. Así da gusto. Muchas gracias por las respuestas, me ha quedado bastante claro. Un saludo.

[Caronte]

El (*.png) además de poder contener canal alpha, puede contener también más información, como material_id, z, objet_id, normal, node_ender_id, transparencia y más cosas, (según tengo entendido eh).

Eso ya depende de la aplicación o del dispositivo (ejemplo: cámaras de fotografías que guardan velocidad, diafragma, etc), porque el jpeg también puede guardar algo de información.

[Nanomix80]

Muy buena ampliación Caronte, yo, por ejemplo, me refria a tirar un render en (*.png) para su postproducción, pero muy útil saber también lo de las cámaras y tal.

[josepzin]

Si menos la mier, del interné jexplorer, que no admite las transparencias del png.

Creo que ya lo hace.