Foros - Stratos

 Pues aquí tenéis otra prueba de mi motor, a ver si los demás se animan a enseñar sus motores también de nuevo.

Es bastante cutrongo, pero bueno, poco a poco se va mejorando.

Pues eso, a ver si os va, fallos que os da, mejoras que haríais y formas de mejorar las cosas ya existentes...
Hay un leeme.txt que explica un poco lo que hay.

En www.agerlands.tk hay algunas screenshots que he hecho durante el desarrollo de esta versión.

Venga pues!  (uoh)  

  (ole)  Está bastante bien,pero las sombras en cada triangulo del bárbaro aparecían muy de repente, no se si el api hará eso de casa pero lo he visto bastante brusco. Otro detalle, a mi desde el ASetup no me rula XDD Lo que mas me ha molado es la deformación de la sombra con el agua entre otras cosas. Una pregunta ¿los modelos proyectan sombras sobre si mismos o el hacha está a parte del barbaro?

 Muy bueno el test, por lo ke me recuerda el escenario en el otra prueba habia 3 modelos de personajes, no?
Animo y sigue con ello, ke cada vez va teniendo mejor pinta  (ole)

Salu2...

 En ventana no me ejecuta, pero pantalla completa si :o
te pongo el log:

Citar
Fichero de Log de NaraEngine Proyecto

NaraEngine -> Creando Engine

NaraEngine <- Creando Engine

Graficos (D3D) -> Inicializando

Clase registrada OK

Ventana creada OK

Interface DirectX9 creado OK

Tarjeta : NVIDIA GeForce4 MX 440

Driver : NVDD32.DLL

Backbuffer : 640 x 480 x 16. Formato = 23.

Seleccionado Depth/Stencil Buffer de 24/8 bits : D3DFMT_D24S8

No se ha podido crear el dispositivo


NaraEngine -> Finalizando

Graficos (D3D) -> Finalizando

Manager de Texturas eliminado, texturas liberadas OK

Dispositivo D3D Liberado OK

Objeto Principal D3D Liberado OK

Clase Desregistrada OK
Graficos (D3D) <- Finalizando


Estadisticas :

Tiempo de Inicio (ms) : 25987567

Tiempo Final (ms) : 25988308

Duracion (s) : 0

Frames Totales : 0

Poligonos Totales : 0

NaraEngine <- Finalizando

y weno, como mejorar las cosas no sabria decirte porq no tengo ni zorra de prog 3D , pero weno, seguro q ya te habias dado cuenta, de q las sombras del enano se ven por debajo del suelo flotando por ahi :P

(http://usuarios.lycos.es/rage182/nara.jpg)

por lo demas, esta de p*** madre  (ole)  sigue asi

 Cosillas rapidas antes de irme :

Sacrifai : El ASetup.exe es simplemente para generar un archivo de configuracion que leera el motor al iniciarse.

Lo del sombreado de los triángulos del enano, supongo que es debido a sus pocos polígonos y que, al generar él la sombra, pues depende de donde esté la luz se van generando los nuevos vértices del volumen, por eso salen tan de repente.

[EX3] : Había tres modelos, pero como tampoco tenía permiso para usarlos he preferido hacer algo más dinámico  :huh: .

nsL : Vaya, de nuevo problemas en modo ventana. Lo curioso es que yo también tengo una MX440 y me funciona bien, incluso con una TNT2 no me da problemas. Esta noche lo miro a ver, muchas gracias por probarlo  ;)

Lo de que se vean las sombras por ahí abajo ya lo sabía sí. Supongo que habría que controlar las colisiones del volumen de sombra con el resto de objetos al crearlo, pero es algo que aún no he hecho.

Gracias por probarlo!  (uoh)  

 Buenas.

Aqui me funciona todo perfecto, tanto el asetup, como a ventana y a completa con 16 y 32 bits.

Lo unico un detalle que me ha estrañado. Las sombras del enano parece q empiezan en las rodillas en vez de en los pies.

Que alguien lo compruebe, q tengo los drivers un poco tocados y tengo que reinstalar el windows uno de estos dias

P.D: Desde pequeño siempre quise ser programador de videojuegos, y poco a poco estoy tomando el camino para conseguirlo. Pero cuando veo y vuestros trabajos con solo pensar q tenga que llegar a hacer eso........vendo pipas, alguien quiere????

 shephiroth gracias por la postdata pero no es para tanto, al menos por mi parte.
Yo no se como hacen sus motores los demas, pero desde luego yo sobre todo últimamente, si me puedo evitar pensar como hacer algo que veo que ya está hecho y está probado que funciona, busco algún tutorial, código o libro (esto último mejor) donde lo explique, veo como lo hacen y como queda el resultado final, y veo la mejor forma de implementarlo en mi motor.
Buenas fuentes de información (y algo de código) para mi motor son o han sido gametutorials, gamedev, flipcode, stratos  (ole) , irrlicht, 32bits.co.uk, el propio sdk de las dx...

De todos modos, ahora lo que quiero es probar el motor haciendo un jueguecillo. Supongo que el concursillo que vamos a hacer será un buen banco de pruebas  (uoh) .

Edit : 400 mensajes ya!!!! ueeeeeeeeeeeee  :huh:
Venga bajároslo los "motoreros" que quiero críticas más duras  :ph34r:

 La idea del "enano" gigante de los escrinchots de tu web me parece muy cachonda XD
Esos efectos de luces dinámicas vendrán muy bien para las bolas de electricidad en el CVRîOS, mola. Los fuegos artificiales están estupendos también :D

 Con tanto colorcillo resulta hipnotico  :lol:

A mi tampoco me ha dado problemas el modo ventana en mi GF MX440.  ;)

Sigue asi.  (ole)  

 Me va perfectamente en la Radeon 9600 XT, tanto a pantalla completa como en modo ventana.

El problema que le veo es el típico de los shadow volumes que se produce cuando la cámara está dentro del shadow volume. Como sabrás, esto lo puedes evitar utilizando el método Carmack's reverse. También está el tema del shadow popping (perdonadme pero no sabría traducirlo :lol:) que se produce principalmente por el bajo poligonaje del modelo.

Yo la verdad es que en la vida he implementado shadow volumes y dudo que alguna vez lo haga. Me parecen un incordio. Además, ahora creo que van a empezar a impornerse los shadow buffers. De hecho Carmack va a utilizarlos en su próximo motor. Si podéis, descargaros los videos de la charla que dió en el QuakeCon de este año (tuvo que grabar la charla porque su hijo nació recientemente y no pudo asistir al evento). Además, de esta forma se pueden conseguir soft-shadows más fácilmente y de esa forma también evitar el aliasing típico de los shadow maps de baja resolución.

Por otra parte aquí tienes una discusión en Beyond3D en la que se discuten las diferentes técnicas que se utilizan actualmente para las sombras. Cuáles son sus ventajas e inconvenientes.

Y en este thread de flipcode tenéis a Nick (el programador de swShader) con el problema del shadow popping. :)

Bueno, eso es todo por ahora.

Buen trabajo.

 Bien, lo que yo he notado (soy malo):
Cuando todos los billboards estan en la pantalla y miras al centro de la explocion haciendo que el volumen la superficie visible , el FrameRate disminuye al 10%. Creo no tiene arreglo, pero agregale un 9.8 m/ss mas un viento cosenico a los billboards y veras el efecto. :P
Sobre las sombras, cuando una sombra choca contra un volumen desaparece, sabias eso, pareciera que lo que haces es dibujar toda la escena y oscurecer con un teselado bidimencional o algo así, este es un problema grave, pues aun los no programadores notan algo raro rapidamente  :angry: .
Por el resto, el selfshading del enano safa bastante bien  (ole) .
Por cierto no me anda en ventana ni en 16 bits, no se por que. :blink:

Edit : sera la GForce 2 MX ?
Edit: 100  mensajes en 2 años.

 Hay mas:
Las olas al mirarlas paralelamente se sobre-zolapan, 2 o 3 veces.

Solucion:
Render all que no es agua.
Render agua, ordenando las caras de cerca a lejos (usando el zbuffer porsupuesto).
Con el teselado que usa esto es facil

Te iba a poner una imagen pero en la foto de arriba se ven claramente.

 En efecto, cuando la cámara se encuentra dentro del volumen de sombra debería utilizar el Carmack's reverse, pero aún no he implementado la rutina para comprobar que la cámara se encuentra dentro  :rolleyes: . Es algo que sí tengo que hacer pronto. De todos modos para ser mi primera prueba con los shadow volumes tampoco me ha quedado mal del todo, y realmente me ha resultado sencillísimo, mucho más de lo que creía en principio. Si lo llego a saber lo hago antes, me ha bastado mirar el ejemplo del sdk y un par de artículos para meterlo en el motor.

El shadow popping... pues creo que poco puedo hacer. Tesselar el modelo quizá?

Gracias por los enlaces Berserker por cierto.

Pogacha : efectivamente lo del agua es porque los polys los dibujo sin orden ni concierto, es una malla .X y no ordeno los polys de lejano a cercano. El agua la quiero crear dinámicamente, así que ya me encargaré de ello más adelante.

En lo de la sombra que comentas es un problema que también había notado y quiero solucionar, cuando choque contra algún objeto debería de quedarse ahí, y no traspasarlo como ahora, que es por lo que se ven los "finales" del volumen rodando por la escena. Habría que detectar colisiones y aún no las tengo implementadas (mucho me queda por hacer todavía).

Sobre los billboards yo no noto caida del framerate, o no te he entendido bien, no se. Alguien lo nota?


Por comentar más cosas del motor, he de decir que todo está renderizado "a pelo". Es decir, o bien utilizo un vertexbuffer por objeto, o directamente mando un DrawPrimitiveUP (para los billboards por ejemplo) por cada objeto (en este caso por cada billboard).
Vamos, que cuando esté todo un poco más ordenado debería ir bastante más rápido.

Por cierto, os va a una velocidad constante? El movimiento debería ser independiente del ordenador.

Venga gracias por las pruebas!  (ole)  

 Lo del agua, para evitar tener que ordenar, utilizar additive blending te daría el efecto deseado sin importar el orden de los polígonos. Luego haz lo que te ha dicho Pogacha, primero renderizas los polígonos sólidos, desactivas el zwrite (no se te olvide esto) y finalmente renderizas las superficies con additive blending (agua, partículas, etc).

Saludos.

 A mi me va genial. Y el efecto está muy bien. Salvo los errores que te han dicho, está muy bien!! (ole)  

 

CitarPogacha : efectivamente lo del agua es porque los polys los dibujo sin orden ni concierto, es una malla .X y no ordeno los polys de lejano a cercano. El agua la quiero crear dinámicamente, así que ya me encargaré de ello más adelante.

Todo lo no transparente o en definitiva que no depende de lo que hay atras ¡debe!, repito, ¡debe! ser dibujado de adelante para atras, o sea de cercano a lejano (obviamente si el sistema te permite ordenarlo facilmente (8trees o bsps), sino estas en problemas). Esto ayuda a que un pixel se dibuje la menor cantidad de veces gracias al z-buffer (mas util aun cuando usas perpixel-lighting).

Todo lo que depende de lo de atras, debe ser dibujado de atras para adelante, por que depende de lo que esta atras!!!

Pero en este caso para el agua no quiero sobresolapamiento, por eso dibujo de cerca a lejos, el z-buffer se va a encargar de deszolapar las olas. Pero tambien depende del paisaje de atras, por ende dibujo todo y al final dibujo el agua, los billboard no importaria el orden si usan alpha channel como deberian.

De todos modos el motor esta bien, segun las modificaciones que piensas agregarle.
Saludos.

 Eyyyyyyyyyyyyyyyyy! Pues nada, quiero hacer más pruebas antes de acabar la primera versión del motorcillo, así que os pongo otro enlace, esta vez del "SDK"  :huh: del motor.

Incluye las cabeceras, la librería, la dll, un ejemplito a modo de mini-tutorial básico, la documentación casi acabada, y seguramente un porrón de errores.

Por si queréis trastear con él : NaraEngine

Faltan muchas cosas básicas como renderizado de texto por ejemplo, pero bueno, poco a poco.  :rolleyes: