Proyecto iL-engine

[arkangel2803]

Holas

Bueno, no es que asegure la sincronicidad con el frame, sino que la 'pregunta' de cuantos pixeles se han contado no es inmediata, y tarda un poco en responder, igualmente encontre en internet que si vas creando 'preguntas', una por submesh, y despues de hacer todas las preguntas, miras su resultado, el tiempo que necesita por pregunta ya ha pasado y no te tienes que esperar.

Igualmente, ese 'efecto' de que ahora SI ahora NO, a mi me sucedia debido a la resolucion tan baja a la que se renderizan los objetos de oclusion, 320x240 en mi caso. Pero igualmente, me ha dado mas alegrias esta tecnica que disgustos hasta la fecha :).

Lo de los Kd-trees ya lo mirare, concretamente no los conocia, buscare infor por inet, thx :P

LLORENS

[Ruben]

Hi,
para la gente que quiera saber algo mas de las occlusion queries:

Capitulo del gpu gems explicando que es, para que sirven y como usar las occlusion queries:
http://http.developer.nvidia.com/GPUGems/gpugems_ch29.html

Capitulo del gpu gems2 explicando el uso de occlusion queries con una representacion jerarquica de la escena:
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter06.html

Aqui el paper en el que esta basado el anterior:
http://www.cg.tuwien.ac.at/research/vr/chcull/bittner-eg04-chcull.pdf

Charla del Gamefest 2008: revision de sistemas de oclusion:
http://www.microsoft.com/downloadS/details.aspx?FamilyID=b9b33c7d-5cfe-4893-a877-5f0880322aa0&displaylang=en

Un saludo,
Ruben

[Hans]

Un curro acojonante. España es como es pero si fuera el encargado de una empresa te haría ofertas a la de ya ;)

[Prompt]

En los GPU Gems te dicen que no se asegura que cada frame esten disponibles las consultas. Si no están disponibles te dirá que si se ven por defecto. Es que esa tecnica no se puede asegurar su sincronicidad. En mi opinion no se debería usar.

Motores graficos modernos utilizan tecnicas de culling en CPU para asegurar la sincronicidad con cada process, así puedes generar un frame en la CPU sabiendo exactamente lo que se ve y lo que no.

Yo ya experimenté en su día, leí mucho y descarté hacer queries a la GPU. Es cuestion de analizarlo, es util en solo determinados casos.

Un saludo.

(que de tiempo sin un hilo tecnico xD, voy a tener que meter más cizaña)

[XÑA]

Yo sí utilizo Querys y no tengo esos problemas. Sí es cierto que hay un parámetro que ahora no recuerdo que no funciona en según que casos, pero si esperas a leer el resulado de la query siempre me ha devuelto el valor.

Lo único malo de las Querys es el famoso tiempo de espera y lo del frame coherency. Lo que sí me fijé es que renderizando a menor resolución no ganaba absolutamente nada.

[arkangel2803]

Holas

Concretamente yo en el engine lo hago de la forma cutre, es decir, hago la query, y espero activamente hasta que el resultado esta disponible. Incluso con esto, el resultado es francamente bueno porque el tiempo de espera compensa la cantidad de pixeles que descartas.

Luego, mas adelante, ( porque siempre las best-practices las aprendes despues del curro que te has pegado :D) lei una manera en la que te podias aprobechar un poco de esa supuesta espera. Y era de la siguiente forma:

- Haces un vector de querys
- Por cada query
-- Haces la pregunta sin recuperar el valor respuesta
- Fin de este bucle
- Por cada query
-- Consultas el valor respuesta
-- Pones o no la submesh en la cola de render
- Fin de este bucle

De esta manera, mientras la query se esta gestando, haces otra ( porque creo que se debe poder hacer ) y asi por lo menos ganas un pelin de tiempo.

Un saludo

LLORENS

[Prompt]

Hombre... parar el motor o hacer otro bucle para tener que esperar queries...

Si lo piensas bien, que pasa si tienes una escena compleja? te mueres esperando hasta que la query esté disponible? los FPS se van un poco al traste.

Estoy de acuerdo en "darle tiempo a la query". Es una buena idea, pero no haciendo todas las preguntas y luego otro bucle acto seguido. Se me ocurre lo siguiente, yo más bien aprobecharía un buffer de frames, imaginaos ir siempre 1 frame por detrás. Es decir:

FRAME 1
- Procesas la escena.
- Esperas hasta que todas las querys esten disponibles.
- Renderizas el frame.
- Lo guardas en un FBO.
- Aplicas los filtros de post-proceso pertinentes.
- Guardas este FBO con la aplicacion de los filtros. (fbo_frame1)
- NO RENDERIZAS NADA.

FRAME 2
- Procesas la escena.
- Esperas hasta que todas las querys esten disponibles.
- Renderizas el frame.
- Lo guardas en un FBO.
- Aplicas los filtros de post-proceso pertinentes.
- Guardas este FBO con la aplicacion de los filtros. (fbo_frame2)
- RENDERIZAS fbo_frame << actual - 1

Esto incluso nos sirve para disponer del frame anterior para hacer filtros complejos.

Es algo así como hacer triple buffering. El doble buffering es lo que normalmente hacemos, calculamos renderizamos un frame (swapbuffer) y mientras renderizamos otro y así.

Triple buffering by Prompt.

[tamat]

ta chulo, se nota que hay mucho curro ahí. a ver si consiguen encauzarlo bien, seguro que salen cosas chulas. cómo gestionas la construccion de las escenas?

/trollmode: por cierto, vaya pajas mentales te metes con el glow y el emisivo, tio, que solo es pintar en otro buffer, blurrear y sumar, hay otras cosas mas interesantes de las que podrias hablar que estan ahi y te emperras en repetir algo trivial. yo me he quedado con ganas de saber como gestionas las sombras, o como gestionas el pipeline de render.

un saludo

[arkangel2803]

Holas

La construccion de las escenas se hace a partir del 3D Studio Max, como no tenia ni idea de hacer scripts en max y tenia un parser antiguo de *.ASE, me hice un exportador de escenas ASE a mi motor, este exportador me aseguraba que cada objeto (representado por 3 mallas) en el 3D Studio Max daba como resultado un objeto para el motor 3D.

Las tres mallas son las siguientes:

1.- Malla normal, con el set de texturas que el diseñador necesite para texturar
2.- Malla lightmap, con un set de texturas unico para cada vertice. Usado para los lightmaps de la escena
3.- Malla occlusion, con muy pocos poligonos para el test de occlusion.

Por lo demas, los objetos son pintados pasando primero un test de frustrum y luego un test de occlusion, (o alguna combinacion algo mas extraña que se me ocurriera por aquellos dias que no me acuerdo bien bien :) )

Igualmente, ahora necesito pensar en como integro alguna estructura de tipo octree / kdtree con todas las demas.

Las sombras son las tipicas shadowmap pero en vez de ser un solo shadowmap, son 6, uno por cada cara del cubemap que tiene la omni. El proceso de descarte de geometria en esta demo y en esta luz esta trucado, pus utiliza las mismas submallas que el frustrum resultante de la camara. Pensad de que la omni nunca sale del campo de vision de la camara, por lo tanto, no puede haber objetos 'fuera' de la camara que hagan sombras dentro de la camara.

El shader de las sombras es relativamente sencillo, creo que solo tiene 1 o 2 linias de codigo.

El pipeline, es algo que con el tiempo he visto que tengo que mejorar reubicando procesos, en principio no utilizo multi render target y todo se hace secuancialmente y como dices en tu utimo post, se hacen los renders de la geometria principal, selfilumination, bright, fusion bright+self, geometria principal + bright + self, etc..

Por lo demas si quereis ya posteare la memoria del proyecto donde podeis ver diagramas y tal de como se realizan los procesos.

Un saludo

LLORENS

P.D: Por cierto, ya que estamos, alguien me podria explicar asi en pocas palabras, como interactuan un KD-Tree y una Camara para poder dar como resultado una lista de submeshes para pintar ?? porque lo que he visto hasta ahora es que los kd-trees almacenan puntos de una forma peculiar, pero como esos puntos con la camara pueden dar el resultado esperado ?

[Loover]

Impresionante este engine. ¡Qué buen curro!

[matriax]

Estaria bien que hicieras un "minijuego" utilizando tu engine y donde mostraras todo lo que se puede hacer y compartir el codigo fuente para que la gente trasteara con el y viera hasta donde se puede llegar o que puede ofrecer a la hora de hacer videojuegos,etc...

[arkangel2803]

Holas

Ya te lo digo yo, se puede hacer poco ahora mismo :D, porque como has dicho tu, sirve mas para trastear y probar cosas que como engine profesional. Es mas, mi intencion es la de aprender, (siempre tirando en direccion a los engines profesionales ) pero teniendo en cuenta de que es mucho curro y que mas vale el conocimiento de como van las cosas  que no el que se pueda hacer con el :)

Un saludo

LLORENS

[XÑA]

Sobre lo comentado de las Querys, yo hago lo siguiente:

Renderizo la Z
Renderizo la Z de nuevo haciendo querys
Empiezo a pintar el mesh y miro la query. (Esto me da algo de paralelismo)

Lo del frame coherency está bien, siempre que 'asumas' cierto nivel de error, pq hay cosas que se verán en este frame que no se ven en el anterior.

De todas formas, yo necesito estar seguro de que el objeto no se ve, pq construyo dinámicamente el shader en virtud de las luces que afectan a este mesh.

[arkangel2803]

Sobre lo comentado de las Querys, yo hago lo siguiente:

Renderizo la Z
Renderizo la Z de nuevo haciendo querys
Empiezo a pintar el mesh y miro la query. (Esto me da algo de paralelismo)

Lo del frame coherency está bien, siempre que 'asumas' cierto nivel de error, pq hay cosas que se verán en este frame que no se ven en el anterior.

De todas formas, yo necesito estar seguro de que el objeto no se ve, pq construyo dinámicamente el shader en virtud de las luces que afectan a este mesh.

A que te refieres con 'dimaicamente' ?? Compilas el shader el tiempo real ??

Un saludo

LLORENS

[[EX3]]

En el JadEngine tengo entendido que tambien hacen lo mismo, van construyendo el shader de la escena segun opciones y caracteristicas de la escena mientras esta se va generando y por lo que me contaron, si se hace bien parece no tener un coste muy alto en cuanto a rendimiento.

Salu2...