Depth Of Field

[zupervaca]

 yo pienso que estos efectos ya los podrian hacer los programadores que quieran usar el motor ya que simplemente son shaders

saludos

[[EX3]]

 Menudos resultados esta dando vuestro motor, mi enhorabuena por vuestro excelente trabajo, 'tais' echos unos cracks (ole)

Salu2 y seguid asi

[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:

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.

[samsaga2]

 

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:

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?
 

[vincent]

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.

[samsaga2]

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).

[BeRSeRKeR]

 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.

[Haddd]

 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  

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 !

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:

Código: [Seleccionar]

Haddd.Scene.CreateDOFEffect()

   

[zupervaca]

 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
 

[seryu]

 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    

[BeRSeRKeR]

 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 ) 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.

[zupervaca]

 cada uno hace su proyecto como quiere que para eso es suyo  , 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
 

[Pogacha]

 

cada 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.

[Haddd]

 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.

 

[BeRSeRKeR]

 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.