domingo, abril 13, 2008

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:
Refracción y ley de Beer
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.

Etiquetas: ,

17 Comments:

Blogger Rox said...

Me he dado cuenta que desde que el blog ha tomado el rumbo del RayTracer no hay apenas comentarios, supongo que por la "ignorancia" de los lectores (yo incluido) sobre el tema. Tambien me pregunto si es una aficion o es algun trabajo comercial o para la venta este XSightRT.

Por ultimo, he de asumir que las bases de datos y las aplicaciones comerciales de gestión han pasado a mejor vida en el camino hacia la "fuente" de Ian ??

Un saludo.

P.D. El tema es muy intersante a pesar de todo, siempre me ha gustado el 3D y el diseño grafico :)

lunes, abril 14, 2008 12:17:00 p. m.  
Blogger Félix said...

estoy completamente de acuerdo :-).

martes, abril 15, 2008 11:58:00 a. m.  
Blogger Ian Marteens said...

me pregunto si es una aficion o es algun trabajo comercial o para la venta este XSightRT.

No. Para forrarme estoy intentando conseguir la patente del caramelo con sabor a coño ;)

martes, abril 15, 2008 5:35:00 p. m.  
Blogger KChis10 said...

No creo que la pregunta sea ofensiva ni nada que se le parezca como para recibir una respuesta de esta índole.

Además, yo también me incluyo en el grupo de usuarios que desde hace muchos años compramos tus cursos y nos quedamos a medias, con la única esperanza de que cada vez que anuncias estar trabajando en alguna parte del cusor sea cierto y la podamos ver alguna vez.

martes, abril 15, 2008 7:08:00 p. m.  
Blogger Ian Marteens said...

Coño, kchis10, la respuesta no pretendía ser ofensiva. ¿O es que crees que un caramelo con sabor a coño es una mala idea comercial?

martes, abril 15, 2008 7:14:00 p. m.  
Blogger Ian Marteens said...

... y, a pesar de que (por ínfulas de escritor) intento usar lo menos posible los smileys (incluso los considero como un signo de desconfianza en la capacidad del lector), colé un guiño al final de la respuesta, por si las moscas.

martes, abril 15, 2008 7:15:00 p. m.  
Blogger Alex said...

Yo que leeo hace años creo que no pretendías ofender con la respuesta, pero reconoce que es bastante furte.
Por otra parte me sumo a kChis10 y los post anteriores como cliente de varios cursos, entre ellos el de ado.net que adquirí al principio sbiendo que estaba desfasado ya que si no había salido VS 2005 faltaba poco. La actualización se produjo a finales de 2007 cuendo ya estaba VS 2008. ¿cuendo saldrá la actualización prometida para VS 2008? ¿cuendo estará completo, con todas las pertes?
De todas formas el curso me parece estupendo y recomiendo la compra a quien puede leer esto. Eso sí nos gustaria un compromiso para acaberlo y actualizarlo.

martes, abril 15, 2008 8:01:00 p. m.  
Blogger Alfredo Novoa said...

Yo creo que es mejor idea inventar un coño con sabor a caramelo :-)

miércoles, abril 16, 2008 1:32:00 a. m.  
Blogger Ian Marteens said...

Se llenaría de hormigas...

miércoles, abril 16, 2008 10:02:00 a. m.  
Blogger Rox said...

Jajajajajaja, me parto con este hombre. A ver por alusiones:
1.) No me he sentido ofendido con la respuesta de Ian, creo conocer el humor negro que gasta, para eso me he leido su libro de la Cara Oculta de C#
2.) Yo como aficionado a la programacion y no profesional de ella noto menos lo que comentan de los cursos pero es cierto que entiendo sus protestas, aun así supongo que es dificil acabarlos. No obstante son buenos y recomendables.
3.) Quiero un 1% de los beneficios de la patente del caramelo con sabor a coño si esque lo consigues !!!!

P.D. He conseguido que vuelva a comentar la gente :))

viernes, abril 18, 2008 9:02:00 p. m.  
Blogger Ian Marteens said...

He conseguido que vuelva a comentar la gente

:) Se agradece...

Respecto a lo demás, y ya en general:

1- Hummmmm..... siendo sinceros, no creo que haya mucho más que hablar sobre bases de datos de lo que ya está hablado y escrito. De lo que podía ser importante y no estaba en la última actualización del curso, por ejemplo, ya escribí en este blog (sobre UpdateBatchSize).

2- Se que hay gente que no despega ojo de las novedades sobre LINQ y sus aledaños. Pero repito mi personalísima opinión:

2.1- LINQ es estupendo, pero LINQ para SQL no lo es.
2.2- Los persistence frameworks, en general, no se llevan muy bien con las tres capas. Sé que es opinable... y ya se ha opinado y discutido sobre el tema bastante (y más, si sigue haciendo falta).
2.3- Se está abusando de LINQ hasta el ridículo. Pero incluso en esa dirección, también he puesto mi granito de arena.

3- El paso verdaderamente revolucionario que está flotando en el viento es el reto que plantean los micros con múltiples núcleos.

Abundo sobre esto último:

Ya tenemos quad-core en la calle, tanto de AMD como de Intel. Y en el caso de Intel, al menos, cada núcleo podrá ser (en algún futuro cercano) "hyperthreaded".

De vuestras aplicaciones, ¿cuáles de ellas pueden aprovechar toda esta potencia YA? ¿Tenéis todos las pilas puestas para lo que nos viene encima?

Confieso que últimamente me he empezado a preocupar por estas cosas. Y estoy intentando dar el máximo en estos temas. De hecho, el proyecto en el que colaboro ahora como consultor utiliza multithreading a chorros... y sockets de todo tipo (está implementado ahora mismo con "unicast" y lo van a pasar a "multicast").

XSight RT no sólo me permite adquirir un conocimiento impagable sobre el CLR, sino que en estos momentos me está permitiendo experimentar directamente con los problemas de concurrencia y sincronización.

Por ahí es por donde van mis tiros...

Y por supuesto, lo que estoy escribiendo sobre BBDDs está yendo a parar al libro y a la próxima actualización del curso.

viernes, abril 18, 2008 9:30:00 p. m.  
Blogger Alfredo Novoa said...

Los persistence frameworks con lo que no se llevan bien es con la inteligencia. La persistencia es solo uno de los muchos servicios que ofrece un SGBD (las tablas son persistentes a menos que indiquemos lo contrario). El mismo término de "marco de persistencia" ya es absurdo. Y todo lo que viene detrás también.

LINQ es una chapuza creada por gente que no sabe muy bien lo que hace, pero han acertado (probablemente por casualidad) en que la solución al problema de la falta de acoplamiento entre lenguajes de programación de aplicaciones y SGBD consiste en elevar el nivel de los lenguajes de aplicaciones para ponerse a la altura de SQL. Cosa que era bastante obvia, y que los expertos en bases de datos llevaban diciendo durante décadas. Yo creo que a partir de aquí es difícil dar marcha atrás y todos se acabarán subiendo al carro.

Cualquier software de servidor aprovecha los múltiples núcleos. En el caso de una aplicación de interfaz de usuario de un sistema de gestión, es difícil imaginar que hacer con más de dos núcleos. Y aun usando un solo núcleo este va a estar "durmiendo" más del 99% del tiempo.

lunes, abril 21, 2008 3:12:00 a. m.  
Blogger Daniel said...

Hola Ian:
para los que seguimos lideando con los sistemas y las bases de datos, para cuando estimas saldra a la venta la cara oculta? Febrero ya pasó, al menos aca en el fin del mundo :)
Un saludo

lunes, abril 21, 2008 1:56:00 p. m.  
Blogger Ian Marteens said...

En el caso de una aplicación de interfaz de usuario de un sistema de gestión, es difícil imaginar que hacer con más de dos núcleos.

El problema es que cada vez se hacen más aplicaciones "de servidor" (y no siempre se aprovecha automáticamente el paralelismo). Ahora mismo, estoy haciendo aplicaciones clientes para servidores propios de difusión y contratación de derivados. Las aplicaciones de servidor ya están hechas... en Java. Y naturalmente, esa gente no conoce qué es un IO Completion Port (en .NET ya viene de serie en el ThreadPool), cómo simularlos y qué ventaja les daría.

Respecto a las aplicaciones clientes, no hay muchas ideas que digamos, ahora mismo, precisamente por las limitaciones en potencia. Primer escenario evidente: juegos. De hecho, la moda ahora es investigar sobre "real time ray tracing" (y hay resultados). Intel incluso tiene planes para producir hardware gráfico orientado a ray tracing, en vez de lo que hay ahora (scanline rendering).

Pero incluso en el mundo de aplicaciones de gestión: inteligencia de negocios, síntesis y reconocimiento de voz, o simplemente más rendimiento. En las aplicaciones cliente que estoy metido hacen falta hilos por un tubo. Cada detalle que no se controle teóricamente se corresponde con un bug (que en v1.1 no se detectaban como en las nuevas versiones).

lunes, abril 21, 2008 10:39:00 p. m.  
Blogger Ian Marteens said...

para cuando estimas saldra a la venta la cara oculta?

Julio/agosto:

1- Cambio brusco de prioridades: tengo un buen contrato de desarrollo, pero me lleva mucho tiempo.
2- Mejoras al contenido: gracias a este contrato, me he dado cuenta de la necesidad de tratar sobre concurrencia "en serio".

lunes, abril 21, 2008 10:40:00 p. m.  
Blogger Alfredo Novoa said...

Respecto a las aplicaciones clientes, no hay muchas ideas que digamos, ahora mismo, precisamente por las limitaciones en potencia. Primer escenario evidente: juegos.

Hombre, con los juegos si que es evidente y cada vez se aprovechan más los núcleos.

Pero incluso en el mundo de aplicaciones de gestión: inteligencia de negocios, síntesis y reconocimiento de voz, o simplemente más rendimiento.

En lo de la inteligencia de negocios el procesamiento se hace casi siempre en los servidores. La síntesis de voz requiere muy poca potencia, pero para el reconocimiento de voz si que viene muy bien tener varios núcleos.

Respecto al rendimiento en los típicos clientes de gestión, yo creo que con los procesadores que hay ahora vamos más que sobrados en la gran mayoría de los casos, sobre todo teniendo en cuenta la velocidad de las redes.

Yo también uso hilos en mis clientes, aunque pocos, y con un solo núcleo ya voy sobrado.

martes, abril 22, 2008 12:19:00 a. m.  
Blogger Alfredo Novoa said...

1- Cambio brusco de prioridades: tengo un buen contrato de desarrollo, pero me lleva mucho tiempo.

Supongo que esto responde lo que te pregunté por email.

martes, abril 22, 2008 10:50:00 a. m.  

Publicar un comentario

<< Home