Cargocultismo

Serie: Los N Pecados Capitales

Durante la Segunda Guerra Mundial, las tropas americanas desembarcaron en muchas islas cuyos habitantes habían tenido poco o ningún contacto con la civilización occidental. Ante los ojos de estos nativos, se desarrollaba un drama sacado de la ciencia ficción: unos seres curiosos, venidos de muy lejos, que realizaban ceremonias incomprensibles, a través de las cuales obtenían un nivel de bienestar material antes desconocido en la zona.

Uno de aquellos seres, por ejemplo, pasaba horas hablando con una extraña caja de la que sobresalían cuerdas de metal. Al parecer, aquellas conversaciones con la misteriosa caja conseguían que en la isla se posaran gigantescos pájaros de hierro, procedentes de la tierra de los antepasados, de cuyos vientres se extraían toneladas de comida, armas y otros objetos deslumbrantes y probablemente útiles. No, no se trataba de dioses, pero era evidente que aquella tribu había descubierto cómo contactar con sus antepasados y recibir la correspondiente bendición material.

Llamaba también la atención el que buena parte de estos marines fuesen de piel oscura... como la mayoría de los nativos, pues he olvidado aclarar que mi historia tuvo lugar en la Melanesia. Esto hacía que la idea de contactar con los antepasados para recibir un cargamento resultase más creíble: los negros de aquella tribu lo habían logrado, ¿no? En la mente de estos melanesios comenzó a forjarse la image de un tal John Frumm (¿John from America, quizás?) un marine negro que prometía volver para ayudar a los nativos tras la guerra.

Naturalmente, terminó la guerra y John Frumm no regresó. O si regresó, no lo reconocieron. Ante la ausencia, ¿por qué no intentar seguir el camino de Frumm? Tallaron radios de madera de cocotero, y pintaron líneas con hollín sobre zonas despejadas. Nativos con hojas de palmeras en sus manos imitaban el código de banderas de los norteamericanos, con la esperanza que aquel baile que habían visto ejecutar a John Frumm atrajese el cargamento de los antepasados a las islas.

Aún hoy, "tropas" de melanesios desharrapados desfilan en algunas islas con rifles de madera al hombro. El fenómeno se conoce como cargo cult y, como puede sospechar, ha sufrido algunos cambios en su necesaria evolución. Por ejemplo, para algunas sectas, los blancos se oponen a revelar el secreto del "cargo", y periódicamente estalla la violencia contra los pocos occidentales que tienen a mano. Ha surgido también algún mesías nativo que ha reclamado ser un avatar de John Frumm, y ha propiciado el correspondiente cisma entre los cultocarguistas.

---

La Informática está llena de cargocultistas: personas que han visto a otras usar con éxito determinada técnica, y que luego se lanzan a repetir la ceremonia sin entender realmente de qué se trata. Por ejemplo, todo el mundo ha leído sobre la maravillosa revolución que se produjo cuando Santa Programación Orientada a Objetos se encarnó entre los mortales, allá por los tiempos de gloria de C++. Por lo tanto, cuando es necesario escribir una aplicación para bases de datos, intentan utilizar eso de los "objetos". Y establecen principios como: "sólo es profesional aquel que define una clase Cliente". O: "tenemos que usar UML, o Java, o servicios Web... aunque no tengamos ni puñetera idea de por qué, pues es lo que hacen los programadores serios". Amén, hermano.

Observe que el cargocultismo es un mal diferente del síndrome del pollo de Skinner. En este último, se cree en la existencia de una relación causa/efecto inexistente, mientras que el cargocultismo se basa en una conexión real, que verdaderamente funciona... excepto que el cargocultista no comprende por qué. ¿Otra diferencia? Nadie confesaría voluntariamente que actúa como un pollo de Skinner, mientras que el cargocultismo tiene cierta aura de respetabilidad a su alrededor. Cuestione a un cargocultista, y parecerá que está cuestionando los principios más básicos de la profesión.

Además, tengo mejor opinión de un pollo de Skinner que de un cultocarguista. En cierto modo, todos hemos sido pollos de Skinner: el aprendizaje y la experiencia son la medicina contra ese estado. Por el contrario, es difícil curar a un cargocultista.

Y es que, en este mundo, mucha gente sigue esperando el regreso de John Frumm.

El Pollo de Skinner

Serie: Los N Pecados Capitales

Burrhus F. Skinner fue un famoso psicólogo estadounidense, mundialmente conocido por sus trabajos en la escuela conductista; aparte de lo anterior, y sin menoscabo de lo dicho, fue también un redomado cabrón (y que me perdonen sus descendientes y herederos). No es éste el momento de explicar el adjetivo, sin embargo. Sólo quiero contar uno de sus muchos experimentos.

Skinner puso un pollo frente a una caja que, de manera totalmente aleatoria, recompensaba al animalito, de cuando en cuando, con una golosina. El minúsculo cerebro del ave, no obstante, intentaba establecer una relación causa/efecto entre sus acciones y las recompensas. Si los pollos hablasen, ésta sería una posible transcripción de sus pensamientos:

¡Vaya, se ha abierto la caja! ¡Y qué gusano más sabroso había dentro! Veamos, ¿qué estaba haciendo cuando se abrió la caja? Entonces movía el cuello, de arriba a abajo. Repitámoslo. Arriba. Abajo... Nada, recórcholis... ¡espera, se vuelve a abrir! Gulp... Parece que si levanto una pata en el segundo movimiento, funciona. Ahí vamos... Espera, debo haberlo hecho mal. Corrijamos el movimiento de la cola... ¡Abrete, maldita seas!

Los pollos de Skinner terminaban elaborando complicadas danzas con el propósito de influir en la apertura de la caja de las golosinas. A pesar de todo, la caja se abría por motivos completamente distintos...

---

Muchos programadores y analistas se comportan como los pollos de Skinner. Se enfrentan a sistemas complicados, cuyo funcionamiento no conocen a fondo. Tras mil peripecias, logran que la aplicación funcione, pero atribuyen la causa del correcto funcionamiento a factores equivocados. Y el toque de brujería termina transformándose en un Principio, con mayúsculas, que todo recién llegado debe acatar, so pena de terribles torturas.

¿A santo de qué cuento esta historia? No sea mal pensado: estaba recordando algunos casos pintorescos que he conocido como consultor, y se me ocurrió recopilar algunos de los patrones, o más bien antipatrones, que son frecuentes en este mundillo. El primer antipatrón que me ha venido a la mente es el del Pollo de Skinner. Pero habrá más...

Espectros

La ley de Beer establece que un rayo de luz se atenúa exponencialmente al atravesar un material dieléctrico, como el vidrio. Esta ley es necesaria para reproducir materiales transparentes coloreados, como en la siguiente imagen, que copio del post anterior:

La mayoría de los ray tracers, XSight RT incluido, implementan la ley de Beer asociando un filtro a estos materiales. El código correspondiente, en XSight RT, está ubicado dentro del método Trace que heredan todos los samplers del motor:

if (attenuation)
{
   // Exponential attenuation inside transparent media.
   filter.blue *= (float)Math.Exp(attFltr.blue * info.Time);
   filter.green *= (float)Math.Exp(attFltr.green * info.Time);
   filter.red *= (float)Math.Exp(attFltr.red * info.Time);
}

Esta parece ser la extrapolación más "natural" de la ley de Beer para que se pueda aplicar a luz multicromática. Sin embargo, es fácil darse cuenta del problema que crea esta implementación. Para intervalos pequeños, es posible controlar los parámetros para dar con cualquier color deseado para el vidrio. Para intervalos grandes, sin embargo, cualquier componente del filtro de atenuación que sea menor que la unidad, terminará eliminando completamente el correspondiente canal de color de la imagen.

Por ejemplo, si digo que mi material tiene un filtro de atenuación con componentes 1, 0, 0 (para el rojo, verde y azul), estaré consiguiendo un vidrio rojo. Si cambio el filtro a 1, 0.5, 0, lograré que los objetos delgados de este material sean de color naranja... pero para objetos más gruesos, la luz terminará atenuándose hacia el rojo puro.

¿Es esto un comportamiento "natural"? Evidentemente no, sino que se trata de un comportamiento inducido por la implementación de los colores en el ray tracer. Esto me ha llevado a investigar, por simple curiosidad, sobre cómo podría implementarse un ray tracer que trabajase con píxeles de cuatro, cinco o más canales espectrales. Hay, sin embargo, muy poca documentación sobre este asunto, aunque me consta que algunos programas comerciales implementan recursos parecidos. Si usted sabe algo sobre el tema, le agradecería cualquier pista.

---

... y se me ocurre otra idea: buena parte del código consiste en instrucciones por triplicado que manipulan los tres componentes básicos de color de un píxel. ¿Sería posible idear una representación diferente del color que simplificase estos cálculos? Por ejemplo, ¿tiene algún sentido el ray tracing con colores en el espacio HSV? ¿Simplificaría el código? ¿Lo haría más eficiente? De momento, es una pregunta abierta...

---

Para terminar, una curiosidad: a primera vista, es lógico pensar que una esfera de cristal tintado debería mostrar un tono mucho más claro en los bordes, en comparación con su centro, ya que en los bordes el camino a recorrer sería menor, y se produciría menos atenuación. Sin embargo, esto no ocurre así, y puede buscar una esfera "real" de cristal para comprobarlo.

¿Por qué? Es sencillo: resulta que los rayos de luz que emergen en la zona cercana al borde viajan proporcionalmente un trayecto más largo de lo que pensamos, por culpa de las leyes de la refracción. De hecho, ocurre algo interesante e insospechado: hay una parte del interior de una esfera de cristal que, al mirarla de frente, no podemos ver, debido también a la refracción. Esto es fácil de comprobar generando imágenes de esferas de vídrio con esferas opacas más pequeñas en su interior. Es muy probable que este comportamiento se aproveche en algún truco de magia. Se lo preguntaré al espíritu de Houdini.

XSight RT v1.5

Nueva versión pública de XSight RT v1.5, también para .NET Framework 3.5. La descarga contiene el instalador del ejecutable, la ayuda y un puñado de escenas para pruebas. No he incluido el código fuente.

La aplicación permite editar escenas con un lenguaje sencillo y bien documentado, y generar imágenes a partir de estas descripciones. De momento, funciona como una aplicación SDI, permitiendo trabajar con un único documento por instancia de la misma.

En esta versión, se incorpora la generación concurrente de escenas, con un modo dual, que reduce casi a la mitad el tiempo de generación en ordenadores con doble núcleo (algo menos en procesadores de un solo núcleo con hyperthreading). Además, ya funciona el material glass, y puede utilizarse un color para el cristal (según la ley de Beer). Hay también soporte para normales perturbadas, los pigmentos crackle y bubbles, cilindros y esferas de cuarto grado, una operación merge para materiales transparentes (equivalente a union, pero eliminando las superficies internas). Y se ha mejorado la velocidad, en general, del núcleo.