Had 3d engine v2

[HalfVector]

Bueno pues ya está, los interesados ya podéis descargar el código fuente de los tutoriales, aqué.

El último tutorial trata sobre skyboxes y de paso se muestra el uso de cubemaps para calcular la reflexión y refracción. He adjuntado dos muestras del tutorial.

El efecto que se puede ver es un fake de los glares que se producen cuando se utiliza HDR. El motor también soporta HDR, pero con este truco se consigue un resultado similar, consumiendo menos recursos.

Por cierto, el environment map que he utilizado seguro que os es familiar a muchos. Se trata del grace cathedral de Paul Debevec, aunque no a tanta resolución. Evidentemente el Gaussian Blur que se aplica para recrear los glares no es de tanta calidad como el que se puede ver, por ejemplo, en las imágenes de Fiat lux. No es que no se pueda alcanzar esa calidad, pero claro, más lento iré la cosa. Saludos.

-- IMÁGENES ADJUNTAS --

[8tintin]

Vaya, se me había pasado este post, de hecho, se me había pasado toda la sección nueva. Muy bueno el video, cada vez tiene mejor pinta el motor. A mí me encantaría ayudaros con el juego (como ya os dije una vez), aunque supongo que, el uso de Blender sería problemático? Todavía seguís importando de md5? Saludos.

[HalfVector]

Muy bueno el video, cada vez tiene mejor pinta el motor. A mí me encantaría ayudaros con el juego (como ya os dije una vez), aunque supongo que, el uso de Blender sería problemático? Todavía seguís importando de md5?

Sí, el tema de los escenarios por ahora está restringido a max. Si me decido a crear un exporter para algún otro programa, sería para Blender.

En cuanto a los md5, tiraremos de ellos sí, lo que pasa es que el sistema de animación es quel? Tica aún no está terminado. Tenemos muchas cosas como soporte para múltiples canales. El usuario puede crear diferentes canales que son conjuntos de Bones. Por ejemplo, puede crear un canal para el torso, otro para la cabeza, para las piernas, etc. Entonces después en el motor se puede asignar una animac¿on para cada canal, o sea, una animación para el torso que haga que el personaje dispare, y otra para las piernas para que haga que corra o ande, etc.

También soporta blending entre sets de animación para hacer las transiciones de forma suave.

Pero lo que falta es integrar todo eso de forma que sea funcional y fácil de ser utilizado.

Pero bueno, iré informando sobre el tema por aquí. Saludos.

[8tintin]

S? El tema de los escenarios por ahora está restringido a max. Si me decido a crear un exporter para algún otro programa, sería para Blender.

Estaría muy bien.

En cuanto a los md5, tiraremos de ellos sí, lo que pasa es que el sistema de animación es quel? Tica aún no está terminado. Tenemos muchas cosas como soporte para múltiples canales. El usuario puede crear diferentes canales que son conjuntos de Bones. Por ejemplo, puede crear un canal para el torso, otro para la cabeza, para las piernas, etc. Entonces después en el motor se puede asignar una animac¿on para cada canal, o sea, una animación para el torso que haga que el personaje dispare, y otra para las piernas para que haga que corra o ande, etc.

Eso suena muy bien. Sería como la mezcla de strips de actions distintas en Blender. (y supongo que, debe ser igual con CS o Cat).

Pero bueno, iré informando sobre el tema por aquí.

Gracias, da gusto ver gente haciendo las cosas tan bien. Saludos.

[shenmue]

S? El tema de los escenarios por ahora está restringido a max. Si me decido a crear un exporter para algún otro programa, sería para Blender.

Solo por curiosidad, y sin ánimo de ofender a los blenderianos, pero no tendrías más salidas con Maya? Tengo entendido que la mayoría de usuarios usan tanto max como Maya, incluso puede que Maya acabe superando a max, porque con la de buenos plugins que están sacando ahora, que si el RenderMan de la mismísima Pixar, o el comet muscle. Yo uso max como sabes, no tengo ningún interés en favorecer a ningún software más que otro, solo es que me extraña un poco.

Posdata: espero que los usuarios de Blender no me tiren piedras.

Postdata 2:perdón por el offtopic.

[HalfVector]

La verdad es que el hecho de escoger hacer un exporter u otro va a depender más de la gente que quiera colaborar. Si resulta que la mayoría de gente quiere utilizar Maya, haríamos el exporter para Autodesk Maya, si fueran más los de Blender, haríamos el de Blender. Hasta ahora, en el tiempo que llevamos desarrollando el motor nos hemos encontrado con que casi todos los colaboradores utilizaban max, por lo que casi todas las herramientas de apoyo se han desarrollado para max.

Bien es cierto que siempre intentamos depender lo menos posible de herramientas de terceros. Por ejemplo, tenemos el visor de escenas que permite ajustar la mayoría de los parámetros como, por ejemplo, todo lo relacionado con la iluminación. También tenemos un editor de partículas. Próximamente también haremos un editor de materiales. En fín intentamos hacer nuestras propias herramientas en la medida de lo posible. Evidentemente me parece demasiado, por ejemplo, crearnos nuestro propio editor de niveles teniendo herramientas tan completas como max, Blender, Autodesk Maya, XSI, etc. Aunque hay veces que no hay más remedio que crearse un editor propio porque tal vez la geometría deba cumplir ciertos requisitos que con herramientas de propósito general sería muy complicado (por engorroso) cumplir. Por ahora no es nuestro caso. En principio no tenemos intención de desarrollar un editor de niveles, aunque no descartamos ampliar el editor de escenas para poder insertar entidades, crear dependencias entre entidades, etc.

En fin, los acontecimientos dictar? N la dirección a seguir. Saludos.

[HalfVector]

Hola. Hacía tiempo que no escribía ningún avance por aquí. Lo más importante es que ya tenemos bastante avanzado el manejo de escenarios. Para los interiores utilizamos portal rendering. Los mapas por ahora deben hacerse en 3dsmax y para convertirlos a un formato adecuando para el motor, he creado un compilador que genera los portales/sectores y también un BSP tree que será utilizado para diferentes cosas. Por ejemplo, nos ayuda a saber en todo momento en que sector se haya el jugador o cualquier objeto.

Otra mejora que se ha llevado a cabo afecta a los light shafts. Los light shafts son el típico efecto volumétrico que se asigna a las luces de tipo spot para simular partículas en suspensión. Evidentemente nosotros no podemos utilizar (por ahora) técnicas como raymarching, así que, utilizamos una técnica que se utiliza mucho en la visualización médica. Se trata de crear una serie de slice planes que, simularan la marcha de un rayo (de ahí lo de raymarching) a lo largo del volumen. En este caso el volumen es el frustum de la luz spot. Además, se a añadido proyección de sombras (a través de shadow maps) dentro del propio volumen, de forma que las partículas que hayan debajo de los objetos dentro del volumen, no serán iluminadas. Esto añade más dramatismo a las escenas.

Para que os hagáis una idea, adjunto un pequeño video demostrativo y aquí tenéis una imagen.



Lo único que le queda para quedar más o menos redondo es aplicar noise para simular el movimiento de las partículas dentro del volumen. Pero bueno, ya lo haré.

También hemos implementado Motion Blur, aunque los resultados no son del todo satisfactorios por ahora. Cuando tengamos algo decente que mostrar, así lo haremos. Saludos.

-- IMÁGENES ADJUNTAS --

[Pepius]

Muy bueno.

[Klint]

Qué bien, que ganas de ver más.

[8tintin]

Qué bueno. Para la historia que estáis creando os van a venir de maravilla este tipo de efectos.

[HalfVector]

Gracias. He estado haciendo pruebas con el noise, pero aún no me convence la animación. Una de las pruebas la hice con un noise 2d de baja frecuencia (muy difuminado) haciendo un scroll y la otra es un noise 3d de alta frecuencia. Con este último he capturado un pequeño video. Hubiera sido mejor un noise menos denso, pero es el primero que tenía a mano.

El problema del noise 3d (que está codificado en una imagen 3d en formato dds) es que ocupa mucho, incluso para una textura de 32x32x64 como la del video que ocupa algo más de 1 Mb.

En fin, seguiré haciendo pruebas, aunque hay otras cosas que tienen más prioridad. Por ejemplo, terminar el manejo de escenarios con la visibilidad, control de entidades, triggers, que es lo que más urge en un juego. Saludos.

-- IMÁGENES ADJUNTAS --

[alberizo]

Vaya half que buena pinta, os está quedando un motor muy completo, yo ahora no le estoy prestando mucho interés en cuanto a la programación, ya que aún no dispongo de una gráfica que me lo soporte, estoy ahorrando para cambiar a una PCI-xpress. Sin duda creo que va a ser un motor que va a dar mucho de que hablar, como ya lo está haciendo.

X cierto vuestro video de manejo de escenario me vino de lujo, ya sabes que estoy liado con eso, aún no he podido hacer mucho, tengo unas ganas de programar.

Enhorabuena.

[HalfVector]

Sin duda creo que va a ser un motor que va a dar mucho de que hablar, como ya lo está haciendo.

Bueno, espero que pronto podamos decir que el motor es apto para hacer juegos con escenarios complejos (estamos trabajando en ello). Está claro que sín las optimizaciones que ofrece un sistema de visibilidad no se va a ninguna parte, aunque siempre se pueden hacer pequeños juegos. Por ejemplo, nuestro webmáster se ha currado un juego bastante curioso que hace uso del motor de física y también tiene su encanto gráficamente. La verdad es que cuando lo vi, me sorprendió y todo.

Por cierto, ¿el de tu avatar es Joe satriani? Saludos.

[damiles]

A mi, cuando probé el juego me fue bastante lento, aun teniendo un a máquina normal, pero suficiente como para un juego o lo que le echen.
¿Qué requisitos tiene por ahora vuestro Game Engine?

[HalfVector]

A mí el juego del que hablo me iba fluido en un Pentium 4 3ghz, 1 Gb de Ram y una Radeon 9600 XT. Es complicado hablar de requisitos puesto que realmente no hemos creado ninguna escena lo suficientemente compleja que nos sirva como referencia. Además, como he dicho más arriba, no tenemos terminado aún el sistema de visibilidad, que nos permitiría descartar más geometría y más luces, lo que quiere decir que también nos ahorraría calcular más sombras y más píxel Shaders, que en ciertos casos (dependiendo del brdf utilizado) son bastante costos os de calcular.

De lo que sí se puede hablar es de un requisito indispensable, y es la presencia de una aceleradora con soporte de píxel Shaders 2.0. Lo demás ya depende de la complejidad de la escena, sobre todo del número de luces y de objetos proyectando sombras. Y bueno, la cantidad de efectos que metas, claro.

De todas formas, estamos pensando en volver a dar soporte para lightmaps y añadir Ambient Occlusion. Eso, además de hacer que la calidad gráfica aumentase, haría que el frame rate se disparase considerablemente. Eso no quitaría que pudiéramos combinar todo eso con algunas luces dinámicas. Saludos.