Necesitamos estandarizarnos

La infografía necesita eestandarizarse. O al menos, es lo que sinceramente pienso. Me gustaría conocer vuestra opinión al respecto.

Hace poco estuve lidiando con el zmapper de ZBrush. Mapas de normales, de todos los tonos y todos los colores, flipeadas en x, en y, y en z. Cada caso para su madre y para su padre, de una manera para Mental Ray, de otra para el 3ds Max, de otra diferente para Autodesk Maya, una para Maya software y otra para Maya hardware, para Vray, para Maxwell Render/FryRender.

Y así acabamos, con normales que se hunden donde deberían salir hacia afuera, con luces que iluminan caras que deberían quedar sumidas en las sombras, por no hablar de los mapas de normales tangenciales en objetos complejos, normales tangenciales bidireccionales y otro montón de opciones a cerca de normalizar la tangente con la bitangente en x, para el software x, normalizar la bitangente con la normal para el software y.

Lo mismo sucede con los desplazamientos, puntos cero que deben estar en el gris neutro para este o aquel software, en el negro absoluto para ese otro de más allá. Y no nos queda más que reír cuando vemos todos esos modelos en los que hemos puesto tanto tiempo y esfuerzo hinchados, interseccionándose a sí mismos o al borde del colapso anoréxico y seguir retocando configuraciones.

Sólo entonces parezco haberme dado cuenta de esto. Software que mide en centímetros en una escena nueva, en pulgadas, en metros, software que establece su dirección y como altura y z como profundidad, como, por ejemplo, Autodesk Maya, que siempre se basó en un dibujo para establecer que la profundidad sería z, el caso contrario lo tenemos en 3dsmax, que se basó en los planos con los que trabajaba el AutoCAD de Discreet para que z fuese la altura, quizá incluso los controles dé la propia cámara deberían eestandarizarse, y que conste que ya hay algunos (max, Autodesk Maya y un modo de XSI) que nos permite usar las herramientas de transformación mover, rotar y escalar con w, e y r.

Así se evitarían muchos modelos importados en otro software vuelto del revés, enorme o diminuto, otro montón de barras y parámetros de importación/exportación que toquetear, por no hablar de que el que parece ser el formato más standard para la geometría, (*.obj), sigue dejando bastante que desear en cuanto a normales, por ejemplo, al llevarlo de un programa a otro.

Y entonces es cuando empiezan a llenarse las ventanas con cientos de opciones, botones, checkbox y menús desplegables que nos hacen perder tiempo y ganarnos el apodo de profesional.

Pero no, a mí esto me parece que no tiene nada de profesional, me parece ridículamente absurdo, me parece absurdo exportar desde x con los parámetros de y e importar en y el archivo con las matizaciones de x. Me parece absurdo coger una textura de a y usarla en b activando las opciones c,d,e y f para que pueda ser bien interpretada, me parece absurdo aprender todas esas configuraciones, como me parece absurdo que programadores y compañías gasten su tiempo y dinero en esa absurda flexibilidad que jamás debió existir.

Por supuesto los programas deben llevar su propia optimización, para su núcleo único y totalmente diferente de los demás, como las imágenes .map de Mental Ray, como las .if de Autodesk Maya, como las.pic de Softimage, pero estoy convencido de que el usuario de hoy, donde todo lo rápido que trabajes siempre es suficientemente lento, no debería preocuparse de estas optimizaciones, deberían ser a nivel interno, simple y llanamente. Maya lo hace, cada imagen se transforma a nivel interno automáticamente, quizá Softimage también lo haga, la cuestión es, optimización sí, pero no a costa del usuario, ni de archivos especiales.
¿Os imagináis necesitar 3 texturas de color, una original para vuestro visor en 3dsmax, otra con el canal rojo un 10% menos saturado para el render en Vray y otra con el canal verde y azul invertido para FryRender, y total, para conseguir el mismo efecto, el mismo fin, la misma imagen?
Es ridículo, pero eso precisamente es lo que está pasando con los mapas de normales y los desplazamientos. Necesitamos un formato standard y que el software aplique sus particularidades internamente.

Y es que el software3d avanza, y lo hace rápido, muy rápido, casi tanto que si nos apartamos de los ordenadores un par de meses tendremos unas cuantas asignaturas acumuladas, un mondust en XSI, un sistema muscular en Maya, una nueva actualización en el BodyPaint de cinema4d o incluso que el 3ds Max se nos divide en dos versiones, y menos mal que sólo nos solemos centrar en un software concreto, aunque al final los avances del uno llegan al otro. Pero honestamente, nos hace falta un tiempo para parar, reflexionar sobre la nueva tecnología y eestandarizar aquello que es lo mismo, no puede ser que necesitemos n mapas de normales o n mapas de desplazamiento para n motores de render cuando se trata de lo mismo.

Y por último, ¿a quién beneficia esto? ¿al usuario, dando vueltas por internet en busca de configuraciones correctas para su software, perdiendo tardes probando configuraciones, hojeando la ayuda para comprender cómo se comporta nuestro software? ¿a los programadores, llenando de opciones paneles de atributos, creando código innecesario? ¿a las empresas, gastando tiempo/dinero tontamente? ¿a quién?
¿Debería haber alguna especie de organismo regulador de estándares en el campo de la infografía? ¿o simplemente deberían quedar una vez al año todas las compañías en una conferencia privada y debatir que formato es mejor y porqué, o en el caso de que sea igual, jugárselo al pinto gorgorito?
Más de uno pensara que decir esto es como decir que todos deberíamos hablar en inglés, y la verdad, quizá deberíamos, pero lo malo, lo ridículo, es que, aun yendo en contra de toda lógica y, aunque suene bonito, suena a imposible.

Sería cómodo el estándar, pero si en otras áreas más importantes no son capaces de usar un mismo sistema de unidades, perdiendo millones porque unos hablan en pulgadas y otros en metros, mucho menos habrá un esfuerzo para los programas 3d.

Además, la mayor parte de los usuarios no usan tantos programas a la vez así que, el problema se reduce mucho más.

En pocas palabras: creo que a las empresas de software no les interesa que haya un estándar. Les interesan plataformas cerradas para que no te salgas de sus productos, poco a poco por demanda de los clientes las cosas han cambiado un poco, pero cada cual quiere mantener su estándar sobre el resto.

Es impensable, además de que haría que los softwares de 3d se desarrollaran muchísimo menos. La competencia te obliga a esforzarte, lo mismo pasa con el software.

Pongo como ejemplo flash, creo que ha perdido mucho desde que lo compro Adobe y a mí se me ocurre que eso es consecuencia de haber eliminado la competencia.

Cada software implementa las cosas lo mejor que le parece y luego si es una buena forma entre ellos se copian o siguen como están, si fuera todo un estándar limitaría mucho las posibilidades, entiendo que como artista sea cómodo tener un estándar, pero no hay que olvidar que existe toda un área técnica en cualquier producción que si le saca provecho a esas diferencias y según eso se definen distintas soluciones según las necesidades del proyecto, yo digo no al estándar y si a la flexibilidad y las alternativas.

Para mí una cosa no tiene nada que ver con la otra, puede haber estándares y competencia al mismo tiempo, un ejemplo: llevamos varios años viendo la dura competencia en el terreno de los navegadores y todos siguen el mismo estándar html, el tener formatos estándar es algo totalmente necesario que no limita las posibilidades de las empresas a la hora de desarrollar sus productos, toda la industria del software basa parte de su modelo de negocio en crear soluciones cerradas, y la mejor forma de hacerlo es mediante los formatos en los que se guardan los datos, esto obliga a los usuarios a permanecer atado a la aplicación. El sector del 3d no se escapa a esto, otro ejemplo, y esté relacionado con el 3d, el estándar rib. Define un estándar para la descripción de escenas para motores de render, y eso no ha obligado que varias empresas desarrollen sus productos en libre competencia.

Porque otros motores de render no han seguido este estándar, o lo han intentado extender para que cubriese sus necesidades.

Cita:

---

Un ejemplo: llevamos varios años viendo la dura competencia en el terreno de los navegadores y todos siguen el mismo estándar html.

---

Pero con color local según cada navegador.

Los estándares son tan útiles que todo el mundo quiere el suyo.

Cita:

---

Los estándares son tan útiles que todo el mundo quiere el suyo.

---

Pues gracias a los estándares puedes leer estas páginas así que, ya me dirás.

Gracias por las respuestas. Interesante debate el de los estándares vs programa cerrado, aunque reconozco que desvié el tema a un ámbito mayor, no me negaréis que lo de las normales y los mapas de desplazamiento es para mear y no echar gota, ¿eh?

Lo de las normales y los mapas de desplazamiento, efectivamente, es como para mear y no echar gota. Lo de la estandarización es una intención muy buena, pero créeme que con un proceso de estandarización se frenaría de manera brusca la innovación (ya que la innovación muchas veces requiere de borrones y cuenta nueva).

Entre la innovación y la estandarización, me quedo de lejos con la innovación libre y salvaje, y cuando la tecnología esté mucho más desarrollada y asentada, ya hablaremos entonces de eestandarizar.

Cita:

---

Lo de la estandarización es una intención muy buena, pero créeme que con un proceso de eestandarizar se frenaría de manera brusca la innovación (ya que la innovación muchas veces requiere de borrones y cuenta nueva).

---

A ver, yo creo que se están confundiendo los términos, eestandarizar no tiene nada que ver con limitar el desarrollo, al contrario, muchas veces se estandariza para poder facilitar dicho desarrollo, si se ve que hace falta algo nuevo pues se crea un nuevo estándar, previo desarrollo de montones de formatos diferentes para hacer la misma cosa, lógicamente si los estándares actuales no cubren un área determinada pues se intentan buscar nuevas opciones, pero eso afecta a una minoría, la inmensa mayoría puede desarrollar a innovar más rápidamente porque hay muchos detalles a los que no tienen que prestar atención ya que están estandarizados, otro ejemplo, el formato OpenEXR, antes de que saliese cada estudio tenía su propio formato de 32-64 bits lineal, hace diez años ya se sabía que el Cineon tenía muchos problemas. La industria para poder innovar y avanzar rápidamente necesitaba un estándar en este segmento y ahí entra ILM con su OpenEXR. Eso ha permitido que rápidamente todos los motores de render y programas de composición adopten un estándar par imagen lineal. Ahora no se concibe un pipeline de un estudio si no está basado en OpenEXR, así que no veo que haya una diferencia entre eestandarizar e innovar, al contrario, si no fuese por la estandarización muchas cosas no podrían desarrollarse a la misma velocidad, otro ejemplo: Linux, el gran problema de Linux a la hora de penetrar en el mercado de los escritorios es su falta de estandarización. ¿Que eso le quitaría su capacidad de diversidad e innovación? Lo dudo mucho. Si hubiese un estándar de escritorio, por ejemplo, no se estarían duplicando esfuerzos y reinventando la rueda como hacen ahora KDE y Gnome. Cada uno ofrece sus opciones, pero al no tener tanta penetración en el mercado de poco vale. Ahí están los Kioslaves de KDE que son un invento buenísimo, yo creo que solo Mac OSX tiene algo parecido, y mira lo han tenido prácticamente que desechar, una pena.

Así que innovación y estandarización para mí son cosas separadas y complementarias.

Cita:

---

Los estándares son tan útiles que todo el mundo quiere el suyo.

---

Pues gracias a los estándares puedes leer estas páginas así que, ya me dirás.[/quote]Ya, hombre, era una de esas frases hechas, como: luchar por la paz es como follar por la castidad.

Los estándares sientan la base del desarrollo para poder aunar esfuerzos y no estar todo el día reinventando la rueda. El problema es que todos quieren imponer su estándar para hacerse con los beneficios consiguientes.

Lo suyo sería adoptar estándares de libre distribución, aunque lamentablemente no es siempre posible.

Cita:

---

El gran problema de Linux a la hora de penetrar en el mercado de los escritorios es su falta de estandarización. ¿Que eso le quitaría su capacidad de diversidad e innovación? Lo dudo mucho. Si hubiese un estándar de escritorio, por ejemplo, no se estarían duplicando esfuerzos y reinventando la rueda como hacen ahora KDE y Gnome. Cada uno ofrece sus opciones, pero al no tener tanta penetración en el mercado de poco vale. Ahí están los Kioslaves de KDE que son un invento buenísimo, yo creo que solo Mac OSX tiene algo parecido, y mira lo han tenido prácticamente que desechar, una pena.

Así que innovación y estandarización para mí son cosas separadas y complementarias.

---

Una cosa es un standard consensuado entre los involucrados y otra muy diferente la estandarización que resulta de la brutal penetración de un producto a consecuencia de las políticas comerciales que lo impulsan.

A ver, en el primer mensaje yo entendí que bien sobre estandarización de métodos, es muy distinto a estandarización de formatos.

No mezclemos peras con manzanas.