Transformar Matris Vista

[kuo]

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...

[BeRSeRKeR]

Se supone que invirtiendo la matriz de transformación de la cámara, ya obtienes la matriz de vista, por lo que no entiendo por qué multiplicas por la matriz que genera LookAtLH.

Saludos.

[kuo]

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

[kuo]

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...

[shephiroth]

Buenas. No te puedo dar la solucion, pero te puedo hacer una "critica constructiva"....que ocurre si el mesh seleccionado (o q se intenta seleccionar) no se ha movido?? No habria cambio de color en el pixel, por lo que o no llegariamos a tener un mesh candidato o seleccionariamos un mesh candidato incorrecto (puesto que el mesh seleccionado no fue candidato).

SALUDOS ^^

[Tei]

Quizas te pueda interesar como se hace en un FPS.

Una vez calculado el punto de origen y de final del rayo (que se calculan como has dicho), se recorre ese camino a pasos (el tamaño del paso es arbitrario, quizas un poco mas pequeño que el objeto mas pequeño).
Entonces a cada paso se calcula si ese punto esta dentro o fuera de un objeto.  Los objetos estan rodeados de una malla muy sencilla. Un cuadrado o una esfera. Asi que el calculo de dentro o fuera es trivial (en el caso de la esfera, una resta entre dos vectores).  Ademas no consideras todos los objetos del juego, sino un subconjunto que puede ser por ejemplo el subconjunto de los objetos que el mapa te dice que son visibles ( el PVS en un mapa BSP ).  La gente que diseña mapa se lo curra para que las areas de visualizacion sean pequeñas, de modo que haya que testear pocos objetos (no hacen los mapas de modo que todo el tiempo se vean todos los objetos).

Esto aun te podria valer para si quieres testear colisiones contra poligonos individuales. Pues puedes tratar el traceline que toca un objeto como una posible colision, y utilizar un traceline que teste los poligonos de ese objeto contra un nuevo traceline que cruce el volumen de colision del objeto. (esto es mas facil de dibujar que de decir ).

La forma mas sarnosa y lamentable de hacer esta clase de cosas es no hacerla en absoluto. Si por ejemplo tengo un juego de tanques, que se desplazan por un heighfield. Hago que el traceline compare la altura del heighfield con la del punto testeado. En el momento que toco tierra o estoy debajo de ella, chequeo el origen de los objetos y si uno esta a una distancia menor que X. Queda seleccionado o disparado o lo que sea.

[kuo]

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

[Mars Attacks]

FPS: First Person Shooter. Un juego de disparar en primera persona (doom, quake, tetris...)