Que tal, soy Pogacha.
Estoy buscando articulos o ejemplos de algoritmos de VIS / PVS o creacion del set de visualizacion potencial en un arbol BSP, el mejor de los modelos que he realizado demoran 30 minutos en el start-map del quake 1, me trepane el cerebro leyendo el codigo de J. Carmack ( Quien deberia abandonar el c y usar c++, ¿verdad?) y no lo entiendo. Los papers que he leido no son practicos. Si alguien sabe de algun lugar con info o ejemplos o lo que sea les agradeceria.
NOTA:
Hago el BSP, el CGS, Regionalizacion, Portalizacion, y el vis me esta demorando.
Saludos y gracias.
El libro "Advanced 3-D Game Programming using DirectX 8.0"(o su reedición con las 9.0) dedica un capítulo en exclusiva a ese tema. La editorial es Wordware, y el autor Peter Walsh.
Papers sobre el tema hay unos cuantos... pero ahora mismo no recuerdo ninguno.
Y sobre el código de Carmack: sí, es un asco (asco) .. consulté el cargador de ficheros ini del Quake 3 y era ininteligible :ph34r: , además de estar metido en un .c junto a otras funciones.
PD: Antes de adquirir el libro puedes echarle un ojo usando el P2P ;)
Gracias.
Voy a ver el libro.
Si hay algo gratis por ahí mejor.
Saludos
Pogacha
Y si no apúntate a
este curso de GameInstitute. Ahí te enseñarán todo lo que tienes que saber sobre BSP/PVS.
Saludos.
Cita de: "Pogacha"Que tal, soy Pogacha.
Hola, Pogacha, yo soy Mars Attacks...
Y a buen entenedor, pocas cucharas bastan.
Bien, U$S 125 es el sueldo de un mes
Hola, tengo 2 tutoriales de los mismos autores del curso de GI. Por si a alguien le interesa lo tengo compartido en el burrito con el nombre bsp_tut.zip
(uoh) (genial) (uoh) (genial) (uoh) O_O (uoh) (uoh) (genial) (uoh)
El burrito es un metodo de: si no lo encuentras en Google, lo encuentras en el burro.
Un buen articulo ( una tesis de un tio , en realidad ) ;
http://www.flipcode.com/misc/SamuelRanta-E...la_BSPTrees.pdf No se si es lo que buscabas, pero es de lectura muy recomendada.
Salu2
londo2061
a mi el codigo del quake me parece facil de leer. Esta clarisimo que C es un lenaguje pesimo y que c++ le da mil vueltas, pero bueno XD. Si quereis ver algo elegante bajaros los fuentes (los que dejan) del unreal :)
En realidad la idea es entender el algoritmo general.
Cuando te pone:
Vector_Cross(Passage->u,Passage-> o,Passage->v)
Vector_Sub(Passage->u, Separators[j+1]
se sabe que hace u=(o x v) - Saparators[j+1];
Lo que no se sabe es para que es esto, no es solo la escritura engorrosa, sino que no esta comentado, usa variables llamadas x,f,t ... que no dicen nadas, y no son variables mudas.
De ultima entendí, mas o menos, como funciona, pero ya se me ocurrieron algoritmos mejores, algunos no los he implementado aun, asi que ese "mejores" queda entre comillas por ahora.
Tendria que ver ese codigo del unreal.
Pues mira casualmente
lo que he encontrado. Ve donde pone
SHERMAN'S DEGREE PROJECT ON BINARY SPACE PARTITIONING (BSP).
Saludos.
Citar
Un buen articulo ( una tesis de un tio , en realidad ) ;
http://www.flipcode.com/misc/SamuelRanta-E...la_BSPTrees.pdf
Es una recopilacion de otras tesis tambien, pero esta bastante completo, (creo que casi todo), a mi no me sirve pero veo que es muy util para quien se inicia en arboles BSP.
Lamentablemente el PVS es el mismo que usan con viewfrustrums, antipenumbra o separators como los llaman en ID Software, y aunque andan bien, son extremadamente lentos, principalemente en espacios abiertos.
Sobre SHERMAN'S DEGREE PROJECT ON BINARY SPACE PARTITIONING (BSP).
Tendre que leerlo, parece hecho bien básico como para que cualquiera lo entienda, me gustan esos dibujos :)
Haber que le saco.
Edit : Muchas gracias
Lei los articulos del Sherman Kong sobre su motor Sherman3d y es un engaña pichanga, nisiquiera se acerca al motor del doom1 aunque incluso usa dx 8.0 y bueno ..., un desastre.
Me lei todo y les juro, no vale la pena.
Citarson extremadamente lentos, principalemente en espacios abiertos.
Los BSP no son adecuados para exteriores por su propia naturaleza, no deberia extrañarte su lentitud. Un octree es óptimo, sería mucho más rápido para mapas grandes.
Creo que algunos motores han usado sistemas híbridos, como podria(no lo sé) ser el caso de Halo. En ese tipo de juego viene bien un octree para las zonas exteriores, con algunos nodos que a su vez estén basados en BSP y quizá tambien PVS (para las zonas interiores, cavernas, bases etc).
En realidad el arbol bsp es optimo para interiores, tanto como exteriores, en lo que es vencido terriblemente es en el LOD o MimMaped Terrain Generation y ese tipo de tecnicas que recurre a reducir la calidad de lo lejano, en el arbol bsp solo me queda usar patches y existe en un sistema que tiene LOD para los nodos y si estos estan lejanos los aplica, pero no lo he implementado, ya que no es practico en construcción por geometria solida (por ahora).
Pero me referia a espacios abiertos a tales como una gran sala, una fabrica o espacios donde halla mucho hueco por aquí y por allí con lo que queda un grafo fuertemente conexo y eso asesina esos metodos.
Estuve pensando optimisaciones, y recurro siempre a no usar un arbol BSP para la visibilidad sino a otra estructura que estoy ideando, la cual permitiria portal rendering en tiempo real, pero aun no me cierra completamente, ... puede que no ande O_O , que este mal conceptualmente.
Aparte de octtress para exteriores quizas es interesante pensar e portales , pero sin querer entrar en la tiopica discusion portales vs bsp que esta algo trillado creo.
Respecto nivel de detalle y bsp no entiendo por que , al menos para los objetos que pueblan un mundo ( onde se van montonazo de poligonos normalmente)sean incompatibles, pero bueno...
Salu2
CitarRespecto nivel de detalle y bsp no entiendo por que , al menos para los objetos que pueblan un mundo ( onde se van montonazo de poligonos normalmente)sean incompatibles, pero bueno...
Si, para los objetos que pueblan, es lo mismo aca y en la china, el problema son los objetos estaticos que forman el arbol BSP estos son creados por solidos, y no conozco (yo), algoritmos de reducción de detalles para objetos que no tienen grupos de difumados.
Imagina que los poligonos del arbol bsp si o si estos toman toda la pantalla, o sea que estos consumen la mitad del tiempo, y si el mapa es detallado de cerca, sera detallado de lejos sin un LOD.
La otra forma seria crear multiples mundo con diferentes niveles de detalles, y en cada nodo mide la distancia a la camara para determinar el LOD pero es problematico hacer coincidir los mapas de luz y ni te cuento el PVS, y el ¿decal que estaba aca a donde fue a parar? :(
Por eso se usan patches en objetos, ahi se puede hacer coincidir el mapa de luz y los decales, y para el vis no se consideran o se consideran planos, para la colision se agregan planos externos y chin pum! B) . Es medio grasa pero anda, en cambio en el LOD, todo esto aun que se pueda hacer va a parar a manos del artista quien no lo vera con buena cara o deberas hacer un cacho de codigo y limitaciones por aquí y por allá.
Sobre Portales como estructura de mundo no la conozco, O_O ..?. ?...? (de que me perdi?)
Me la cuentas, relatas o linkeas ?
Normalmente los objetos que pueblan un mundo que su visibilidad la basas en BSP solo usan su caja o esfera para ver en que hoja del arbol bsp esta contenido. Si la esfera contiene todos los modelos de los distintos niveles de detalle no deberias de tener problema.
LSI te metes con niverle de detalle en arquitectura del mundo ademas de los objetos ( que, segun mi opinion , no es muy necesario ), usar BSP y lightmaps, ademas de otros problemas inherentes ( estatico, mucha memoria, etc) me parece un poco una locura, habiendo otras tecnicas mejores, tanto por refinamiento de algoritmos ( portales ,etc ) como algoritmos algo mas de fuerza bruta ( octrees,etc)
Lo tecnica de portales si manejas PVS o sabes en que se basan de deberia de sonar. Ademas, juegos como descent, unreal ( este usa tecnicas mixtas si no recuerdo mal) o incluso blade usaban portales.
Algo de info tienes en el pdf que copmente ( creo ), y en flipcode creoq habia un tutorial ( nos e que tal era ).
A nivel conceptual mira
http://www.geocities.com/siliconvalley/215...51/portals.html ( los dibujitos estan muy claros)
Nada, espero haber servido de ayuda
Esta bien, es determinación de superficies por recursion de portales basados en frustrum, pero la estructura de mundo es "node based bsp", capaz tambien ando con un hojaldrado. O sea que en este momento se puede hacer en tiempo real. Que bueno!!!. Por supuesto!, si se hacen sombras en tiempo real !!!.
Gracis a todos.