Hola Klinex:

Seguramente no soy la persona más indicada para responder ya que nunca he implementado un octree pero aún así lo intentaré :ojo:

La técnica consiste como tu dices en ir subdividiendo el espacio en nodos (cubos como tu dices) hasta que se cumpla una cierta condición. Una de esas condiciones (hay más) es que se llegue a un nº mínimo de polígonos por nodo. Evidentemente tendrás que ir viendo qué faces están dentro de cada nodo e incluso podría caber la posibilidad de recortar los polígonos que compartiesen mas de un nodo (yo personalmente con la potencia de las aceleradoras actuales no soy partidario del clipping porque entre otras cosas puede ocurrir que acabes con bastantes más polígonos de los que tenías en un principio). En esta fase inicial el frustum no lo utilizas para nada ya que lo que te va diciendo qué face se debe añadir a un nodo o a otro es el propio nodo (su bounding box). Así tenemos que en un principio crearías un cubo que acaparase toda la geometría (es decir, tendrías que buscar el vértice con coordenada mínima y el que tenga la coordenada máxima de entre todos los vértices de tu geometría) y a partir de ahí irías subdividiendo el espacio e irías asignando a cada nodo los índices de las faces que contiene.

Ahora bien, donde sí utilizarás el frustum es durante la ejecución del programa ya que a través de él podrás saber qué nodos (las bboxes de éstos) están en el campo de visión (ya sea total o parcialmente) de la cámara y por lo tanto también sabrás qué faces debes mandar al renderer.

Como he dicho antes no soy la persona más indicada para hablar de octrees ¡pero espero que lo que te he dicho sea una ayuda! :sonriendo:

Un saludo.

[ Este Mensaje fue editado por: BeRSeRKeR el 2002-03-16 10:12 ]                                

                                Drácula

Gracias por la proposición. Sin duda, si tengo alguna duda o algo que comentar aquí lo pondré...y la verdad, yo también me alegro de que el foro vuelva a ser lo de antes incluso mejor (por ahora los posts están siendo muy interesantes)

Un saludo                                

                                La verdad es que ya avisó de estos problemas con el ICD OpenGL de las Radeon John Carmack (otra vez Carmack :ojo:) en su último http://finger.planetquake.com/plan.asp?userid=johnc&id=15810>plan. Recomiendo la lectura de dicho plan ya que saca conclusiones muy interesantes que se deberían tener en cuenta (no sólo para los programadores sino para los propios usuarios de videojuegos).

Un saludo                                

                                Emotion

Efectivamente debemos pensar por nosotros mismos (al fin y al cabo así es como se evoluciona) pero también es cierto que no es malo fijarse en el trabajo de los demás pero aún así te doy toda la razón en que lo que verdaderamente puede revolucionar el mundo del videojuego se encuentra en los papers del Siggraph o de las universidades por ejemplo...e incluso de personas anónimas!...pero aún así no podemos obviar que Carmack siempre va por delante de sus competidores y cuando saca un engine siempre hay una pequeña o gran revolución (el sistema de shaders de quake3 me parece muy bueno y lo hemos adquirido; ampliándolo eso si, para nuestro engine) y si no piensa en una cosa...qué engines han superado (en igualdad de tiempo) a los de id Software?...yo creo que ninguno...y seguramente así ocurrirá en el momento de salida de Doom3. Y es que como dijo una vez Carmack a ellos no les preocupa la competencia conocida (ej: Epic) sino ese grupo de personas que trabaja duro en el anonimato en busca de revolucionar el software de entretenimiento al igual que hizo id en sus comienzos.

Drácula

Efectivamente el tema de los vertex shaders me parece aún bastante lioso como para utilizarlo (el caso más claro es el que tu dices de las luces) de echo en nuestro engine estamos utilizando la fixed pipeline ¡y por ahora estamos muy contentos! :sonriendo:

Un saludo                                

                                Ithaqua

Reconozco que hace ya algún tiempo que dejé de utilizar OpenGL y está claro que vosotros (los que lo utilizáis a diario) y no yo sois los que podéis hablar con conocimiento sobre el tema. Pero lo mismo que digo esto también pido que aquel que no haya utilizado Direct3D (a partir de la versión 8) se abstenga de criticar ya que precisamente esas personas son las más radicales, las que lanzan las críticas mas duras y encima muchas de ellas sin sentido y falsas...ahora, si escucho las críticas de una persona como Dracula que ha utilizado intensivamente Direct3D pues me callo porque sé que habla con conocimiento de causa y punto...sin problemas ni rencores porque al fin y al cabo el fin de todo es crear ese engine que tanta ilusión nos hace con este y aquel efecto...y da igual con que medios lo consigamos, ¡el caso es conseguirlo! (bueno y que vaya bien ;))

Un saludo

[ Este Mensaje fue editado por: BeRSeRKeR el 2002-03-14 23:35 ]                                

                                Quiero dejar claro que no soy un experto en engines o programación 3D (todos los días se aprende) ni quiero parecerlo...pero no creo que lo que digo esté exento de lógica alguna...y si no, ¿por qué todos los juegos que conozco utilizan un VSD?. Así es en el caso de la serie quake y derivados y Unreal (BSP trees), Blade y el tan esperado (por lo menos para mi :sonriendo:) Doom3 (portal rendering)...y no creo que por utilizar por ejemplo un sistema de portales estés limitando la posibilidad de crear cualquier efecto que se te pase por la cabeza siempre y cuando sea posible en el hardware presente.

También quiero dejar otra cosa clara. No quiero que nadie se ofenda con lo que he dicho sobre OpenGL entre otras cosas porque no he dicho ninguna mentira. La cuestión es que ni quiero ni me apetece entrar en una discusión de este tipo porque como han dicho por ahí arriba eso ya está muy visto y todo lo que digamos será repetir una y otra vez lo que ya hemos leído u oído (muchas cosas de personas que en su vida han utilizado Direct3D y que tan sólo se guían por aquel famosísimo plan de Carmack sobre DX3 o 5, no recuerdo...y la verdad, las cosas han cambiado mucho desde aquel entonces). Sólo diré una cosa más sobre el tema...incluso el mismísimo Carmack reconoció la capacidad de la "nueva" versión de Direct3D y no sólo eso sino que además en su último plan también manifestó su disgusto por todo el tema de las extensiones (que si los vertex programs de nVidia no valen en los de ATI y muchas cosas más).

Un saludo                                

                                Así es la vida del programador querido Lessman :sonriendo:...un aprender sin fin!!                                

                                Emotion:

Es cierto que para el tema del render podríamos pasar del tema de la jerarquización y mirar qué objetos, a través de sus bboxes, bspheres o lo que sea están dentro del frustum y una vez que tenemos esos objetos que son visibles (o parcialmente visibles) hacer un backface culling de las faces de dichos objetos...pero aún así, ¿no sería mejor tener una jerarquización de la escena para decartar esos objetos de una forma mucho más rápida?...lo que quiero decir es que teniendo un sistema por ejemplo de portales tenemos que si estamos en un sector en el que hay un portal a través del cual vemos otro sector, si a través de dicho portal no vemos otro portal quiere decir que aunque el nº de sectores que pudiesen haber (cada uno con los objetos que contuviese) fuese de 1000 pues tan sólo recorreremos 2 (el sector en el que estamos y el sector que vemos a través del portal).

Y lo mismo se puede decir para las colisiones...no es lo mismo averiguar si hemos colisionado con 40 objetos que con 1000...supongo que nos ahorraremos unos cuantos cálculos...

Por otro lado creo que si John Carmack se decidiese a programar en Direct3D, haría engines tan rápidos y buenos como si los hiciese en OpenGL...los programas no son más rápidos o buenos porque se utilice una u otra API sino porque el programador que los haya creado se ha preocupado de que así sea.

Yo personalmente utilizo Direct3D (comencé con OpenGL y lo utilicé durante unos 2 años) y la verdad me ahorro toda la problematica de las extensiones y de tener que reprogramar muchas cosas para cada una de las aceleradoras del mercado (o bueno, por lo menos las GeForce y la Radeon). Porque si OpenGL es portable entre plataformas y sistemas no lo es tanto entre aceleradoras (vale, es cierto que si utilizamos un glVertex pues no nos preocupamos...¿pero a donde vamos con un glVertex?...tu mismo has comentado la extensión Vertex Array Range sólo presente en las GeForce de nVidia). No creo que a nadie se le pase por alto que el sistema de extensiones se está convirtiendo en un lio padre...de ahí que se estén presentando las bases para un nuevo OpenGL...OpenGL 2.0

Un saludo                                

                                De momento estoy bastante ocupado con el engine que estoy programando con un colega así que los tutos están aparcados por el momento...pero me gustaría escribir alguno más...a ver si saco tiempo y lo hago. Mi pensamiento ha sido desde hace algún tiempo escribir uno sobre frustum culling..pero ya veremos.

Y bueno, más tutoriales sobre D3D básicos (en inglés) pues puede ser los de http://nexe.gamedev.net que intentan ser una imitación a los de OpenGL de NeHe. En uno de sus tutoriales me parece recordar que había un cargador de modelos en formato ASCII de milkshape......además ese formato soporta bones así que puede ser un comienzo!

Un saludo.                                

                                Creo que aunque el BSP/PVS se está dejando atrás (sobre todo porque no permite el dinamismo de por ejemplo un sistema basado en sectores/portales), no es justo decir que no sirve para nada...porque realmente no hay ningún engine con portal rendering que pueda superar en frame rate a un engine basado en un BSP/PVS. Por otra parte un BSP es magnífico para la detección de colisiones por ejemplo. En lo referente al formato de objeto...no lo entiendo bien pero creo que es absolutamnte necesario tener una jerarquización de la escena (un octree, un BSP, sectores...) para el descarte rápido de polígonos y también y muy importante para una rápida detección de colisiones (y supongo que también para la IA).

Y pasando a lo de los tutoriales, en flipcode había (y supongo que seguirá habiendo :ojo:)una serie de tutoriales sobre portal rendering escrito por "The Phantom".

Un saludo