Esta tarde se ha implementado el Depth of Field y la verdad es que ha quedado bastante bien. Hemos tenido que reducir el número de samples (hemos utilizado una distribución del tipo Poisson) a 5 porque si no nos quedábamos sin registros. :D
Este es el resultado:
(http://www.arrakis.es/~jonathan01/stratos/dof.jpg)
Por si os interesa me he basado en el paper de Thorsten Scheuermann (ATI),
Advanced Depth of Field.
Saludos.
Ultimamente me estais dando unas ganas de meterle mano a la V2 cuando salga, q no veas.... ;)
Con cada post de BeRSeRKeR me entra más complejo de inferioridad... :huh:
Buen trabajo!!!
saludos
La imagen es una pasada (uoh) Yo creo que tendría que aparecer en el diccionario de palabras técnicas, al lado de Depth Of Field, es un ejemplo perfecto :D
Es una pena no tener shaders 3.0, y más todavía que NVidia no pusiera en sus tarjeta 2.0 los MRT. :( Lo que tenemos que hacer para que salga... B)
Y Ber lo ha implementado en unas horas...si es que.... (genial)
esta muy chulo, aunque este es el tipico efecto que puesto en un juego demuestra lo 'tonto' que es meter tecnologia a saco 'porquesi'. Todavia recuerdo el MOD de half life 2 depth of field donde parecia que jugabas con gordon sin gafas :blink:
Hola,
Yo no entiendo un pimiento, pero como mola... :D Un saludo!
Vicente
Genial el efecto Berserker! A ver cuando pones un vídeo para que se pueda apreciar bien en movimiento :)
Haddd: no necesitas shaders tan avanzados para hacer DOF, incluso puedes hacerlo perfectamente sin pixel shaders con el mismo resultado. Que añade el 3.0 exactamente para que se pueda hacer mejor? MRT? no los he mirado todavía.
Ea, a seguir dándole caña al proyecto que os está quedando cojonudo :D
Vaya, no estaba identificado. El mensaje era mío O:)
Juas, nada que ver con el ejemplo cutre de las DirectX. Y os vendrá muy bien para usar técnicas cinematográficas en vuestras demos con historia, o en cutscenes en el juego.
Ahora que veo a Ithaqua por aquí se me ocurre que con lo que tenéis ahí entre tecnología y talento podéis hacer una demo y presentarla en alguna party.
Pues eso, felicidades y a seguir así.
Se veria mejor si la foto la hubieses sacado con una camara no digital con el enfoque en omega y así no te hubiesen salido borrosas las esferas de atras, pues seguro que la tomaste con una camara digital.
Cita de: "Pogacha"Se veria mejor si la foto la hubieses sacado con una camara no digital con el enfoque en omega y así no te hubiesen salido borrosas las esferas de atras, pues seguro que la tomaste con una camara digital.
Hmm. No se si es una broma o no entiendo tu post, pero
a) eso no es una foto, es un screenshot de un render en tiempo real (para algo estamos hablando del motor)
B) el difuminado de las esferas de más atrás
es el efecto que han implementado, no es ningún fallo o comportamiento indeseado.
Citar
Haddd: no necesitas shaders tan avanzados para hacer DOF, incluso puedes hacerlo perfectamente sin pixel shaders con el mismo resultado. Que añade el 3.0 exactamente para que se pueda hacer mejor? MRT? no los he mirado todavía
En realidad para hallar el color final se hace un filtro Poisson ( que es una esfera de sopa de puntos) de 10 samples. Debido a las limitaciones del 2.0, sólo podemos utilizar 4 samples <_<
Y claro, al no poder utilizar MRT, tenemos que hacer dos pasadas, cuando con 1 quedaría resuelto.
Cita de: "fiero"Con cada post de BeRSeRKeR me entra más complejo de inferioridad... :huh:
Completamente de acuerdo con esta afirmación. Yo creo que me voy a retirar de esto de los videojuegos :P
Mu chulo el efecto! (ole)
Quizás está mal que ithaqua lo diga, pero yo no. En Arise (
http://www.pouet.net/prod.php?which=12850 ) hay un efecto de DOF al comienzo de la demo y creo recordar que Ithaqua, en el making of publicado en la becanne03 (
http://www.becanne.net/ ), comentaba como hacer el efecto.
Está muy bien, tenemos ganas de ver el video con todas esas cosas nuevas.
Esta muy currado el efecto pero un motor 3d no vive solo del render. ¿Como llevais el tema escenario y fisicas?
yo pienso que estos efectos ya los podrian hacer los programadores que quieran usar el motor ya que simplemente son shaders
saludos
Menudos resultados esta dando vuestro motor, mi enhorabuena por vuestro excelente trabajo, 'tais' echos unos cracks (ole)
Salu2 y seguid asi ;)
Muchas gracias por los comentarios.
La verdad es que como dice seryu, este efecto para utilizarlo in-game pues la verdad, no sirve de mucho. En realidad al implementarlo lo hemos hecho pensando en las secuencias cinemáticas. Tal vez lo utilicemos para el próximo video. Ahora tendré que modificar el exportador de cámaras para que el grafista pueda jugar con el DOF.
Por otra parte tengo que decir que una vez que Haddd me explicó cómo funcionaba el sistema de postproducción que desarrolló, implementar el efecto fue cuestión de unas pocas horas así que bueno, ¡¡parte del mérito es de él!!. :)
EDITADO:Cita de: "samsaga2"Esta muy currado el efecto pero un motor 3d no vive solo del render. ¿Como llevais el tema escenario y fisicas?
Sobre la física que responda Haddd. :)
En cuanto a los escenarios, se ha implementado un sistema basado en sectores/portales. La verdad es que con MAX es un poco engorroso este tema y el sistema no es que vaya a ser definitivo pero bueno, de momento nos sirve para crear grandes escenarios y descartar muchas partes con muy pocos cálculos. Eso sí, cosas del portal rendering, está muy bien para interiores pero para exteriores habrá que utilizar otra solución tipo octrees. Eso sí, juntar ambas técnicas no debería ser mucho problema. También pensé en implementar anti-portales (creo que Unreal hacía/hace uso de ellos), es decir, todo lo que esté dentro de un anti-portal, no es visible, una forma de oclusión. Podría venir bien por ejemplo para terrenos. Se podría poner un anti-portal en una montaña y así descartaríamos todo lo que hay detrás. Evidentemente también se podría utilizar para los interiores.
Saludos.
Cita de: "BeRSeRKeR"Muchas gracias por los comentarios.
La verdad es que como dice seryu, este efecto para utilizarlo in-game pues la verdad, no sirve de mucho. En realidad al implementarlo lo hemos hecho pensando en las secuencias cinemáticas. Tal vez lo utilicemos para el próximo video. Ahora tendré que modificar el exportador de cámaras para que el grafista pueda jugar con el DOF.
Por otra parte tengo que decir que una vez que Haddd me explicó cómo funcionaba el sistema de postproducción que desarrolló, implementar el efecto fue cuestión de unas pocas horas así que bueno, ¡¡parte del mérito es de él!!. :)
EDITADO:
Cita de: "samsaga2"Esta muy currado el efecto pero un motor 3d no vive solo del render. ¿Como llevais el tema escenario y fisicas?
Sobre la física que responda Haddd. :)
En cuanto a los escenarios, se ha implementado un sistema basado en sectores/portales. La verdad es que con MAX es un poco engorroso este tema y el sistema no es que vaya a ser definitivo pero bueno, de momento nos sirve para crear grandes escenarios y descartar muchas partes con muy pocos cálculos. Eso sí, cosas del portal rendering, está muy bien para interiores pero para exteriores habrá que utilizar otra solución tipo octrees. Eso sí, juntar ambas técnicas no debería ser mucho problema. También pensé en implementar anti-portales (creo que Unreal hacía/hace uso de ellos), es decir, todo lo que esté dentro de un anti-portal, no es visible, una forma de oclusión. Podría venir bien por ejemplo para terrenos. Se podría poner un anti-portal en una montaña y así descartaríamos todo lo que hay detrás. Evidentemente también se podría utilizar para los interiores.
Saludos.
Lo del antiportal tiene buena pinta pero la verdad es que no es facil implementarlo... avisad cuando lo tengais y chafardeo el codigo fuente :rolleyes:
Otra pregunta... habeis notado mucho la diferencia de velocidad con respecto del c++ al c# o la diferencia es minima?
Cita de: "BeRSeRKeR"También pensé en implementar anti-portales (creo que Unreal hacía/hace uso de ellos), es decir, todo lo que esté dentro de un anti-portal, no es visible, una forma de oclusión.
Con poner un sistema de flags en el portal ( normal, con textura transparente, espejo, antiportal) y dibujar en función de este flag ya estaria, no?
VinCenT.
Cita de: "vincent"Cita de: "BeRSeRKeR"También pensé en implementar anti-portales (creo que Unreal hacía/hace uso de ellos), es decir, todo lo que esté dentro de un anti-portal, no es visible, una forma de oclusión.
Con poner un sistema de flags en el portal ( normal, con textura transparente, espejo, antiportal) y dibujar en función de este flag ya estaria, no?
VinCenT.
No serviria porque la forma de cortar el view-frustum contra el anti-portal no tiene nada que ver con cortarlo contra un portal normal. Contra un portal normal el view-frustum se va haciendo cada vez mas pequeño y contra un anti-portal el view-frustum se va "deformando" (por decirlo alguna forma).
Yo en principio no pensé en los anti-portales como un medio para recorrer la escena sino como un método de oclusión, es decir, si me encuentro un anti-portal, creo un frustum a partir de él y todo objeto/portal que esté dentro no se procesaría y ya está, no se haría nada más. En definitiva, en este caso un anti-portal no conectaría dos sectores (supongo que eso es evidente) sino que serviría para ocultar objetos tras objetos grandes (una gran columna, una montaña, etc).
Saludos.
La física utiliza el motor Newton. Es un gran motor, me gusta mucho y tiene la enorme ventaja de estar hecho en C. Todos direis...pero que locura. Pues sí, pero al no tener ninguna estructura, la conversión a C# es casi trivial. Luego me monto yo las clases y listo.
Actualmente controlamos la colisión con el mundo, los objteos reaccionan a la física y demás. Está bastante integrado en el motor. Eso sí, falta TODO el tema de joints, que no he mirado nada todavía, pero estoy en ello :D
Tenemos el alogritmo de IA y los genéticos desarrollados por Vicente y está en vias de integrarlo en el motor para responder a las colisiones con el mundo.
Respecto al sonido, pues leemos vorbis a traves de una vorbisdotnet.dll y realizamos sonido 5.1 o 3D en su defecto con todos lo posibles efectos que suministra DSound.
Así que tenemos exportadores, sonido, shaders, sombras, animación de personajes, portales, física, IA...¡tenemos un motor de juegos! (uoh) ¡ por fin !
Citar
Zupervaca:
yo pienso que estos efectos ya los podrian hacer los programadores que quieran usar el motor ya que simplemente son shaders
Ya, pero la gracia está en poner en el motor:
Haddd.Scene.CreateDOFEffect()
;)
no me mal interpretes, me parece bien que los pongais, pero en el ejemplo que has puesto es el problema que le veo, demasiado sencillo, si el programador que esta usando vuestro motor necesita una variacion especial de ese efecto no aprovecara eso que habeis hecho, a mi forma de ver las cosas lo mejor es que hagais pequeños "agregados" al motor con efectos de este tipo, pero siempre por separado, es una idea mas, ademas al tenerlo separado del motor siempre das la oportunidad de que la gente os mande efectos por correo, etc
saludos
siendo open source, ya dan la oportunidad de que cualquiera envie su efecto, o subsistema de lo que sea, para agregarlo al motor.
Por otro lado, siendo fruto de solo una tarde de trabajo, dile tu a berserker que no lo haga. Hay que conocer la mente de un programador para saber que cuando le entra el gusanillo de programar algo no se le puede decir haz esto otro que es más práctico.
Porque práctico, lo que se dice práctico, no se suele buscar eso en la programacion 'de tiempo libre'.
Saluditos ;)
La verdad es que estaba un poco saturado de tanto exporter y portales y me apetecía hacer algo más "agradable" así que le pregunté a Haddd qué podría hacer y me dijo que el DOF estaría bien. Así que me puse a ello.
Está claro que hay cosas que urgen más pero como aquí no hay presiones pues uno se puede dedicar a hacer lo que le venga en gana, por lo que ya no se trata de qué es lo más conveniente para el motor sino lo que a uno le apetece hacer. En este caso del DOF, yo no había desarrollado este efecto en mi vida, así que era una buena excusa para hacerlo. :)
Algo parecido me pasó con los MD5. Estuve unas dos semanas pensando y desarrollando todo el sistema de animación (y aún quedan algunas cosillas por pulir :D) y claro, acabé de MD5 hasta el gorro. Aunque aquella vez, en vez de programar otra cosa más ligera, directamente me tiré unos días sin tirar ni una sola línea de código. (ole)
Saludos.
cada uno hace su proyecto como quiere que para eso es suyo :D, a lo que me refiero yo es que por ejemplo esa linea que has puesto de codigo me parece estupenda, pero ya has asociado un efecto al objeto de la escena, cosa que muchos como yo pensaran que no es del todo correcto, muchos pensaran que se asocie a la camara otros a la escena, etc yo creo que los efectos no deberian estar asociados a nada y activar o desactivarse cuando quieran ya que los shaders permiten esa flexibilidad es recomendable no eliminarla, solo me refiero a eso
un saludo
Citarcada uno hace su proyecto como quiere que para eso es suyo
Muy buena frase, a menudo me parece que me olvido de eso.
En este caso creo que Haddd y BeRSeRKeR no lo olvidaron nunca, lo cual le da ese
toque al motor ... yo no coincido en la forma de encarar muchas temas, pero no he querido nombrarlos (por mas que lo haria con la intencion de ayudar) para no romper su esquema con el cual han hecho esos logros, todo lo que han hecho es por que lo han hecho a su modo y cada vez que plantean una solución es distinta a la que yo hubiese hecho, esto es por que las soluciones estan adecuadas a su motor y no para otra cosa lo cual seria absurdo ... ¿verdad?.
Saludos.
Bueno, en realidad, no se puede hacer un motor tan abierto que permita todas las posibilidades y tan sencillo de programar que en unas líneas puedas hacerlo todo. Tienes que tomar decisiones de estructura, de diseño del motor, que evidentemente para según que cosas no irían muy bien.
Seguimos apostando por la simplicidad, que en unas pocas líneas podamos desarrollar cualquier ejemplo. Pero claro, cada vez que añadimos un efecto "importante", como DOF, intentamos "facilitar" al desarrollador su utilización, simplemente activándolo y asignando los parámetros que quiera.
Bueno, yo en principio tampoco comparto del todo la forma en la que se ha desarrollado desde el principio el motor, pero es la que había cuando llegué y me he adaptado. Pero como se ha dicho yo no estoy metido en el desarrollo de este motor para crear el motor perfecto sino simplemente porque me apetecía probar cosas nuevas y además ver que esas cosas sirven para algo. Porque no vamos a negarlo, empiezan a poder hacerse cosas interesantes con este motor.
Aún así, mi idea para el futuro (espero que próximo, ¿versión 3.0? :)) es hacer que el motor sea totalmente programable sin tocar una sóla línea de código C#, todo a través de scripts. De esa forma añadir cualquier cosa al motor sería cuestión de crear un shader, un material, un script...
Así, cualquier persona sin conocimientos de programación (aunque necesitaría ciertos conocimientos técnicos sobre gráficos 3D) podría crear sus propios efectos (encima estará disponible el editor de materiales que facilitará aún más la tarea) o cualquier recurso disponible. Evidentemente otra cosa es crear vertex & pixel shaders. Ahí si hacen falta conocimientos más profundos sobre teoría del 3D y algo de programación pero para eso estamos creando una librería de shaders que contendrá varios modelos de iluminación y unos cuantos efectos de forma que el usuario final pueda empezar a utilizar el motor con una buena base en sus manos. :)
Saludos.
me parece que sigo sin explicar bien la idea que os planteo, en principio esta idea es para ayudaros a que cuando la gente os envie nuevos efectos no tengais que adaptar el motor, la idea es la clasica de la programacion orientada a objetos, se crea una clase base abstracta con dos metodos en principio, el de creacion del efecto y el de activarlo, asi siempre el que hace el efecto se adapta a vuestro motor y no vosotros a el, aun no se si me he explicado bien (nooo)
saludos
Como he dicho en mi anterior mensaje:
Cita de: "BeRSeRKeR"Aún así, mi idea para el futuro [...] es hacer que el motor sea totalmente programable sin tocar una sóla línea de código C#, todo a través de scripts. De esa forma añadir cualquier cosa al motor sería cuestión de crear un shader, un material, un script...
Eso significa que no hay que tocar el código del motor ni crear módulos extra para añadir nuevos recursos al motor. Todo será cuestión de escribir un script (que evidentemente se tendrá que ceñir a las reglas que imponga el motor), ya sea con un editor de texto o a través de los editores que desarrollemos (materiales, partículas...). De esta forma si un grafista quiere crear recursos (de cualquier tipo) para el motor, no tiene que contar con ningún programador ni con herramientas de desarrollo (pongamos por caso el Visual C# Express). Eso sí, como he dicho, necesitará ciertos conocimientos técnicos. Eso es inevitable (aunque con los editores la cosa se facilita bastante).
De todas formas no está claro que ese sea el rumbo que tomemos, es una cosa que hay que hablar.
Saludos.
zupervaca eres un incomprendido :P.
Como han dicho por arriba al ser de codigo abierto (por ahora, no seais locos y venderlo cuando esté terminado!) se puede modificiar y hacer módulos propios de los usuarios. Pero si enciman tienen esa implementacion (aunque no se adapte con lo que ellos quieran) base ya en el motor implementada, mejor que mejor.
Si total, pa una hora que echó.. que trabaje leñe! (ñshas!! sonido de látigo :P)
Desde que vi la imagen de este post que tenia el gusanillo.... (genial)
Asi que no me he podido resistir y lo he implementado yo tb.
Me ha basado (es casi un cut&paste) en el shader (GLSL) que hay en el RenderMonkey.
(http://img99.imageshack.us/img99/2320/dof16zu.th.jpg)(http://img99.imageshack.us/img99/9046/dof22th.th.jpg)Ahora me falta averiguar como poder hacer de nuevo alpha-blending... pq con el "efectillo" de marras me como el canal alpha :rolleyes: ¿como lo habeis resuelto vosotros?
Citar
En realidad para hallar el color final se hace un filtro Poisson ( que es una esfera de sopa de puntos) de 10 samples. Debido a las limitaciones del 2.0, sólo podemos utilizar 4 samples
Haddd, puedes explicarme esto mejor? Cuando dices que solo se pueden utilizar 4 samples te refieres a que solo se pueden leer 4 texturas en el shader?
Bonito DOF. :)
Cita de: "Lord Trancos 2"Ahora me falta averiguar como poder hacer de nuevo alpha-blending... pq con el "efectillo" de marras me como el canal alpha :rolleyes: ¿como lo habeis resuelto vosotros?
Si no me equivoco, en Haddd se utiliza un RT para el DOF y el glow por lo que no tenemos problemas con el alpha blending ya que la distancia a la cámara se almacena en el canal alpha de dicho RT y no en el frame buffer.
Cita de: "Lord Trancos 2"Haddd, puedes explicarme esto mejor? Cuando dices que solo se pueden utilizar 4 samples te refieres a que solo se pueden leer 4 texturas en el shader?
Exactamente eso. Pero en realidad el limitador no eran los accesos a las texturas (que se pueden hacer hasta 16, si por eso fuera podríamos hacer 8 samples) sino que era el número de instrucciones artiméticas.
Por lo que veo, el ejemplo que viene con RenderMonkey es diferente al que se presenta en el documento que puse en el primer mensaje.
Saludos.
Cita de: "BeRSeRKeR"Si no me equivoco, en Haddd se utiliza un RT para el DOF y el glow por lo que no tenemos problemas con el alpha blending ya que la distancia a la cámara se almacena en el canal alpha de dicho RT y no en el frame buffer.
Osea, que haceis 2 pasadas (por lo menos) no?
Una para "pintar" y otra para llenar un RT similar al G-Buffer de 3ds Max?
Ahora mismo hacemos:
Una pasada para el ambiente+ZBuffer
Una pasada para las normales ( esto tiene su explicación, porque si no, intentad hacer con shaders 2.0 reflexion+refracción+bumpy )
Una pasada para el Glow(RGB)+DOF(A).
Y al final, lo que hacemos es para ahorrar slots, copiamos el resultado del backbuffer en el mismo RT que tenemos el DOF. De esa forma el shader accede al rgb de la escena y al dof con una sóla lectura.