Si, pero si el objeto está asociado a un solo nodo mas grande que su volumen acotante (AABB,OBB,etc.) Puede ocurrir que, por ejemplo, un objeto muy pequeño se encuentre ocupando la mitad de un lado del nodo raíz, y en vez de ocupar tan sólo un par de nodos pequeños, como queremos englobarlo dentro de un solo nodo, estaría asociado al nodo raíz y por lo tanto a la hora de testear colisiones lo deberíamos hacer con todos los objetos tanto estáticos como dinámicos del mundo, y si luego no lo seguimos asociando recursivamente a todos sus hijos, sólo renderizaríamos el objeto el la situación de que el nodo raíz entero fuera visible:

----|-----|-----|-----
|     |    ooo     |      |
|     |    ooo     |      |
|----|-----|-----|-----|
|     |      |       |      |
-------------------------
|     |      |       |      |
-------------------------
|     |      |       |      |
----|-----|-----|------

  No se si me entiendes, la verdad es que el dibujito es una jena (se supone que es un quadtree con un objeto insertado representado por os).
  Por otro lado, si asociamos al objeto sólo el nodo en el que se encuentra el centro de su AABB, y la AABB ocupa otros nodos, no calcularíamos las colisiones con estos otros nodos, y si alguno de éstos fuera visible, pero el que contiene el centro de la AABB no, no renderizaríamos el objeto (joder que lío)
  Ya se que me explico muy mal, pero espero que alguian consiga entender esta sarta de tonterías que acabo de escribir                                

                                Si, tienes razón, yo me refiero a actualizar dicho array de punteros, es decir, si un objeto cambia de pos. su array de punt. a nodos en los que se encuentra ya no será el mismo, pero el problema es calcular todos los nodos en los que se encuentra para marcarlos con los nuevos punteros que formarán parte del array.
  Por último ¿Qué diferencia hay entre mallas dinámicas y obj. que cambian de pos? Yo los trataría de igual manera con una AABB lo suficientemente grande para que englobara los distintos cambios (frames de animación, deformaciones del agua...) y con esta AABB realizaría las comparaciones con los nodos del OCTREE                                

                                Perdón, creo que es:

CENTRO DEL PADRE +- LADO DEL PADRE/4

Y lo siento por escribir tan mal, soy un inútil del teclado                                

                                Hola, tengo un OCTREE con los datos estáticos de la escena, pero a la hora de insertar y mover objetos dinámicos, tengo que recaculcar en qué nodos se encuentran, tanto si son nodos hojas como en los nodos internos (ya que si ub bodo que no es hoja se encuentra completamente contenido en el interior de FRUSTUM, lo mando renderizar sin seguir visitando a sus hijos). Mi prugunta es la siguiente:
  ¿Qué método es el mas efectivo para realizar estos cálculos? Ya que si comienzo desde el nodo raíz, visitando recursivamente todos sus hijos hasta llegar a los nodos hojas, el algoritmo serñia muy costoso.
  ¿Hay algún algoritmo mas eficiente? E visto por ahí que se puede aprovechar el hecho de que los hijos tienen lados de longitud igual a la mitad de la de los del padre, y que sus centros se encuentran a:

                     CENTRO DEL PADRE +- LADO DEL PADRE/2

por cada coord. X,Y,Z.

  Si tenéis algo de cód. fuente o pseudocódigo mandármelo por favor.                                

                                Gracias por los links, me pondré con ello en cuanto termine con el tema de las colisiones (nada fácil), pero entre las fiestas, luego prepararse los exámenes y después el esperado viaje de fin de curso (la única razón por la que me metí en la facultad) creo que me llevará tiempo, porque me lo voy a tomar con calma (no es bueno intentar programar con resaca, lo digo por experirncia).                                

                                Si bueno, la distancia del plano far biene dada por una variable, podría incluir dos teclas para acercarlo o alejarlo, de todas formas, en cuanto ponga el efecto de niebla atenuará el problema.
Por cierto ¿Dónde puedo encontrar una página buena con información del tema de los shaders en los mapas del QIII? Y otra pregunta, con respecto al tema de los FPS (aunque el motor no está optimizado) ¿Que tal os va?¿Os anda a patás o va a una velocidad aceptable?¿En qué equipo lo probasteis?
Gracias.                                

                                Si, uso GLUT y lo tendré en cuenta para incluir las dlls en la próxima versión.
Con respecto a lo de las partes de la escena que no se renderizan, creo que te refieres a que en ciertos polígonos no se dibujan las texturas y sólo aparecen en azul, ya que no dibujo los colores del polígono, creo que ésto ocurre porque algunas texturas bienen en los scripts de los shaders y por ahora el motor no las carga (aunque no estoy seguro de ésto).
Por último decirte que las líneas que se dibujan corresponden a los nodos del octree en los que se encuentra la cámara actualmente (sólo si los nodos contienen polígonos). Ésto es necesario para cuando programe la detec. de colisiones con respecto a la cámara.                                

                                Hola, os invito a que visiteis mi pagina web
http://usuarios.lycos.es/jalfonsosm/
todo un alarde de imaginación, os aseguro que nunca habéis visto nada igual XD.
Bueno fuera de cachondeos, allí podreis bajaros una demo mi pequeño motor 3D que aún está muy verde, pero me gustaría que lo probárais y me mandaseis los errores, impresiones o lo que queráis (en el hipotético caso de que consiguierais arrancar el programa, ya sabemos que esto de tener tantos ordenadores y configuraciones distintas es una jodienda para las palicaciones 3D).
Gracias[/url]                                

                                Creo que te refieres al problema del "aliasing". Para solucionarlo, busca en la red por "antialiasing"                                

                                gracias por tu respuesta                                

                                Tengo una función, que a partir de las matrices de modelado y proyección de OpenGL, extraigo los planos del frustum en coord. de mundo.
Mi pregunta es: ¿Qué método sería el mas óptimo para obtener los vértices del frustum? Es decir, a parte de la posición de la cámara en coord. de mundo, quiero conocer los 4 vértices en coord. de mundo que delimitan el plano de corte lejano.
¿Es mejor obtenerlos a partir de sus coord. de recorte y las matrices de proy. y modelado? (no estoy seguro, pero creo que en este caso la concatención de matrices sería distinta a la usada para la extracción de los planos del frustum, ya que para los planos y normales (covariantes)  se utiliza la matriz traspuesta de la inversa de la transformación de ptos.),
O por el contrario es mas eficiente encontrar los puntos de corte de los planos extraídos en coord. de mundo.
Conoceis codigo fuente que resuelva este problema.

Gracias