Hola
Soy nuevo por aqui y me gustaria empezar mostrando un video de mi proyecto final de carrera. Me gustaria saber vuestra opinion de que os parece.
El video es de un engine fruto del estudio y desarrollo de ecuaciones de iluminacion asi como otras estructuras de gestion interna de engine's 3D.
Para mas comodidad, todo el video esta comentado en espeañol para poder facilitar la informacion de las zonas.
Un saludo y gracias por el visionado, se aceptan criticas buenas y malas ;)
Video: Proyecto iL-engine (http://www.vimeo.com/1768191/)
LLORENS
Joder muy bueno, tanto los ejemplos en 3d como los comentarios estan muy bien. Lo mejor el efecto de Glow en la iglesia y la iluminacion en el tunel dando calor o frio.
Holas
El glow se consigue mediante texturas de self-ilumination juntamente con el brillo por pixel como se puede ver en los controles.
La niebla es algo que se me ocurrio viendo un video del editor del Crysis, y es hacer la niebla mediante 2 colores y no solo uno, defines el color cercano, y color lejano de la niebla y da un resultado que me ha gustado mucho.
Un saludo
LLORENS
Impresionante 8o. Mis felicitaciones.
Un Saludo
Esta genial el video. Algo que considero jodido de verdad en el desarrollo de un motor 3D es la iluminacion, por ello le veo mucho merito y curro al asunto. Enhorabuena :)
Salu2...
Excelente trabajo.
¿Tienes alguna web con más detalles sobre el motor?
¿En que lenguaje está programado?
Esa vidriera voronoi blenderita :D
Me ha gustado el vídeo, quizá como presentación necesitaría una mejora en la grabación de la voz y en su volumen con respecto a la música en algunas partes, pero está compensado por lo amena y visual que es.
Muy buena pinta, pero ¿podrías explicar algo más en qué ha consistido tu trabajo? Es que no entiendo bien si has hecho tu propio motor render, si te apoyas en DX u OGL, o qué...
Holas
Por partes :)
- El lenguaje utilizado ha sido C++ y DirectX 9.0c (con pixel shader 3.0).
- La finalidad del proyecto era hacer un engine que no se apoyara encima de otras librerias que no sean las de DirectX (utilizo DXUT por que me facilita el tema de la interfaz grafica para interactuar con la demo). En este engine he profundizado en las ecuaciones de iluminacion sobre todo y tambien en la gestion interna de todas las estructuras y objetos de memoria que necesitaba para hacer funcionar el engine 3D.
- El codigo del engine esta hecho por mi.
- El modelado de la demo esta hecho por mi, a escepcion del modelo de jugador del UT2004, que es de ese juego.
- Las texturas estan sacadas de Half-Life 2, Doom 3 y Quake 4.
Y si, lo del sonido es verdad, pero no tenia mejor equipo porque si vierais mi micro.... ^_^' igualmente en la proxima demo espero que sea mejor el sonido.
Con respuesta a si tengo web o demas, no, de momento no tengo nada, solo le video para mostrar, cuando entregue el proyecto, pondre para que se pueda descargar la demo ( codigo entero con cpp's y shaders ) porque ya estoy empezando la segunda version con nuevas ideas.
Espero haber respondido a todas las preguntas, si teneis mas estare encantado de responderlas.
Un saludo
LLORENS
Felicitaciones, se aprecia una cantidad de trabajo enorme y que decir del acabado, simplemente fabuloso.
¿Con que equipo lo ejecutaste?
¿Lo planeas liberar en algún momento?
Holas
El equipo es un pelin potente, porque tiene un Core duo 2600 o alguno similar, una Nvidia 8800 GTX de 700 y pico megas de memoria y 2Gb de memoria ram.
Aunque todo hay que decirlo, el equipo es potente, pero mis años de experiencia en modelado MAX se han basado en su totalida en experiencia para modelar en Low-Poly, la demo me corria entre unos 120 y 300 frames.
A mitad del desarrollo de la demo me di cuenta de que podia exprimir mas las escenas en cuanto a carga poligonal pero tube que poner freno a las idas de olla porque sino no acababa nunca ;)
Si, pondre el codigo para descarga una vez lo presente en la universidad, que sera en unas semanas, aunque no se si ya he comentado que ya estoy con una nueva version con nuevsa ideas.
Un saludo a todos
LLORENS
Como ya te he dicho. El trabajo es simplemente impresionante. Además, es algo estupendo que decidas compartirlo.
Si quieres trabajar en la ind. algo como lo que has hecho debería ser suficiente para llamar la atención. Así que hazte un blog, aunque sea de esos gratis en Blogger, y publica el motor. Puede que te caiga alguna oferta de trabajo interesante. Además, en Barcelona hay ahora mismo muy buenos estudios que están haciendo proyectos cojonudos.
Hola a todos!
Arkangel2803 mis felicitaciones, un magnifico comienzo.
Aqui podemos ver evidentemente mucho curro. Se ha usado un ordenador bastante potente que aún puedes exprimir mucho más. No se que optimizaciones típicas de renderización habrás usado o cuando "fixed pipeline". Imagino que no muchas porque aún estás en los comienzos. Por lo tanto seguro que te vemos por aqui pronto contandonos nuevas caracteristicas del motor.
Un saludo! arkangel2803 no dejes el motorcillo aparcao eh! (como hacen muchos) xD que has empezado bien :), ánimo!
Holas
Bueno, te puedo comentar que de fixed pipeline no utilizo apenas nada. Concretamente para lo que uso la fixed-pipeline es para dibujar las linias que vemos en pantalla en algunos momentos (normales de los vertices, tangentes de estos, bounding boxes) y eso es asi porque no se aun hacerlas pasar por el programable pipeline ^_^'
Respecto a optimizaciones, utilizo frustrum culling en la camara, y occlusion culling de geometria. En un futuro tendria que añadir algun tipo de optimizacion de Octree para la escena, es decir, para que cuando mire si una submalla esta dentro del rango de vision de la camara o no, no me patee todas las submallas del mundo, sino las que estan por delante de la camara.
Tambien lo interesante seria hacer 6 threads diferentes y paralelos para poder hacer lo mismo que comento en el parrafo anterior pero cuando estoy haciendo los shadow map desde la luz omni, ya que las sombras de la luz omni necesitan un cubemap ( 6 caras ) para poder calcularse, y tengo que hacer evidentemente 6 frustrum cullings uno por cada cara.
Y seguramente mas optimizaciones que me faltan por ver y algunas otras que ya estoy implementando en una nueva version.
Un saludo
LLORENS
Bien.
Espero que tu occlusion culling no sea el que da D3D o OGL. Ya que este no asegura la sincronicidad con el frame, a veces te responderá que algo se ve y otras no. Tenlo en cuenta.
Sobre los octrees yo personalmente tengo que rescatar, más bien usar kd-tree, miratelos creo que es lo mejor. Puedes usarlo a la vez del octree, como filtro previo para los sub-meshes.
Un saludo.
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
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 (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 (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 (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 (http://www.microsoft.com/downloadS/details.aspx?FamilyID=b9b33c7d-5cfe-4893-a877-5f0880322aa0&displaylang=en)
Un saludo,
Ruben
Un curro acojonante. España es como es pero si fuera el encargado de una empresa te haría ofertas a la de ya ;)
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)
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.
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
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.
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
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 ?
Impresionante este engine. ¡Qué buen curro!
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...
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
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.
Cita de: XÑA en 29 de Septiembre de 2008, 09:56:02 AM
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
En el JadEngine (http://forums.stratos-ad.com/index.php?board=38.0) 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...
Cita de: arkangel2803 en 29 de Septiembre de 2008, 10:50:21 AM
Cita de: XÑA en 29 de Septiembre de 2008, 09:56:02 AM
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
Sería una locura, se referirá que le pasa un parametro de numero de luces o con una estructura por cada luz. O si acaso, compilan varios shaders con configuraciones diferentes de n luces y aplican "dinamicamente" una y otra según cuantas luces le de al objeto.
Vamos a darle más caña tecnica a esto.
Un 38% más de rendimiento con Occlussion Maps + Oclussion Query (una especie de filtrado antes de ni si quiera preguntar si se ve o no)
http://w210.ub.uni-tuebingen.de/volltexte/2005/1548/pdf/TR_WSI_2004_6.pdf
Es un interesante articulo. Como siempre estoy seguro que esos Oclusion Maps podrian usarse para otras cosillas... :)
Un saludo.
Cita de: Prompt en 29 de Septiembre de 2008, 12:48:04 PM
Cita de: arkangel2803 en 29 de Septiembre de 2008, 10:50:21 AM
Cita de: XÑA en 29 de Septiembre de 2008, 09:56:02 AM
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
Sería una locura, se referirá que le pasa un parametro de numero de luces o con una estructura por cada luz. O si acaso, compilan varios shaders con configuraciones diferentes de n luces y aplican "dinamicamente" una y otra según cuantas luces le de al objeto.
Si, entonces es mas o menos como lo hago yo, aunque en el engine actual solo tengo un mega-shader, en el siguiente quiero implementar una especie de multiples shaders que se activaran segun una signatura de shader generada por el material del objeto e informacion de la escena.
Por cierto, alguien me podria explicar lo que pregunte de los KD-trees ?? como conviven los KD-trees con las sub-meshes y la camara ??
Thx
LLORENS
Si genero el shader dinámicamente y después compilo. Si el shader ya existe, no vuelvo a compilarlo.
Cita de: XÑA en 30 de Septiembre de 2008, 10:36:41 AM
Si genero el shader dinámicamente y después compilo. Si el shader ya existe, no vuelvo a compilarlo.
Así te ahorras tener un único shader e ir objeto por objeto "subiendo" a la tarjeta los valores uniform, is'n it?
Leí hace mucho tiempo un paper de nVidia donde decía AVOID UNIQUE SHADER. Lo que yo plantee en mi motor al principio, da mucha más libertad pero cláro... donde está el límite de shaders? :) memoria, ids... no se hasta que punto es contra producente. Evidentemente imagino que se refería a que no usará 400 veces el mismo shader subienod los uniforms, eso se come el BUS.
Cita de: arkangel2803 en 29 de Septiembre de 2008, 02:36:56 PM
Si, entonces es mas o menos como lo hago yo, aunque en el engine actual solo tengo un mega-shader, en el siguiente quiero implementar una especie de multiples shaders que se activaran segun una signatura de shader generada por el material del objeto e informacion de la escena.
Por cierto, alguien me podria explicar lo que pregunte de los KD-trees ?? como conviven los KD-trees con las sub-meshes y la camara ??
Thx
LLORENS
http://en.wikipedia.org/wiki/Kd-tree
http://donar.umiacs.umd.edu/quadtree/points/kdtree.html
Imaginatelo como un simple filtrado previo. Es como un grafo de escena.
- Procesas todos los objetos
- Generas el kd-tree
- Calculas el frustum de la camara
- Obtienes todos los puntos (objetos etc...) que están dentro de ese frustum
- Ejecutas las consultas de oclusion (o las calculas en CPU en este instante)
- Pintas lo restante
Un saludo.
Cita de: Prompt en 01 de Octubre de 2008, 10:25:49 AM
Cita de: arkangel2803 en 29 de Septiembre de 2008, 02:36:56 PM
Si, entonces es mas o menos como lo hago yo, aunque en el engine actual solo tengo un mega-shader, en el siguiente quiero implementar una especie de multiples shaders que se activaran segun una signatura de shader generada por el material del objeto e informacion de la escena.
Por cierto, alguien me podria explicar lo que pregunte de los KD-trees ?? como conviven los KD-trees con las sub-meshes y la camara ??
Thx
LLORENS
http://en.wikipedia.org/wiki/Kd-tree
http://donar.umiacs.umd.edu/quadtree/points/kdtree.html
Imaginatelo como un simple filtrado previo. Es como un grafo de escena.
- Procesas todos los objetos
- Generas el kd-tree
- Calculas el frustum de la camara
- Obtienes todos los puntos (objetos etc...) que están dentro de ese frustum
- Ejecutas las consultas de oclusion (o las calculas en CPU en este instante)
- Pintas lo restante
Un saludo.
Holas
Lo que no acabo de ver claro es 'que informacion' se pone dentro del KD-tree, es decir, yo tengo un objeto X en mi mundo en una posicion (x,y,z). El KD-tree solo almacena puntos, por lo tanto, tengo que poner en el kd-tree el centro de la BBox del objeto ? o es otra idea ?
Y la otra pregunta magica es: Teniendo un frustrum de una camara, como consigues los puntos que estan en el interior de este mediante un kd-tree ?
En principio esos links los he visto y probado, pero tengo dudas de como funcionan las estructuras entre si.
Un saludo
LLORENS
Hola
Informaros de que he abierto un blog para centralizar un poco toda la informacion.
http://ilengine.wordpress.com/ (http://ilengine.wordpress.com/)
Un saludo
LLORENS
Nosé si lo habrás hecho, pero te recomiendo que suscribas el blog al planet stratos: http://www.inmensia.com/planet/stratos-ad/
Holas
Permiteme que te muestre mi gran ignorancia pero.. que es eso ? ???
Muchas gracias por la info
LLORENS
CitarLa primera regla del Planet Stratos es no preguntar qué es el Planet Stratos.
>:D
Hablando en serio, la wikipedia te contesta: http://es.wikipedia.org/wiki/Planeta_(agregador) (http://es.wikipedia.org/wiki/Planeta_(agregador))
Y te voy a añadir inmediatamente al Planet Stratofftopic ( http://forums.stratos-ad.com/index.php?topic=11277.0 ), si no tienes objeción. arkangel2803, estás stratofftopicado :P
Holas
A ver si me he enterado, estos 'planetas' son como una biblioteca de blogs, pero, cuando yo escribo un post en mi blog, este se ve desde los planetas porque tienen algun sistema rollo RSS o simplemente esta mi link en el planeta como si de una web normal se tratara ?
Por cierto, muchas gracias tewe76 y yEnS por avisarme de esto de los planetas ::)
Un saludo
LLORENS
Yo no me he leído el link de la wiki, pero por mi forma de usarlo/verlo utilizo el planetstratos para tener agregado el RSS del mismo y así estar suscrito con un único RSS a todas las updates de los distintos blogs suscritos.
Si yo actualizo mi blog, todos se enteran atraves del RSS del planet, si tu actualizas, todos nos enteramos, etc, etc...
Y además en este caso, la temática del Planet Stratos es (teóricamente y a menudo) sobre desarrollo de videojuegos o similares.
Cita de: tewe76 en 07 de Octubre de 2008, 05:37:12 PM
CitarLa primera regla del Planet Stratos es no preguntar qué es el Planet Stratos.
>:D
Hablando en serio, la wikipedia te contesta: http://es.wikipedia.org/wiki/Planeta_(agregador) (http://es.wikipedia.org/wiki/Planeta_(agregador))
Y te voy a añadir inmediatamente al Planet Stratofftopic ( http://forums.stratos-ad.com/index.php?topic=11277.0 ), si no tienes objeción. arkangel2803, estás stratofftopicado :P
tewe! yo te maldigo, a mi me dices que mande un sucio mail, a una direccion que rechaza mails, y a el lo añades, ACTUALIZA MI BLOG !!!
¬¬ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* TEWE
... www.alvaromartin.net
Prompt, vuelves a confundirme --
Yo soy el del Planet Stratofftopic y tengo puesto tu blog desde el principio ( http://www.estupendamente.com/PlanetStratofftopic/category/prompt-alvaro-j-martin-lopez-prompt-_/ ). Además, mi email no rechaza a nadie, que lo tengo bien educado :)
No lo confundas con el Planet Stratos, que ese no lo llevo yo... ::)
Ya veo que lo que vas a hacer es crear el shader dinámicamente ;) Bienvenido al club!!! Yo probé con multipass o ahora que estoy con 1 shader para todas las luces. Sin embargo no creo que te sirve el sistema XML para identificarlos. La primera versión con multipass usaba un sistema parecido al tuyo, pero el problema es que lo que haces es tener un sistema de materiales muy genérico, pero a la vez limitado. Por ejemplo, si quieres tener un material que haga un efecto 'Ghost' utilizando Fresnel, tendrás que crear ese 'efecto' en tu definición de materiales.
Todo esto lo superé con la versión actual, donde:
No necesito hacer multipass ( creo que el límite son 8 luces debido a los samplers necesarios para las sombras)
No necesito hacer multipass para cada layer de material, porque puedo procesar en el mismo shader estas características.
Puedo hacer transparencias ( aunque controladas) porque no necesito activar el Blending One-One.
Los materiales son 'clases' con métodos virtuales que son los que generan el shader.
Problema de todo esto: lento!! ¿Porqué? Pues porque hay muchos shaders que se tienen que ir activando con cada mesh, y eso no le gusta a la tarjeta. Supongo que con DX11 y el multithreading esto se resolverá, porque creo que lo que pasa es que le cuesta mucho hacer las comprobaciones que hace o las listas de instrucciones que tiene que crear ( aunque es un suponer).
aiiiiiiiins! es verdad, gracias y disculpeme señor tewe... la empanada de antes de desayunar!
xD hahahaa :)
Cita de: XÑA en 08 de Octubre de 2008, 09:38:03 AM
Ya veo que lo que vas a hacer es crear el shader dinámicamente ;) Bienvenido al club!!! Yo probé con multipass o ahora que estoy con 1 shader para todas las luces. Sin embargo no creo que te sirve el sistema XML para identificarlos. La primera versión con multipass usaba un sistema parecido al tuyo, pero el problema es que lo que haces es tener un sistema de materiales muy genérico, pero a la vez limitado. Por ejemplo, si quieres tener un material que haga un efecto 'Ghost' utilizando Fresnel, tendrás que crear ese 'efecto' en tu definición de materiales.
Todo esto lo superé con la versión actual, donde:
No necesito hacer multipass ( creo que el límite son 8 luces debido a los samplers necesarios para las sombras)
No necesito hacer multipass para cada layer de material, porque puedo procesar en el mismo shader estas características.
Puedo hacer transparencias ( aunque controladas) porque no necesito activar el Blending One-One.
Los materiales son 'clases' con métodos virtuales que son los que generan el shader.
Problema de todo esto: lento!! ¿Porqué? Pues porque hay muchos shaders que se tienen que ir activando con cada mesh, y eso no le gusta a la tarjeta. Supongo que con DX11 y el multithreading esto se resolverá, porque creo que lo que pasa es que le cuesta mucho hacer las comprobaciones que hace o las listas de instrucciones que tiene que crear ( aunque es un suponer).
Holas
La intencion es ir evolucionando el sistema de materiales para que cada vez sea mas generico y se puedan hacer mas materiales con un xml predefinido como el que tengo.
Concretamente ahora tengo tres tipos de xml, normal, particle, water. (aun son ideas) Pero con estos 3 tengo suficiente para hacerlo casi casi todo, posiblemente integre particle en normal, aunque aun no lo se porque las particles necesitaran tener una texture3D y un material normal no, ya veremos a ver como va.
Independientemenete, descubri que DirectX se le puede pasar el codigo de una funcion sola de shader y te la compila, y luego la puedes linkar con otra funcion compilada previamente con el fragment linker, ke va a ser la clave para esto que quiero hacer.
Un saludo :)
LLORENS
Esto del fragment linking es lentísimo. Yo lo probé y vaya porquería!!! Ya hace años de esto así que a lo mejor lo han mejorado pero de todas formas ni ATI lo utilia. Hace cosas de 1 año o 2 que ya se dió cuenta de que lo mejor es crear su propio shader dinámicamente. No es dinámico 100%, pq utiliza predefiniciones, pero sigue esa lógica ;)
Cita de: arkangel2803 en 08 de Octubre de 2008, 11:00:58 AM
Concretamente ahora tengo tres tipos de xml, normal, particle, water. (aun son ideas) Pero con estos 3 tengo suficiente para hacerlo casi casi todo
¿Podrias hacer reflexion recursiva? ;)
Cita de: XÑA en 08 de Octubre de 2008, 01:03:10 PM
Esto del fragment linking es lentísimo. Yo lo probé y vaya porquería!!! Ya hace años de esto así que a lo mejor lo han mejorado pero de todas formas ni ATI lo utilia. Hace cosas de 1 año o 2 que ya se dió cuenta de que lo mejor es crear su propio shader dinámicamente. No es dinámico 100%, pq utiliza predefiniciones, pero sigue esa lógica ;)
Concretamente yo lo ke tengo pensado es:
-Cargamos modelo
-Cargamos material del modelo (imaginemos que solo tiene uno)
- SI el material ya esta cargado ENTONCES utilizamos el material cargado
- SINO generamos el codigo del vertex shader, generamos el codigo del pixel shader, los compilamos por separado, y los unimos con el Fragment Linker
- Ya tenemos todo cargado
- En bucle de programa ese shader esta siempre activo para ese material en concreto por lo que no necesitas volver a retocar nada.
Segun la documentacion de directx, la funcion de unir dos shaders es muy rapida y poco costosa. Otra cosa seria compilar los shaders para cada uno de los frames que vamos a renderizar.
@ Ruben: En principio el mapa de reflexion es un cubemap de baja resolucion, simplemente para dotar al objeto de 'reflexion' sin meter mucha zizaña en el tema de calidad. En principio no pretendo hacer ningun tipo de recursividad.
Un saludo
LLORENS
Aquí en el curro tambien usamos shaders dinamicos, es decir, tenemos un macroshader con mil defines y en función de las propiedades del objeto activamos unos o otros, ademas guardamos el map de los compilados previamente para poder reusar.
El sistema funciona, tal vez a veces puede dar un paron si tiene que recompilar el shader con una nueva configuración que no tenía antes pero se puede evitar forzando el compilado durante la fase de carga de la escena.
Algo parecido es lo que tiene ATI :P
Holas
Comentar de que hoy lunes he entregado el proyecto final de carrera y como tal, hago publico con efecto imediato el codigo de dicho proyecto.
Lo podreis encontrar en el blog: Proyecto iL-engine (http://ilengine.wordpress.com)
Un saludo y gracias por vuestras visitas. Por cierto, no os olvideis de consultar la ultima entrada del blog pues comento cosas a tener en cuenta como las librerias DXUT que de PC a PC pueden dar problemas de compilacion.
LLORENS
De nada! A ti por compartir el código y por los comentarios del blog, interesantes para iniciados y no iniciados ;)
Hola
Hace ya unos cuantos días que no actualizo el blog, y no es que lo tenga abandonado sino que no es el tipo de pagina web que yo quería para poder publicar conocimiento.
El tema está en que un blog es algo para leer día a día perdiendo de una manera simbólica el índice de las cosas que se han hecho y perdiendo el norte de todo lo que se ha publicado.
Por eso mismo, he decidido moverme hacia una página en forma de wiki para poder publicar allí todo lo que estaba publicando aquí y más de manera más ordenada y fácil de consultar.
Por lo tanto pido a todos aquellos que leíais la información que posteaba aquí que actualicéis vuestros links porque a partir de ahora pondré todo el conocimiento en la nueva wiki.
Nueva pagina: http://ilengine.wikidot.com (http://ilengine.wikidot.com)
Un saludo y gracias
Tienes razón en que un blog no es buena solución para lo que quieres. Pero lo malo de la wiki es que no tienen RSS (creo). Aunque sea un poco más de trabajo, quizás podrías usar las dos cosas: añades en la wiki un nuevo artículo y pones en el blog una entrada simplemente con un link a dicho artículo.
Es una idea.
arkangel por curiosidad eras de un foro donde estaban unos tales skual,hoplita,jugocas etc? el foro trataba sobre el wr :..
No, no creo que sea esa parsona porque no me suena ese foro que comentas :)
Un saludo
LLORENS
Impresionante!!! Me quito el sombrero 8o
Por cierto, la musica que suena de fondo cual es y de donde viene?
Muy bueno, lo único los chasquidos del micro que te joden vivo como lleves cascos :)