[Aquí está la chapucilla]

  Como mi código es una guarrada ¡está en c! (Si, si, yo también he dao ingeniería del SW y se las ventajas de la POO, pero es que lo empecé antes de aprender C++, y como soy tan vago, por no cambiarlo todo...), pues mejor pongo algo de pseudocódigo, además, las funciones son grandes y no quiero quitaros mucho tiempo, tendréis cosas mejores que hacer. Bueno como he dicho antes, lo he resuelto de una forma que no se si es la correcta:

// En el loop principal del juego llamo a la func. ActualizaSistema

glutIdleFunc(ActualizaSistema);

//...

funcion ActualizaSistema ()
{
      tSeg <- tiempo transcurrido desde la última llamada

     Obtengo la entrada por teclado y ratón (acelreac. de la cámara, rotaciones de la cámara...)

     Roto la cámara según el ratón

     // Aquí está la chapucilla

     // Lo del 5 es temporal, debería ser una variable que se ajuste a una frecuencia fija para el cálculo de
     // colisiones, o que dependiese de la longitud del vector desplazamiento que se utilizará para las colis.

     FraccionT=tSeg/5.0f;

     para f<-0 hasta 5 hacer
     {
             // Calculo fracciones de tiempo menores, con lo que el vector de
             // desplazamiento (S = S0 + v0*t + .5 * a *  t*t)  que se calculará en la func. mueveCamara
             // será menor y evitaré los problemas de colis.

             // Aquí llamo a la función que mueve la cámara. y lo hace de forma que respete las colis.

             //                         tiempo,  gravedad ON, tipo de colis (AABB/Tri)
   
             mueveCamara(FraccionT,  GRAVIDEZ     , AABB_COLIS);

      }
   
      Calculamos FPS

      Renderizamos la escena
}

Así parece que funciona y no atraviesa ningún polig. pero como he dicho antes, no se comporta igual: en las colis. parece que se ralentiza algo. No se si es porque esto que hago es erróneo, o porque al calcular mas colisiones aplico mayor nº de veces la fuerza de rozam. o porque sobrecargo la CPU con tantas llamadas y calculos en la función de colis.
Bueno y en relación con lo del 5 temporal en FraccionT y el bucle: es mejor que sea un frecuencia cte. y calculemos el nº de iteraciones según el tiempo transcurrido, o por el contrario es mejor calcular la distancia a recorrer en este frame, y según su módulo, calcular el nº de loops (porque lo que realmente afecta a la eficacia de los cálculos son los vectores velocidad extremadamente grandes ¿no?)

  Si mira, tu tienes un array (o una lista) en el que cada entrada o índice es un puntero a otra lista de polígonos.
Bien, ahora cada vez que renderices la escena, coges los nodos visibles, y por cada primitiva de los nodos, calculas un índice asociado a dicha primitiva que dependa de su textura, material, shader... (eso lo dejo a tu elección) y con ese índice I introduces el polígono en la lista de polígonos a la que apunta el nodo I de la tabla de dispersión, así en esa lista tendrás todos los polígonos que comparten shader, o textura, o lo que sea. Opcionalmente, dentro de esta lista, sí que puedes ordenarla si los polígonos no tienen iguales todas las características que no influyeron en el cálculo del índice I.
Cuando realizas esta operación para todos los polígonos visibles, únicamente te queda ir recorriend los nodos de la tabla, en cada uno de ellos, que tienen asociado la list de elems. con misma textura por ejemp., si la lista no es vacía (hay poligs.)  cargas esa textura, renderizas toda la lista con la misma textura, y pasas al siguiente nodo de la tabla, así hasta el último nodo.
De esta forma puedes tener un vertex arrays para todos los vértices, las primitivas serán índices a éstos vértices, y las listas de los nodos serían símplemente índices a las primitivas, o directamente índices a los vértices. Así podemos renderizar los poligs. indexados en el array (lista) del nodo.  
Ya se que me explico un rato mal, lo siento.

  Vale, en mi código, como utilizo GLUT, la función que la pasaba como arg. a glutIdle se encargaba de calc. los FPS, actualizar las pos, realizar la detec. de colis. y renderizar la escena.
Ahora 1º he intentado renderizar la escena sólo cada 20ms. y así no perdería tanto tiempo en cada loop del juego, pero no ha servído de nada.
Luego se me ha ocurrido la siguiente chapuza: cada vez que voy a detectar las colisiones, si he calculado que ha transcurrido x tiempo desde el último test, entro e un bucle de, digamos 10 iteraciones, por ejemp., y llamo a la función de colisiones con tiempo x/10, así realizo 10 cálculos de colisiones con vectores de desplazamiento 10 veces menores, esto parece solucionar el error, pero imagino que es correcto, porque ahora, al deslizar por una parez, el programa lo hace de forma mas lenta y a trompicones (quizás también pueda ser por el mayor nº de cálculos que realizo).
 Ayuda por favor, que soy un negao y estoy desesperao (estoy a punto de tirar el ordenador por la ventana)

  Yo era un aférrimo defensor de OGL, pero joder, después de ésto habrá que ponerse al día con DX, JA, JA, JA! Seguro que es una maniobra del Gates para convertir a todos los programadores a su API. Menuda cara se le hbrá quedado a los productores

  Bueno pero aun así me das mil vueltas como programador eso seguro.

  Vale, gracias tío, voy a probarlo porque ya no se que hacer con las puñeteras detec. de colis.

 Hola, tengo un problema que por mas que le doy vueltas no consigo solucionar. Estoy implementando la detección de colisiones entre un objeto móvil (representado por una AABB) y el escenario (todos los polígonos son triángulos). Sigo el método descrito en el libro '3D GAMES Vol. 2', y parece que todo funciona bien hasta que encuentro zonas del tipo:
             
             1

!Menudos dibujos, estoy hecho un artista!. En estos casos, normalmente detecta la siguiente colisión, pero si sigo insistiendo en la misma dirección acabo traspasando el plano:


             2

Imagino que es debido a errores de precisión en el redondeo de los floats, pero quizás sea un error en mi código (que al final va a ser eso ya verás). Bueno si alguien sabe porqué puede pasar ésto que me eche un cable por favor. Otro tema es que una vez la caja penetra al polígono, el algoritmo no lo detecta, ¿cuál podría ser una forma óptima de hacerlo? Así podría volver a la posición anterior y evitar estos errores.
¿Conocéis algún tutorial o código en internet aparte del mencionado sobre este tipo de colis.?
Gracias.
¿Hey, porque leches no puedo meter imágenes en el mensaje?

  No tienes porque ordenarla, yo en vez de utilzar una lista, utilizo una tabla de dispersión, por lo que, dado el material del polig. lo insertas inmediatamente dentro de la tabla, y al terminar, sólo debes ir recorriendo la tabla, para cada nodo de la tablza tendrás un lista de poligs. que comparten el mismo material, por lo que dibujas todos y los cambios de estado (textura, etc.) sólo los realizas al pasar al siguiente nodo de la tabla hash.

 Pues yo me decanto por los AABB trees, ya que aunque parecen ser mas lentas que los OBB trees, permiten una rápida actualización para objetos deformables. Si te interesa, mira este doc:
vandenbergen98efficient  

                                Yo me metí en la carrera porque pensaba que tenía muchas salidas, y si, en mi clase hay muchas tías, pero n¡nguna está salida y no me hacen ni puto caso, con lo guapo que soy (bueno al menos eso es lo que me dice mi madre y mi abuela). Creo que me meteré en alguna de letras que allí si que hay tías.                                

                                Gracias por mentir tanto hacerca de lo bonita que es mi web. Respecto a tu iniciativa sólo puedo decirte ánimo y adelante, (se que es un coñazo, pero no tienes porqué hacerlo todo tu sólo, es mas, podrías proponer una página donde todo el que quisiera subiera sus tutoriales y código). Además no tiene por qué ser una página cojonuda llena de efctos y soplapolladas, lo importante sería el contenido.
 Si tienes algunos tuts mas que quieras subir a internet, estoy a tu disposición, podría mejorar algo mi web para tener una página dedicada a ellos.
Sinceramente pienso que es una gran idea, ya no solo por escribir los tutoriales en castellano, sino porque creo que el tutorial de PVS/OCTREE trata un tema muy poco detallado en internet, es frecuente encontrar artículos en inglés para crear PVS a partir de BSP y portales, pero muy poco o nada hacerca de los PVS/OCTREES.                                

                                Gracias tío, es un documento muy interesante, me va a servir de mucha ayuda. Para todo aquel que lo quiera ontener ahí va: http://be.sierra.eresmas.net/descargas/PVS.doc. A Carlos, como puedes comprobar, eso de mantener la web no es lo mío, creo que tienes razón, en vez de colgar en internet my web, creo que es mejor no poner nada y al menos no hago el ridículo, algún día de estos me pondré ha hacer una página decente de la que no me avergüence. Perdona por poner tu documento en la Web mas hortera de todo internet, creo que tu documento merece estar en algún sitio mejor, pregunta a los de stratos si quieren colgarlo en su zona de tutoriales.                                

                                Sobre tu tut. de PVS, hoy en díapuedes encontrar espacio web gratuíto donde quieras y hacer una pág. cutre está tirado con frontpage, dreamweaver o similares, de todas formas, si me lo pasas lo puedo poner en la mía (da asco verla de lo fea, hortera y mala que es, 9 de cada 10 oftalmólogos opinan que es perjudicial para los ojos) pero así lo compartirías para la gente que quisiera bajarselo. Cuando termine los exámenes e implemente la detec. de colis. en mi motor (por llamarlo de alguna manera), también me pondré a estudiar el tema PVS, pero con OCTREES, ya he encontrado algo de inf. tuts. y código para este tema                                

                                Oye muy bueno tío, a mi me va d eputa madre, 85 fps y porque ese es el refresco de mi monitor. Lo que hecho de menos es una animación al andar hacia atrás. Una pregunta ¿Qué tipo de detección de colisiones utilizas? (polígono/polígono, AABB/ polígono, esferas/esferas...) Yo estoy estudiando qué algoritmo utilizar, si sabes de algun tutorial en internet que merezca la pena cuéntamelo.                                

                                Bueno, lo de que con los Shadow Maps solo sirvan para luces direccionales no es del todo cierto, por ejemplo en http://www.delphi3d.net tienes una demo de dual paraboloid shadow mapping, el cual permite sombras generadas por pointlights.