Hi,
estos meses, desde marzo mas o menos, he estado currando en un proyecto avanzado de la asignatura de graficos de la carrera de informatica de la uam.
Normalmente se suelen hacer unas practicas por cada asignatura, pero en algunas te dan la posibilidad de hacer un proyecto, si te ves con las suficientes ganas. Asi que como yo habia estado toqueteando desde hacia un tiempo con el tema de graficos, se lo comente a mi profesor y me emplazo a presentarle una serie de propuestas.
En un primer momento me dijo que lo que normalmente se hacia es el tipico ray tracer, pero como me parecia demasiado tipico le propuse un mapa de fotones. Me dijo que mucho animo y nada, me puse manos a la obra.
El mapa de fotones es un algoritmo de iluminación global de dos pases. Un primer pase consiste en crear el mapa de fotones, es decir, vas lanzando fotones de los focos de luz y por medio de algun tipo de metodo como la ruleta rusa, vas haciendo que reboten/reflejen/refracten/absorban.En un segundo pase, usas back ray tracing para saber el color de cada pixel. Pero en vez de hacer el calculo que se haria en un ray tracer, usas el mapa de fotones para saber la contribución de los fotones mas cercanos a ese punto.
Bueno, mas o menos y simplificando muchiiiiiisimo es eso. Normalmente el mapa de fotones se usa en conjunto con el monte carlo ray tracing. Es decir, el mapa de fotones se usa para iluminacion indirecta y causticas. El resto se usa el ray tracing.
Os voy a poner un render que he tirado justo despues de arreglar los fallos en el codigo de refraccion y reflexion. Ahora mismo estoy tirando mas renders para poner, y en cuanto arregle un par de fallos, subire los binarios para que destripeis la aplicacion sin piedad!! (uoh)
(http://img530.imageshack.us/img530/8820/segundopase15123274pa.th.png)En el render se ve una esfera totalmente transparente pero no refleja, un cubo rosa detras y un cubo azul como suelo, ambos totalmente difusos y opacos.
De todas formas, le faltan un monton de cosas y detalles (texturas, eficiencia, mejorar la interface de escena, etc...) aunque en 3 meses escasos no me ha dado tiempo a mas, teniendo en cuenta que trabajo y no solo tengo esta asignatura de practicas.
Aqui os dejo una captura del interface de configuracion de escena que he hecho. He reusado la gui que te viene en el sdk de directx.
(http://img325.imageshack.us/img325/993/configuracion151421432my.th.png)Un saludo,
Rubén
La unica pega que le veo es que parece que tiene bastante aliasing... el resto... (genial) muy chulo.
Cita de: "Lord Trancos 2"La unica pega que le veo es que parece que tiene bastante aliasing... el resto... (genial) muy chulo.
te refieres por la ¿"esfera" ? Realmente el objeto no es una esfera perfecta. He usado la primitiva de directx para crear la malla de la esfera con 32 cortes(tanto slices y stacks). Una de las mejoras sería usar mis propias primitivas para las mallas.
De todas formas, si os fiajis en el "suelo" hay determinadas transiciones de colores que son muy bruscas. Esto es debido a los parametros de configuracion de escena: numero de fotones y radio de busqueda de foton vecino.
Este render creo que tiene solo 150k fotones y un radio de busqueda de 0.4. Cuantos mas fotones lances menor radio podras poner y mayor precisión tendras.
Gran trabajo (ole)
Se ve muy bien. No controlo mucho del tema, pero no encuentro mucha diferencia entre lo que has contado y el rayracing. En el raytracing se lanzan rayos y en función de donde colisionen se reflejan/refractan/etc. que es lo mismo que has dicho con fotones. Podrías explicar las diferencias?
Hi,
voy a explicarlo algo por encima, asi que la gente que sepa por favor no me deis mucha caña.... :P
El trazado de fotones es exactamente igual al trazado de rayos excepto que el foton propaga el flujo de energia y un rayo recoge la "brillantez"("radiance"). Como supongo que no ha quedado nada claro, voy a explicar los dos algoritmos por encima. El trazado de rayos, lo paso muy por encima, ya que no lo he implementado aun (aunque planeo hacerlo :P ).
Mapa de fotones:Un foton es un punto en el espacio con una energía determinada. La estructura es tal que asi: posicion, direccion, normal y energia. Este atributo nos dira la energia/intensidad que tiene cada foton del mapa de fotones. Normalmente se codifica como una terna de floats (r, g, b ).
Un objeto tiene estas propiedades:
-Factor difuso
-Factor especular
-Factor de opacidad
-Indice de refraccion
El mapa de fotones es el conjunto de fotones de la escena, que ya han sido lanzados y procesados.Ahora explicare en que consiste este proceso. Este mapa de fotones normalmente es una estructura espacial que nos permita una busqueda muy rapida: kdtree, por ejemplo.
El algoritmo de iluminación global por mapa de fotones consiste en dos pases:
1)
Trazado de fotones:Para cada foco de luz, se emiten(lanzan) una cantidad de fotones a la escena. Se pueden elegir entre multitud de formas de distribución, la más comun es la de Monte Carlo. Cada uno de estos fotones tendran una energia inicial inversamente proporcional al numero de fotones que se van a lanzar. Esto nos asegura que la energia es igualmente distribuida a lo largo de la escena.
Ahora, cuando hemos lanzado nuestro foton pueden pasar dos cosas: o bien que no encuentre ningun objeto en la escena, por lo que ese foton se perdera, o bien (y lo mas interesante :P ) que interseccione con algun objeto. Cuando intersecciona un objeto tenemos varias posibilidades, dependiendo de las propiedades del objeto. El fotón puede ser reflejado, transmitido o absorbido. Esto se decide de una forma probabilistica segun el metodo de la ruleta rusa. Es decir, se elige un numero aleatorio entre 0 y 1:
a ) Si el numero es menor que el factor difuso del objeto, estamos en el caso de una reflexion difusa. Por lo tanto el foton se almacena en el mapa de fotones con la posicion siendo la interseccion y la energia siendo el color de la luz que lo ha emitido por el factor de opacidad. Además se emite un foton nuevo, que simulara la transmision de color entre objetos, con direccion una aleatoria (teniendo cuidado que no apunte al interior del objeto) y energia la del foton absorbido multiplicada por el color del objeto y su factor difuso. Para este foton nuevo se repite el proceso de trazado (recursivamente o por iteraciones).
b ) Si el numero esta dentro del intervalo del factor difuso y especular, estaremos ante una reflexion o refraccion, dependiendo del factor de opacidad. Si el foton es reflejado, no se guarda en el mapa de fotones, y se lanza de nuevo con una direccion calculada por la tipica formula de reflexion fisica(si la quereis me lo decis que ahora no me acuerdo) y con la energia multiplicada por el color del objeto y su factor especular. Y lo mismo pasa si es refractado, exceptuando que hay que lanzarlo a traves del objeto, teniendo en cuenta indices de refraccion tanto para la entrada como para la salida. Igualmente no se guarda en el mapa de fotones. Estos fotones serviran para visualizar las causticas.
c ) Si el numero es mayor que el factor difuso mas el factor especular, el foton es "asesinado" :P, vamos que se absorbe en esa posicion, con la energia multiplicada por el factor de opacidad de ese objeto, si el objeto es (algo) opaco o (algo) difuso.
Como veras el foton lleva una energia inicial y la va propagando a traves de la escena. Mientras que, como luego explicare, el rayo va ganandola.
2)
Visualizacion del mapa de fotones:Ahora que tenemos un mapa de fotones con sus energias y posiciones, llega la hora de usarlo para renderizar la imagen. Lo que se usa es algo parecido al back ray tracing. Se lanza un rayo por cada uno de los pixeles de la "pantalla" y se comprueba la interseccion con los objetos de la escena. Si ese rayo no intersecciona a un objeto, el color del pixel sera negro. En el caso de que interseccione se estima la densidad en ese punto. Esto se lleva acabo, encontrando los fotones mas proximos al punto con una cierta distancia y/o numero de fotones encontrados de limite. Luego se calcula la contribucion energetica de cada uno de estos fotones y ya tenemos el color del pixel.
Este es el algoritmo en su forma mas simple. Luego Henrik Jensen, el autor de este algoritmo, nos explica que para sacarle el maximo provecho se debe de implementar una solucion mezclando mapa de fotones y ray tracing, ademas de usar filtros, formulas de distribucion de fotones mas eficientes, etc...
Realmente lo bueno que tiene el mapa de fotones es que para las causticas y la iluminacion indirecta es mucho mejor que el ray tracing. De hecho con apenas 20k fotones tienes unas causticas muy reales.
Ray tracing:Basicamente lo que hace el trazado de rayos, es lanzar un haz de rayos por cada pixel de la "pantalla". Cuando un rayo intersecciona a un objeto difuso se calcula en ese punto un factor de iluminacion que coloreara al pixel. Este factor de iluminacion vendra dado por cada luz de la escena y el color del objeto. Si el objeto es especular o transparente, el rayo se refleja o refracta y se vuelve a hacer lo mismo. Ademas, existen otro tipo de rayos para calcular las sombras, aunque por lo que he visto se han de usar un monton de rayos para conseguir un resultado decente.
De momento eso es lo que os puedo decir, sin miedo a equivocarme mucho del ray tracing. Si quereis mas info buscarla
aqui. Es un tutorial de como hacer un ray tracer.
Espero que te haya aclarado algo ethernet, si tienes mas dudas pregunta! :D ya sabes que cuando alguien ha hecho algo esta encantado de explicarlo hasta la extenuacion... :P
Un saludo,
Rubén
PD: aqui teneis el render que os habia dicho antes, acaba de terminar ahora. :P Me estoy fijando y no tiene causticas... habre configurado mal las propiedades de la esfera. Voy a ver si tiro un render con causticas, que quedan muy chulas :D
(http://img471.imageshack.us/img471/241/segundopase15201887us.th.png)
Muy chulo. Cuanto puede tardar el render de una escena como las que estas mostrando?
Cita de: "Marci"Muy chulo. Cuanto puede tardar el render de una escena como las que estas mostrando?
Pues exactamente no te se decir, pero para el render del primer post unos 30 minutos. Para el segundo unas 2 o 3 horas.
De todas formas, no esta para nada optimizado. Habría que mejorar el sistema de intersecciones (he usado la funcion de D3DX de interseccion), creando yo mismo las funciones de interseccion con las primitivas. Teoricamente, no es para nada complicado y deberia mejorar bastante el tiempo.
Tampoco me ha dado tiempo a mas, la verdad. Ahora hay un monton de cosas por mejorar y hacer. Por ejemplo, las refracciones no son del todo fisicamente correctas, ya que no he tenido en cuenta la Ley de Beer para la transmision de luz... o meterle texturas... o mejorar la primitiva de esfera y que sea realmente una esfera...
Por cierto, aparte de por el proyecto en si, estoy bastante orgulloso por que este es el primer proyecto "complejo" que acabo y mi segundo en esto de los graficos. :)
Muy interesante la explicación, tengo que masticarla :)
[OFFTOPIC]
Creeis que algún dia sera posible ray tracer o fotones por GPU en tiempo real? (uoh)
[/OFFTOPIC]
Cita de: "Marci"[OFFTOPIC]
Creeis que algún dia sera posible ray tracer o fotones por GPU en tiempo real? (uoh)
[/OFFTOPIC]
Hay cantidad de ray tracers implementados integramente en la GPU y renderizan en tiempo real.
En cuanto a mapa de fotones, aun estan sacando papers que explican como hacerlo en tiempo mas o menos real, aunque se acercan un monton les queda bastante. Si te interesa, busca algun paper de Purcell.
Hi,
he mejorado algunas cosillas y arreglado otras.
Lo mas destacable es que las esferas ahora, son perfectas. Esto se podia conseguir de dos formas, o bien interpolando las normales de los vertices de la malla de la esfera para obtener la normal en el punto de interseccion. O usar un par de calculos vectoriales para obtener el punto de interseccion y la normal. La primera opcion la implementaba con una funcion de intersecion de d3dx, por lo que con tantas caras relentizaba muchisimo. En cambio, con la segunda opcion, va m�s rapido y los resultados son iguales.
Además, he usado interpolacion lineal para sacar la normal en el punto de interseccion para objetos que usen el metodo de interseccion de d3dx. Basicamente, tengo una clase cModelo3d que implementa un metodo virtual getInterseccion(), implementado con D3DXIntersect(...). Luego tengo clases que heredan de esta clase como cEsfera, cTetera, ... Para primitivas, sobreescribo el metodo y para el resto uso el heredado. Esto implica que ahora los objetos "complejos", como la tetera, tendran un aspecto suavizado y no con "caras visibles" como se puede apreciar en las esferas y teteras de los renders que puse al principio.
Aqui teneis algunas imagenes en donde se pueden apreciar, por ejemplo, las causticas que producen objetos transparentes y reflexivos.
(http://img117.imageshack.us/img117/2692/segundopase1887281im.th.png)(http://img117.imageshack.us/img117/3522/primerpase18830112pr.th.png)(http://img104.imageshack.us/img104/1743/segundopase18915494ut.th.png)(http://img117.imageshack.us/img117/8215/primerpase18935527lh.th.png)(http://img240.imageshack.us/img240/5229/segundopase18105303pp.th.png)Este fin de semana intentare retocar las ultimas cosillas, y poner aqui el binario para que lo probeis y me digais que os parece. Por cierto, ¿donde podría subir un zip con el binario?
Un saludo,
Rubén
CitarEste fin de semana intentare retocar las ultimas cosillas, y poner aqui el binario para que lo probeis y me digais que os parece. Por cierto, ¿donde podría subir un zip con el binario?
Yo tengo sitio libre. Si quieres me lo mandas y lo cuelgo.
Cita de: "Marci"
Yo tengo sitio libre. Si quieres me lo mandas y lo cuelgo.
Muchas gracias! :D
En cuanto le de un par de retoques mas, te lo mando.
Me ha hecho ilusion ver este thread. Primero de todo felicitarte por tu trabajo, tiene un acabado perfecto.
Yo tambien programé un sistema de fotones para mi raytracer (
screenshot). Veo que has usado kdtrees, yo al final dudé y lo hice mediante lighmaps para almacenarlos y el resultado era sensiblemente inferior.
Uno de los ejemplos en los que se ve la potencia del algoritmo era haciendo causticos sobre agua, basta con que lances los fotones contra una superficie que los perturba en función de un perlin noise o una sinusoidal y la escena queda muy chula.
Te recomiendo que uses la clasica cornellbox para las pruebas, suele quedar muy bien y es un momento.
Por cierto, una pregunta, tú como resuelves el tema de la luz especular?
Un saludo.
Hi,
gracias! pero la verdad es que aun no esta acabado... :rolleyes: Faltan un monton de cosas, entre otras:
+Añadir texturas.
+Añadir la escena de la "caja de cornell".
+Añadir el modelo del "conejo resulton" tipico de papers del siggraph. :P
+Rehacer el algoritmo de lanzamiento de fotones (no me gusta para nada el que he implementado) y cambiarlo a un metodo de Monte Carlo.
+Añadir la ley de Beer a las refracciones.
+Añadir el modelo de Schlick a las reflexiones.
+Limitar la estimacion de densidad por numero de fotones en vez de radio.
+Añadir de alguna forma al interfaz de configuracion la posibilidad de meter distintos medios participativos: agua, humo, ...
+Implementar el algoritmo para que sea capaz de renderizar en medios participativos(tiene tela).
+Dividir el mapa de fotones en dos: iluminacion indirecta y causticas.
+Hacer la iluminacion directa por ray tracing.
+Comprobar la eficiencia de la implementacion del KDTree.
+Un largo etc....... :P
Aunque no creo que para la entrega del proyecto me de tiempo a hacer todo eso... entrego la semana que viene :) De todas formas, con haber hecho la iluminacion directa e indirecta ya cumplia los objetivos del mismo. Asi que, el resto que he hecho es un "bonus"... :P
En cuanto a los objetos especulares: uso ray tracing. Segun Jensen, autor del algoritmo de mapa de fotones, para que las estimaciones de densidad en las superficies reflexivas fueran correctas el numero de fotones seria muy elevado. En la iluminacion directa y reflexiones un Monte Carlo ray tracing obtiene mejores resultados que el mapa de fotones. Y el mapa de fotones, en causticas e iluminacion indirecta(sombras) obtiene un resultado muy bueno en muy poco tiempo, en comparacion con el ray tracer. Lo suyo es hacer una mezcla de los dos.
Aqui os dejo la tetera, por fin, suavizada:
(http://img230.imageshack.us/img230/2194/segundopase181258117iu.th.png)Un saludo,
Rubén
Hi,
he modificado algunas cosillas:
+Añadidas texturas: Ahora puedes poner texturas a los objetos. Es un simple mapeado esferico (coordenadas polares) para la esfera y la tetera. Y el cubo, pues no se como llamarlo, asi que aqui teneis el codigo.
D3DXVECTOR3 ejeU(normal.y, normal.z, -normal.x);
D3DXVECTOR3 ejeV;
D3DXVec3Cross(&ejeV, &ejeU, &normal);
float u = D3DXVec3Dot(&posicion, &ejeU);
if(u < 0)
u *= -1.0f;
float v = D3DXVec3Dot(&posicion, &ejeV);
if(v < 0)
v *= -1.0f;
D3DXCOLOR cRet = getTexel(0, u , v);
cRet.r *= color.r;
cRet.g *= color.g;
cRet.b *= color.b;
cRet.a = 1.0f;
return cRet;
No tiene ningun filtro. Iba a meterle el filtro bilineal, que es muy sencillito, pero la verdad, es que si le meto mas tiempo a esto no voy a aprobar ni una....
+Modificadas las transparencias aplicandole la ley de Beer: asi que, ahora cuanto mas grueso sea el objeto mas oscuro se vera la imagen transparentada.
Esta noche le pasare a Marci el zip con todo para que lo suba, lo probeis y me digais que tal lo veis.
Y aqui os dejo un par de nuevas capturas:
(http://img216.imageshack.us/img216/7347/segundopase202331436nd.th.png)(http://img524.imageshack.us/img524/6101/segundopase202147175pn.th.png)Un saludo,
Rubén
Hey, no está mal, nada mal. (ole)
Hi,
gracias a Marci (ole) que me ha dejado espacio para subir el proyecto.
Os lo podeis descargar de
AQUI.
Info util:
+Teneis un Leeme.txt que viene muy bien leerselo, ya que no es excesivamente sencillo configurar una escena.
+El proyecto esta compilado contra el sdk de directx de febrero del 2006.
+Teneis en la carpeta de datos varias texturas de prueba.
+Para aplicar una textura correctamente, seleccionar un objeto (Presionar o y el objeto seleccionado se convertira en una malla para indicar que esta seleccionado), pulsar el boton aplicar textura, seleccionais una textura y presionais OK.
Además os dejo unos renders con texturas y causticas. Estan inspirados en un render del libro de Jensen. :P
(http://img312.imageshack.us/img312/5653/segundopase211714564bt.th.png)(http://img312.imageshack.us/img312/9537/segundopase2118255en.th.png)Espero vuestros comentarios! malos o buenos.... (asco) (asco)
Un saludo,
Rubén
He estado probando la aplicación y me ha parecido un gran trabajo. Felicidades. (ole)
Como ya te comente por privado, al principio me salia un mensaje diciendo que faltaba la dxdx9_29.dll. Baje la libreria y me funciono sin ningun problema. Creo que la libreria viene con el sdk pero no forma parte de la version de usuario.
Positivo
----------
La interfaz esta muy bien diseñada y es atractiva.
Calidad final del render buena. Crea unas escenas estupendas
No tan positivo
-------------------
Problemas con el ratón y los botones.
El editor corre con privilegios muy altos y consume demasiados recursos. Ocurre lo mismo una vez que se termina el render.
Aliasing en algunas escenas.
Ideas
-------
Posibilidad de añadir un plano para que haga de suelo.
Posibilidad de cargar/guardar la escena
En general el programa me ha causado una impresion muy buena. Si yo fuera el profesor de la asignatura de graficos te daba un 4 :P
Hi,
gracias por probarlo! :D
A ver, por partes:
+Interfaz de usuario:
No me pedian una interfaz de usuario, pero queria poder configurar una minima escena. Asi que reuse el gui del sdk de directx. Existen problemas a la hora de seleccionar los botones, menus, etc.. Hay que pinchar un pelin mas abajo. No tengo ni idea de porque y tampoco he tenido tiempo para corregirlo. De todas formas, espero hacer en este verano un programa de configuracion de escenas en c# y windows forms que me permita crear escenas sencillas e ir añadiendo algoritmos a base de modulos: ray tracer, radiosidad, mapa fotones, ...
CitarEl editor corre con privilegios muy altos y consume demasiados recursos. Ocurre lo mismo una vez que se termina el render.
Efectivamente, el programa cuando esta ejecutando tanto el primer pase como el segundo consume muchisimo, pero es que es asi. El algoritmo no corre dentro del "loop" de la actualizacion de la pantalla, por eso se queda sin refrescar. Es algo hecho a proposito. No queda muy bien, pero es pasable. Lo de los niveles de privilegios no tengo ni idea de a que te refieres.
Y si, lo unico es que al final cuando renderiza, come muchisimos recursos. No tengo ni idea de por que. Voy a echarle un ojo luego, a ver si hago algo raro en la actualizacion del frame.
CitarAliasing en algunas escenas.
¿Te importaria poner alguna imagen? Asi veo a que te refieres exactamente.
Gracias por las ideas:
+Lo de poner un plano lo tengo implementado pero no probado ni añadido...
+Lo de cargar/guardar escenas es lo suyo. Seguramente me hubiese ahorrado tiempo a la hora de configurar escenas...
Seguramente lo que haga es dejar como esta el proyecto y comenzar lo de la aplicacion en c# y windows forms para tener un configurador de escenas sencillo. Luego meterle el modulo de mapa de fotones, reusando mucho codigo de este proyecto y mas tarde, empezar con ray tracing.
Un saludo,
Rubén
Con lo de los recursos me referia a que es normal que cuando hace los calculos consuma mucho tiempo de procesador, pero el editor no deberia hacerlo. Solo con el editor funcionando en el administrador de tareas de Windows el programa consume el 100% del procesador sin que se este realizando ninguna tarea (supongo que tienes un bucle refrescando la pantalla). Una vez finalizados los calculos sucede lo mismo, 100% de procesador y ninguna tarea (supongo que el bucle de nuevo). Ya se que no tiene nada que ver con el objetivo del proyecto pero me parecio interesante comentarlo.
Respecto al aliasing, si te fijas en la imagen de la tetera que pusiste el 1805/06 @ 20:19 se ven los bordes de la tetera dentados. No estoy muy puesto pero creo que despues del trazado de rayos-fotones habría que añadir otra pasada para difuminar los bordes. No se si tienes como objetivo lograr una imagen final lo mas realista posible o solo implementar el mapa de fotones pero podrias añadir algo para eliminar el aliasing como usar el accumulation buffer (por lo menos con OpenGL se puede hacer asi bastante sencillito).
Valep, ya se a que te refieres con lo de los recursos. Voy a repasar el codigo del editor y el del final del render a ver que demonios le pasa... ;) ¿alguna intuición de que podrÃa estar pasando?
En cuanto a lo del aliasing, he ojeado algun libro de graficos buscando este tema y se que hay tecnicas para mejorar el aliasing despues del trazado de rayos. Lo del accumulative buffer de opengl ni idea, sinceramente :P . Para el siguiente que haga lo tendre en cuenta.
Sólo comentar que el curro que te has metido es impresionante Ruben.
Un proyecto para poner en un curriculum de excelente categoria, sigue así :)
CitarValep, ya se a que te refieres con lo de los recursos. Voy a repasar el codigo del editor y el del final del render a ver que demonios le pasa... ¿alguna intuición de que podrÃa estar pasando?
Sin ver el codigo es bastante aventurado pero yo apostaria a que tienes un bucle de dibujo y le estas mandando continuamente dibujar el editor, cuando bastaria solo con refrescar la imagen si hay cambios. Con el render final pasaria lo mismo, una vez que muestras la imagen no necesitas dibujarla continuamente, solo tienes que hacerlo si hay que actualizar la ventana por algun motivo. No se me ocurre nada mas. De todos modos no te comas mucho el tarro que no parece tan importante y metelo en el bote de las mejoras para la segunda version :D
El aliasing se resuelve por supersampling, basta con que traces muchos más rayos por pixel de la imagen con una ligera desviación (que no supere 1) y que despues hagas un promedio.
Yo tenía una matriz con desviaciones, que eran pares de x,y. Antes de trazar un rayo cogía una desviación de la matriz, y desviaba el rayo segun ella, al final el resultado lo promediaba con los anteriores aunque el sistema correcto es convolucionar.
Aquí puedes ver el resultado:
(http://www.tamats.com/uploads/resultado_raytrace.jpg)
Cita de: "tamat"Yo tenía una matriz con desviaciones, que eran pares de x,y. Antes de trazar un rayo cogía una desviación de la matriz, y desviaba el rayo segun ella, al final el resultado lo promediaba con los anteriores aunque el sistema correcto es convolucionar.
Realmente la convolución es la operación usada para aplicar filtros a señales, en este caso 2D, y el promedio (o filtro paso bajo) es una convolución, con lo cual realmente estás haciendo una convolución no?
La imagen está chula ^^.
Hi,
muchas gracias por los comentarios, se agradecen un monton (ole)
Lo que voy a hacer es finalizar el proyecto, es decir, dejar de tocar codigo en el. Hay cantidad de cosas por hacer y mejorar, pero no me gusta nada el actual diseño del proyecto. Ha cumplido con creces los objetivos por los cuales lo diseñe, pero ya no da para mas.
Asi que lo primero que voy a hacer es separar el sistema de configuración del sistema de renderizado. El sistema de configuracion lo hare con windows forms y mdx. El sistema de renderizado seran modulos, que se añaadiran al sistema de configuracion. Asi podre dedicarme solo y exclusivamente a implementar el algoritmo de turno y simplemente seguir un interfaz para añadirlo al sistema de configuracion.
El framework (maquina de estados, wrapers para cargar modelos, etc...) que hice, ha evolucionado un monton gracias a este proyecto y lo usare para desarrollar "juegos". Aunque le queda un monton de detalles que limar y rehacer, al menos tengo la intencion de hacer un pong con el :P
De todas formas, a ver como termino la carrera y sobre todo cuando! :P Deberia terminar en junio, asi que hasta julio no podre ponerme seriamente con todo esto... A menos que me pase como siempre, que en vez de estudiar me ponga con lo que me divierte... :rolleyes: :rolleyes:
Un saludo,
Rubén