Buenas a todos muchacho...
Bueno desde hace unos dias he estado analizando el codigo que me ha enviado un buen amigo... Donde el pequeño programita carga un Archivo 3DS y desde luego aqui tambien se considera un Octree, Frustum,culling y todos estos aspectos para acelerar el renderizado , ya saben...

Bueno el hecho es que analizando el programa detenidamente se puede ver la estructura de archivo .3DS (binario)  y la forma como se

guardan los datos en este tipo de archivos, esto me ha sido muy provechoso ya que puedo cargar la data del archivo 3DS y

adecuarla al programa que estoy haciendo...

Bueno el problema es que en el mismo programa no estan especificados todos los tipos de datos que se guardan osea que hay nodos (partes del archivo-en binario) que se  ignoran como lo de los keyframes y otras cosas...

Megustaria saber si alguno de ustedes me puede proporcionar informacion sobre la forma como se guardan los datos en un archivo .max y tambien de maya puesto que quiero que mi programa interprete todos estos formatos y asi los pueda manejar en mi entorno...Ahhh y si tubieran la estructura completa del archivo 3DS tambien me seria util...

Porfa...los que tubiesen informacion de la estructuras de estos archivos a ver si me dan una mano...Se los agradeceria un monton...

......Salu2 a To2......

[senior wapo]

Otra ves gracias...senior wapo... :D
Buena explicacion...

Algo muy parecido a lo que describes sobre el frustum lo encontre en http://www.fuzzygamedev.com/?p=215 donde realizan la demostracion matematica de sacar los planos del frustum, para verificar si algun BoundingBox o BoundingSphere esta dentro del frustum...es muy bueno... :)

Ahora se que estoy por el camino correcto...ejejjejje :idea:

Oe senior wapo gracias por tu tiempo... espero que cuando tenga otras dudas me puedas dar una mano :wink:

rectifico lo anterior sobre el frustum...se que la piramide frustum tiene 8 vertices..jeje

[senior wapo]

Oe senior wapo...que buena explicacion del tema... :D

La verdad es que he leido varios tutoriales y ninguno me revelo los misterios(Bueno almenos para mi) que has expuesto...En todos los tutoriales que habia leido graficaban el octree como cubos cerrados...nunca imagine que fuera diferente

Gracias senior wapo por todo tu ayuda me sacado de muchas dudas...Ahora si tengo una idea clara de la particion del espacion con octrees...

Bueno viejo ahora me surge un interrogante...pero mas bien es algo que necesito que me confirmeis... :?:

Segun lo que me has explicado...(de la definicion de octree)

Cuando haga la verificacion del frustum lo logico deberia ser que verifique por cada punto guardado(osea dentro de un nodo del arbol)... si uno o mas de los seis vertices del frustum cae dentro de una de las 8 diviciones del octree no... si es asi ese subespacio es candidato a ser evaluado para ver si un objeto que esta dentro de el cae en el frustum...
bueno segun mi razonamiento pienso que es asi ... o acaso usan una logica distinta o mas rapida... :?:

Esta bien...  8)
Si entiendo la parte en que cuando el mesh es demasiado grande debo considerarla en varios nodos... pero lo que realmente quiero saber es como se empiesa a guardar cada objeto en cada Voxel (nodo) y saber si tal ves el tamaño del voxel es predefinido antes de guardar cualquier objeto o su tamaño se establece a la hora de analizar cada objeto
...y que pasaria con el siguiente objeto...

Bueno pienso quien alla hecho esto antes me imagino que almenos debe tener una serie de pasos generalizados no...?? :?:

Simplemente quiero un pequeño algoritmo para que me de una idea... y ya yo analizando lo podre ajustar a mis necesidades...

Les agradeceria un monton que me respondieran... :wink:

Buenas a todos... Estoy empesando a hacer un pequeño proyecto...Se trata de un pequeño programita para mi tesis sobre representacion 3D y masomenos tendre que construir un buen algoritmo para administrar las geometrias que tenga en el entorno...Bueno segun lo que hasta ahora e leido he considerado que un octree seria muy conveniente para manejar la disposicion de los objetos en el espacio...Ademas de poder lidiar con culling, Frustum...ya saben

Bueno segun he leido entiendo que el octree Guarda en cada Hoja la geometria deacuerdo a un criterio...

Bueno mi problema es que no se cual es el criterio que se tiene en cuenta para colocar un solido en alguno de los nodos del octree...

Por ejemplo si hay un solo solido en el entorno me imagino que ese estara en la raiz del octree...y luego cuando se agregue un segundo solido al entorno que hago???...comparo su volumen y posicion con respecto al nodo anterior por ejemplo o que debo hacer para hubicarlo dentro del octee....

la verdad es que he imaginado algunos algoritmos pero no se si estare en lo correcto...

Bueno no se si podrian ayudarme tal ves describiendo los pasos que debo hacer para agregar un nuevo solido al octree...Se los gradeceria un monton... :D

Haaa...oigan alguien sabe como pongo una imagen en mi perfil...tengo probleas por que no me permite cargar una img desde mi pc...alguien sabe como se hace??? :?:

Hola a todos...
Haddd a que te referias con la propiedad Visible de Mesh (acaso existe eso)....??? ()

[shephiroth]

Con respecto a lo que dijo shephiroth... Bueno analizando detenidamente el algoritmo te daras cuanta que si funciona...por que solo es cosa de hacer el Bucle cuando el mouse ha hecho click (sin importar estados de moviemiento de las mayas) de modo que antes de empesar el bucle podria haber una variable IndexMeshSelec=-1 y ademas el PixelBackBuffer=Color.Black, PixelAnterior=Color.Black por ejemplo...si despues de renderizar alguna mesh if(PixelBackBuffer!=PixelAnterior) Entonces ha cambiado el BackBuffer a causa de renderizar la mesh de modo que esta seria la selecciondo(por ahora) ademas hacemos PixelBackBuffer=PixelAnterior; y se repite el bucle...

El unico problema que he notada es que si se renderiza una mesh del mismo color a alguna mesh anterior q fue candidata el PixelBackBuffer seria = al PixelAnterior ... bueno esto creo que lo solucionaria Comparando los colores de las mesh y si son = entonces la ultima es la nueva candidata...

Gracias de todos modos por la critica... Se que todo es en pos de perfecionar nuestros codigos...


Oe Tei la sugerencias que me has dados son muy interesantes...sobre todo lo de recorrer el camino del rayo me parece un algoritmo muy valioso practico y rapido...El unico inconveniente que tengo es que no he leido mucho sobre arboles BSP pero creo que ya me estoy convenciendo de que es lo siguiente que debo hacer para mi programa...(eso de saber que objetos se renderizaran y cuales no lo haran es de vital importancia para la velocidad de un aplicacion como estas)

Gracias por todo... Tei

Brother a ver si me recominedas algunas paginas que conoscas donde expliquen el tema con facilidad....

A por cierto ¿que significa FPS?--Acaso Frames por segundo jajjajaja

Bueno aprovechando el temita...en el programa que estoy haciendo tambien requiero que mi programa detecte que mesh se a seleccionado al hacer click en la pantalla...Bueno segun he leido muchos hacen los siguientes pasos:
1) Calculan el rayo que produce el mouse en el espacio
2) Con ese rayo verifican en cada mesh(que pueden ser cientas) si uno de sus triangulos(q pueden ser hasta millones) ha sido intersectado por el rayo...( Mesh.Interction(...)  )

Bueno no tengo ninguna duda que funciona...pero me parece un proceso demasiado lento...A mi por mi parte se me ha ocurrido por ejemplo hacer el siguiente proceso(que creo que seria muchisimo mas rapido)...

1)Renderizar una mesh (la primera por ejemplo)
2)Obtener el BackBuffer Actual en una varible y transformarla a Bitmap
3)Obtener el pixel de la posicion del mouse en la pantalla 2D(claro habiendo calculado previamente la posicion xy con su escala con respecto al tamaño del BackBuffer y todo eso )
4)Si se obtubo un pixel diferente al pixel que habia antes de renderizar esta mesh entonces el Backbuffer ha si cambiado en la renderizacion de esta mesh y por lo tanto se considera esta mesh como posible candidata a haberse seleccionado...
5)Pasamos al paso "1)" analizando una nueva mesh

*El algoritmo termina cuando se termina de renderizar todas las mesh...considerandose como seleccionada a la ultima candidata...

Bueno este proceso que se me ha ocurrido a mi parecer es mas rapido que hacer muchos de calculos por cada mesh(ya que poseen cientos de trinagulos)...Lo que desearia es la opinion de alguno de esta comunidad...A ver si conocen una idea diferente que mejore el proceso...
Se los agradeceria un monton...

Ha por cierto muchachos ¿Conocen como puedo saber si el Backbuffer ha cambiado despues de renderizar una mesh? -Por que puede que la mesh no este al frente de la camara y entonces el Backbuffer no cambia para nada con respecto a un renderizado anterior...No se tal ves el device tenga una propiedad o algo asi que indique eso ... les agradeceria un monton su ayuda...

Gracias... BeRSeRKeR   :D  :D  :D ya me funciona.....
realmente lo multiplicaba por que pensaba que era necesario tener una matris en la cual te bases y luego a esa aplicarle las tranformaciones...pero ya me di cuenta que eso estaba muy mal... Asi es cuando estas iniciando en 3D jejjeje  .... :) Bueno gracias por la ayuda ps BeRSeRKeR... es bueno saber que  hay patas como tu pa ayudarnos ps a los mas necesitados...jejeje

Hola a todos...Bueno tengo unos problemillas con la matris vista...Lo que pasa es que quiero aplicar las distintas transformaciones a la camara(una clase q he creado, que maneja la matris vista) osea Mover, rotar, escalar...osea q posea la misma funcionalidad que se le aplica a los objetos...Bueno de modo que queda de la siguiente manera...

MatrisVista = Matrix.Invert(MatrisTransformacion) * Matrix.LookAtLH(Vector(0, 0,0),Vector3(0, 0,5),Vector(0, 1, 0));  

bien el problema surge que al mover la camara 3 unidades en Y por ejemplo (esto implica que el objetivo y centro de la camara tambien estrian en 3 unidades en Y) los objetos se dibujan en sus correspondientes posiciones pero parece que los hubiesen girado en sentido contrario a la camara..realmente no se que pasa (de loq ue si estoy seguro es que de INvertir la matris no es la culpa)...no se si me podrian ayudar ya que soy nuevo en esto de Directx...

Saludos a todos...al al tratarse del tema del backbuffer (y al ver que son algo expertos) queria preguntarles un detalle...saben como saber si el backbuffer ha cambiado entre una llamada a Mesh.DrawSubset()... y la siguiente... A ver si me dejo entender masomenos este es el algoritmo...

//Dibujo el mesh(aqui el contenido del backbuffer seria el inicial)
mesh.DrawSubset(x)
//Ahora lo que quiero es comparar si ha cambiado el backbuffer con respecto al estado inicial
if("que hago aqui")
{

}