Buenas a todos y a todas, después de buscar por internet y no encontrar acabé implementando un algoritmo para generar frustums a partir de portales pero existen una serie de bugs que no consigo hacer desaparecer.
Quizas exista un alma caritativa que sepa decirme la implementación de escuela de este algoritmo.
Un saludo y gracias a todos, todos.
Creo que lo que buscas es la interseccion de portales con el frustum para generar otro frustum, este tema viene ligeramente (pero de manera muy clara) explicado en el libro Core Techniques.
Un enlace que te puede ayudar
http://gamecode.tripod.com/tut/tut06.htm
¡Frustrum! Cómo me mola esa palabra :D Suena como a Frostis o al sistema "no frost", o a frustrarse. Podría pasar hasta como encantamiento de Harry Potter
Malfoy: - ¡Expeliarmus!
Potter: - ¡Frustrum!
La pastilla. Ñam.
En mi motor hago esto:
Tengo el frustrum de la camara y la region inicial.
Render_Sector(frustrum *f)
{
Para cada portal
{
Portal *p= f->Crear_Portal_Cortado_Con_Frustrum(portal);
if(p->Area!=0) // por decir algo, p->Vertices > 2 o ...
Render_Sector(p->Crear_Frustrum(f->Origen));
delete p;
}
}
En el libro Real Time Rendering también lo explican bastante bien.
Lo que tienes que hacer es proyectar tu frustum en pantalla, crear la bounding box 2D de la proyección, y utilizar estos puntos para crear el nuevo frustum. Es mucho más rápido que empezar a hacer cálculos en 3D.
VinCenT.
Nosotros probablemente utilicemos Querys. Permite que los portales sean de cualquier forma. Pero todavía no lo hemos implementado.
Sobre proyectar, mmmm..., no siempre quiero saber que es lo que ve el player unicamente.
CitarQuerys
No se lo que son, puedes introducirme en el tema? (con un link sobra)
Seran los oclusion querys?, intentas dibujar el portal y si se dibujan 0 pixel no entras?
Saludos
Exactamente, oclusion querys.
Las occlusion queries van bien, como has dicho, pq te permiten tener cualquier tipo de portal, pero tienen su punto flojo en que són más lentas, pues has de tirar cosas por el bus i dp recoger la info. A parte, si algún colega tiene por debajo de una GeForce3, pues no podrá ejecutar tu motor...
Eso si, són muy fáciles de implementar.
Taluego!
VinCenT.
Cierto, son lentas. Pero puedes dedicar ese tiempo a hacer otras cosas... ;)
jejeje cierto. Pos pa'lante y ya contaras como te ha ido... y en que gastas ese tiempo!!
Taluego!
VinCenT.
Yo no he podido ver el paralelismo, no hay forma!, mando a dibujar un triangulo intercalado con determinar la visibilidad de la proxima luz (por ejemplo) y no consiguo ningun aumento de la velocidad, será que si no usas el glFlush() el paralelismo se consigue automaticamente en opengl?
En un pentium 3 750 con escenas de 600 portales vivos (o sea visibles por la camara o las luces) utilizando el sistema de cortes de portales es mas rapido que teniendo grandes triangulos con muchos objetos por sector. Comprobado empiricamente!.
Saludos
Tal vez se podría hacer el clipping por hardware a través de los User Clipping Planes pero los veo poco flexibles en este caso, sobre todo teniendo en cuenta que (si no recuerdo mal) se consume una unidad de textura por clipping plane que se active, de forma que el número de aristas por portal estaría algo limitado. :)
Saludos.
Nosotros utilizamos esta lógica para renderizar:
Renderizamos con un pixel shader de ambiente para que la Z se asigne al valor que corresponda.
Para cada objeto
Para cada luz
Comprobamos si la query ha terminado y si ha terminado comprobamos si el nº de pixels es 0, con lo cual podemos dejar de procesar más luces para este objeto
Renderizamos lanzando una query(Sólo la 1ª vez)
Pues SIEMPRE es más rápido NO comprobar la query y CASI nunca llega a terminar ninguna Query.
Así que parece que las querys no son muy útiles. Sin embargo, te diré que nosotros no utilizamos muchos polígonos, abrá que ver con un nº mayor si le da tiempo. Seguimos trabajando en ello y te daremos más conclusiones cuando las tengamos.
No termino de entender ...
Cuantas querys se pueden mandar a la vez?
Muy buenas,
he estado repasando my rutina de portal rendering y resulta que estava programada horrorosamente.
Os recuerdo lo que hago: Mantengo como variable del clipper un rectángulo que es la caja contenedora en 2D del ultimo portal por el que ha pasado. Así, la rutina de recalcular el frustum ( no en la primera iteración que se hace con la típica función que todo el mundo utiliza ) sinó en las siguientes, lo que hace es passar esta caga 2D a coordenadas de mundo y utilizar sus extremos, junto con la posición de la camara, para calcular el nuevo frustum.
El código viene a ser este:
D3DXVECTOR3 pMaxXMaxY, pMinXMinY, pMinXMaxY, pMaxXMinY;
D3DXVECTOR3 p00(actualRect.m_iXMin, actualRect.m_iYMin, 0.0f);
D3DXVECTOR3 p01(actualRect.m_iXMin, actualRect.m_iYMax, 0.0f);
D3DXVECTOR3 p10(actualRect.m_iXMax, actualRect.m_iYMin, 0.0f);
D3DXVECTOR3 p11(actualRect.m_iXMax, actualRect.m_iYMax, 0.0f);
D3DXVec3Unproject(&pMinXMinY, &p00, &clip->pViewport, &clip->proj, &clip->view, &clip->world);
D3DXVec3Unproject(&pMinXMaxY, &p01, &clip->pViewport, &clip->proj, &clip->view, &clip->world);
D3DXVec3Unproject(&pMaxXMinY, &p10, &clip->pViewport, &clip->proj, &clip->view, &clip->world);
D3DXVec3Unproject(&pMaxXMaxY, &p11, &clip->pViewport, &clip->proj, &clip->view, &clip->world);
frustum[4] = clip->frustum[4];
frustum[5] = clip->frustum[5];
// Right plane
D3DXPlaneFromPoints(&frustum[0], &m_vPos, &pMaxXMaxY, &pMaxXMinY);
D3DXPlaneNormalize(&frustum[0], &frustum[0]);
// left plane
D3DXPlaneFromPoints(&frustum[1], &m_vPos, &pMinXMinY, &pMinXMaxY);
D3DXPlaneNormalize(&frustum[1], &frustum[1]);
// bottom plane
D3DXPlaneFromPoints(&frustum[2], &pMinXMinY, &pMaxXMinY, &m_vPos);
D3DXPlaneNormalize(&frustum[2], &frustum[2]);
// top plane
D3DXPlaneFromPoints(&frustum[3], &m_vPos, &pMaxXMaxY, &pMinXMaxY);
D3DXPlaneNormalize(&frustum[3], &frustum[3]);
El problema viene que ponga el orden que ponga en los puntos en el D3DXPlaneFromPoints el plano siempre me hace el culling hacia el mismo lado. Alguien tiene idea de lo que me está pasando?
Merci!
VinCenT.
A que le llamas orden? v0 - v1 - v2 = v1 - v2 - v0 = v2 - v0 - v1
La verdad que de directx ... cero.
Mas que eso nada.
En principio la normal del plano depende del orden con que le pases los vértices a la función. Lo que me pasa es que ponga el orden que ponga, el clipping me lo hace siempre en la misma dirección.
Bueno, ya está todo arreglado. Mi visual necesita que lo reinicien de vez en cuando. Ahora todo funciona correctamente.
Un saludo!
VinCenT.
Menos mal!
La verdad es que no es la primera vez que una cosa que no va, reiniciando el visual funciona despues.... :blink:
Yo tengo basta experiencia en eso, inclusive cada una o dos horas reinicio la maquina.
Saludos
El Halcón Milenario tenía menos problemas que ciertos programas (y sistemas operativos).
De todos modos fijate de que no hallan quedado punteros sueltos.
Pasa que al VS no lo pilotea Hand Solo (veo un fan de SW?)
Saludos
Creo que tenemos un concepto distinto de lo que significa un "Hand Solo" (twist)
(Es "Han Solo", y aquí me parece que todos son fans de SW, es un requisito imprescindible para dedicarse a esto).
Saludos onanistas.
Tenes razón, "hand solo" era de una parodia.