¿Qué es un OBB? ¿El Bounding Box del objeto?

Yo conocía las técnicas del arbol de BB o BSpheres.

Yo utilizo los BB. Aunque siempre he pensado que lo mejor sería utilizar un octree también para las colisiones. Sin embargo, no he implementado nada ( ¡siempre me falta tiempo!)
Pero también hay que saber con qué colisionan. En mi primera versión del motor, utilizaba un Quadtree que colisionaba sólo con un segmento. Ahí las colisiones eran muy rápidas. El problema está cuando queremos comprobar las colisiones triángulo a triángulo, que es la única forma de saber si dos objetos colisionan de verdad. Pero ..¿realmente hay que llegar a tal grado de precisión?
                               

                                ¡No me he molestado en absoluto! Pero muchas gracias por las disculpas, dicen mucho por tu parte ( ante todo seamos respetuosos unos con otros)

Bien, es decir, que por lo que me cuentas, lo único que haceis es BFC por hardware. Perfecto, esa es la conclusión a la que llegué. Hacerlo por software es contraproducente.
Y ahora que parece que la cosa se va aclarando..¿hay alguien que lo haga por software que crea que vale la pena?                                

                                A ver, me gustaría deciros que SE PERFECTAMENTE lo que es el BACK FACE CULLING y como expliqué un poco más arriba, LO ESTUDIE DETENIDAMENTE E IMPLEMENTE DIFERENTES OPCIONES. La verdad es que es difícil expresarse usando sólo texto y algunas veces se da pie a cierta confusión.
Y ahora Julio, si dices que ahorras muchísimo tiempo, me gustaría que me explicaras el algoritmo que utilizas para ahorrar tanto tiempo, porque yo HE PROBADO MUCHOS Y CON NINGUNO HE GANADO TIEMPO.
¿a ver si los que perdeis fps sois vosotros porque utilizais BFC?
¡Atención, sólo estoy compartiendo mis conocimientos con vosotros! No me gustaría que nadie se molestase. Estos mensajes los he puesto porque CREO que os equivocais, y como yo lo estudié mucho, me gujstaría ayudaros(o que me ayudeis vosotros diciendo DONDE me equivoqué yo!)
Pensad que mi motor es MUY MUY rápido, comparado con otros motores que existían en la scene de características similares. Así que se un poco de lo que hablo...

Y esto del Back Vertex Culling ya lo he explicado un poco más arriba! Por favor, que nadie siga comentando esto....                                

                                Turrican:
Me parece que estás equivocado. DX NO hace BFC en 3D. Y el culling que tu dices que se indica, es para que él sepa la dirección del culling y si realmente quieres hacerlo.

El hardware sólo puedo resolverlo en 2D y nunca en 3D, puesto que no tiene ni idea de la matriz de la cámara, aunque haya una GPU!!                                

                                No entiendo bien a Turrican. ¿Dices que el BFC será más rápido si tienes una GPU? Yo creo que no.

Y pensad como funciona una tarjeta:Coge los vértices, los convierte, y empieza a dibujar triángulos. Pero antes de dibujar el triángulo comprueba el BFC...¡a nivel 2D!

Por ello si no eliminas vértices, el BFC no sirve para nada.

Atención:¡esta es la conclusión a la que llegué después de mucho probar y optimizar! Si alguien no está deacuerdo...¡que comparta sus conocimientos con nosotros!                                

                                No es lo mismo el Back Face que el Back Vertex(que es un concepto que me inventado yo después de tu primera respuesta!)

El problema del back face culling es que no sirve para nada si no puedes descartar los 3 vértices que forman la cara. Pero para poder descartar los 3 vértices tienes que RECONSTRUIR la indexación de las caras. Y además tienes que SABER que puedes descartar esos 3 vértices.
Y TOOOOODOOO esto para no pintar una cara que el hardware ya decide por sí solito que NO tiene que pintarla.

Por eso digo que no sirve para optimizar. Sin embargo he leido muchos posts donde parece que sí lo usais para tal acción, y por ello mi pregunta de a ver si el método que utilizais realmente optimiza.                                

                                Berserker:

Según lo que tu me dices, lo que hay que hacer no es Back Face Culling, sino Back Vertex Culling!!

Sigo creyendo que el Back Face Culling NO tiene sentido. Yo incluso ordenaba las caras de los objetos para que el BackFace fuera óptimo...¡y ni así se ganaba!                                

                                Se habla mucho aqúí de la optimización BackFace Culling. Sin embargo, en mi primer motor implementé y estudié ampliamente esta opción y...¡no se ganaba tiempo en absoluto!
Y de verdad que estudié mucho el tema, probando diferentes técnicas y en ningún caso, en ninguno, valía la pena.

¿En qué me equivoqué?                                

                                No cortar! Si cortas no podrás tener un mundo dinámico!! Aunque como bien han dicho..¡no lo dibujes 2 veces!

Por cierto, se habla mucho de los octrees, pero en portales, casi siempre es suficiente con un Quadtree!!                                

                                Yo no he implementado todavía nada con portales, sin embargo los he estudiado mucho para poder implementar algo que sea realmente potente.
Aquí viene la explicación:
Usas portales sólo para ganar velocidad, eso que te quede muy claro. Por tanto el nº de portales que decidas colocar ya no es tan importante. Hoy en día un sector tiene muchos polígonos, por lo que ahí entra la necesidad de "subdividir" el propio sector. Esto puede hacerse con portales, con lo que tienes que un portal te divide dos sectores y sectores dentro de sectores(es un poco lioso!) Sin embargo, yo te aconsejo que le des facilidad al grafista y le pidas que te haga el menor número de portales posible, y si tienes sectores con muchos polígonos utilices un octree.                                

                                ¿Alguien puede explicarme, o indicarme dónde puedo recabar información a parte de las SDK, sobre los POOL de memoria que hay en DX8? Sus tipos y para qué se debe usar cada caso.                                

                                Ithaqua, quizás no hablamos de lo mismo. Piensa que en el vertex shader hay me parece que espacio sólo para 128 instrucciones(aunque de esto no estoy seguro. Creo que lo leí en la SDK pero ahora no lo encuentro!) Por tanto, me limita mucho ya sólo este aspecto. Después tengo que compilar el vertex shader en tiempo de ejecución. Y ya sabes que según que tarjeta tengas, al final podrás usar uno u otra shader!! Y todo esto para qué:¡sólo para ganar velocidad! Es decir que complico la historia un montón, elimino un montón de tarjetas que no soportan el shader en hardware, para que se puede jugar a 80 fps en 1600x1200!! Pues yo prefiero que el juego funcione en muchas más ordenadores, con TODAS las características, pero que jueguen a 80 fps en 1024x768.

Sin embargo, esto es una opinión. Es evidente que algo falla en los Shaders cuando Microsoft saca una nueva versión en cada revisión de DX. Y en la 9 aparecerá la 2.0, con control de flujos!!                                

                                No he visto nunca el q3Radiant, así que no puedo ayudarte.
Pero fíjate que por tu reflexión te encaminas a que lo mejor es hacer un editor.
                               

                                Bueno, en realidad el gran problema estriba en aquellos polígonos que pertenecen o no pertenecen a 2 sectores. Si una pared pertenece a un sector, lo lógico es que la parte de atrás pertenezca a otro. Pero si es 1 solo objeto..¿Cómo puede saberse?
Ese problema me lo he planteado mucho, porque mi idea es también cargar una escena de MAX y punto, para no tener que hacer un editor. Al final, después de mucho pensar, me di cuenta de que...¡lo mejor es hacer un editor! Pero bueno, dejaremos esta reflexión para otro momento.
El problema de la famosa pared que comparte 2 sectores, se puede solucionar..¡teniendo 2 paredes! Una para cada portal. Esto rompe totalmente con la idea de optimización, y por supuesto de BSP, sin embargo es la mejor forma que encontré(y esto lo he razonado muchooo)

Después hay el problema de decirle...¿Qué objetos forman parte de un sector? Bien, la idea del nombre es buena, pero muy engorrosa. Yo apostaría por esta otra:Encierra los objetos que tu quieras que formen un sector en un cubo. Y a este cubo dale el nombre del sector y las propiedades del mismo. Así cuando hagas un sector, agrupas los objetos junto al cubo y...¡perfecto! El grafista tiene los sectores agrupados y tu tienes la información que necesitas.

                               

                                Hay mucha documentación sobre Octrees. Te propongo que vayas a http://www.flipcode.com y busques por la palabra octree

¡Te sorprenderá la de cosas que hay!

Por cierto, la optimización octree es terriblemente buena. El único problema es que no puedes determinar qué esta delante y que está detras. Yo prefiero portales y dentro del porta un octree.