Gracias, encontré la solución en la página que pusiste, Warchief. La función que necesitaba es exactamente gluUnProject, que desconocía.

A esta función se le pasa la posición del cursor y la distancia z que buscamos, el viewport y las matrices de transformación, y te devuelve las coordenadas en 3D. De manera que con 2 llamadas con diferentes distancias obtenemos un rayo que "sale" del cursor a la escena, y con él se puede determinar su intersección con cualquier plano y por tanto el punto exacto de colisión que buscaba.

ahora lo que he intentado hacer es mi propia función gluUnproject conociendo la fórmula.

To compute the coordinates (objX, objY, and objZ),
     gluUnProject multiplies the normalized device   coordinates by
     the inverse of model*proj as follows:

http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/glu/unproject.html

multiplico la matriz modelview por la de projection, la matriz resultante la invierto. y multiplico el punto 2D de la ventana normalizado por esa matriz.

Es así ¿no?
Pues no funciona :roll:

Bueno, da igual, ya lo resolveré, lo que quería ya lo he encontrado.

Puedes mirar en motores de código abierto. Por ejemplo en Irrlicht (version 3demon):

Código [Seleccionar] Expand


getScreenCoordinatesFrom3DPosition( const core::vector3df& pos3d, ICameraSceneNode* camera )
{
core::vector2di pos2d(-1000,-1000);

 // ...

core::vector2di dim = Driver->getScreenSize();
dim.X /= 2;
dim.Y /= 2;

f32 transformedPos[4];

core::matrix4 trans = camera->getProjectionMatrix();
trans *= camera->getViewMatrix();

transformedPos[0] = pos3d.X;
transformedPos[1] = pos3d.Y;
transformedPos[2] = pos3d.Z;
transformedPos[3] = 1.0f;

trans.multiplyWith1x4Matrix(transformedPos);

if(transformedPos[3] < 0)
return core::vector2di(-10000,-10000);

f32 zDiv = transformedPos[3] == 0.0f ? 1.0f :
(1.0f / transformedPos[3]);

pos2d.X = (s32)(dim.X * transformedPos[0] * zDiv) + dim.X;
pos2d.Y = ((s32)(dim.Y - (dim.Y * (transformedPos[1] * zDiv))));

return pos2d;
}


Será cuestión de adaptarlo a las funciones que tengas en tu motor o API.

Quiero hacer eso pero al revés. Creo que se aproxima más a lo que haría un trazador de rayos, es decir, que conozco la posición 2D, la proyección y vista de la cámara, y quiero saber a qué posición 3D corresponde. Con la ventaja de que el lugar de colisión no es un objeto, sino una superficie plana y recta con respecto al origen de coordenadas e infinita.

Pensaba que iba a ser más sencillo y que lo sabría alguien, una simple fórmula.

Es que la gente es mu floja... muy muy floja Razz no pide links ni algo para estudiar no... piden ya el código para copiar, pegar y adaptar.

?

¿no estarás seleccionando una textura o activando estados entre cada dibujado de polígono?

es que no quiero usar el modo de render de selección de opengl, porque es que no lo necesito, y además no sería lo más eficaz.

Quiero poder seleccionar la celda correspondiente en la típica matriz de celdas iguales. Que en 2D sería muy fácil, pero en 3D se complica un poco porque depende de la posición y la orientación de la cámara, de la proyección y el viewport.

Todavía no lo he intentado hacer, pero es que como no lo tengo nada claro quería saber si alguien que esté puesto en el tema tenía alguna idea.

Busca en google "picking 3d" y cosas así. Por cierto, como fue lo de los impostores?

sigue pendiente  :(


lo otro a ser posible no querría usar el gluPickMatrix

quiero saber en qué lugar de la superficie, se proyecta un supuesto rayo que sale de una posición en 2D (del cursor del ratón).

La idea es hacer una función a la que supongo tendré que pasar la matriz de vista, la de proyección, el viewport y la posición del cursor. Y me devuelva la coordenada 3D donde hace el picking.

Como el lugar de "colisión" del rayo un plano recto en la altura cero, pues basta con que me devuelva la coordenada X/Z de la superficie del suelo sobre la que estoy "pasando" el cursor.

¿alguien sabría la fórmula?, imagino que es el proceso inverso al de pasar la coordenada 3D a 2D en la pantalla, pero ando un poco liado y no quiero perder demasiado tiempo dando palos de ciego, si alguien lo supiera pues estupendo, mientras seguiré indagando.

¿Has probado a salsear con el orden de la multiplicación de las matrices? Se supone que coges el quad del impostor, lo escalas al tamaño que quieras y luego lo orientas con la matriz "billboard" de la camara, es decir, la inversa de la matriz de vista de la camara con 0 de traslación. Vamos, este es el orden de multiplicación que toca.

Supuestamente hago eso, aunque atajo, multiplico la matriz del impostor ya escalada por la matriz de la cámara en lugar de invertir la vista (que sería la misma).

A lo mejor puede ser primero multiplicar por la vista y luego escalar.

Haré diferentes pruebas a ver...

Sí, hago lo de multiplicar por la inversa de la vista poniendo a cero la traslación, sino cambiaría de posición.

El caso es que el objeto en cuestión debe de ser la matriz de identidad, es decir que no se puede modificar su escala lo más mínimo, entonces falla.

Supongo que la solución como dices, pasa por guardar el escalado, poner la orientación/escalado de "identidad", o como se diga. Y luego aplicar el escalado de alguna manera.

Miraré a ver si se puede hacer multiplicando de nuevo por una matriz que contenga la orientacion/escalado del billboard. aunque por lo que he visto, las solución rápida no pasa por ahí, y me temo que tendré que usar otra técnica.

http://www.lighthouse3d.com/opengl/billboarding/

pues no sé en qué falla, porque en principio parece que funciona bien, pero basta por ejemplo con escalar el ancho por dos, para que se produzcan deformaciones que estiran el rectángulo en algunas esquinas a medida que roto la cámara sobre él.

Para orientar un impostor (sprite 3d) a la cámara, basta con multiplicarlo por la inversa de la matriz de vista. Sin embargo al escalar o rotar la matriz del impostor, ya no funciona correctamente. Los vectores de rotación y de escalado siempre deben ser los de la matriz de identidad.

¿Hay alguna solución recomendable?, ¿o mejor cambiar el sistema y hacerlo como se indica aquí?
http://www.fuzzygamedev.com/2007/03/24/billboards/3/

Vale, parece que me va a tocar estudiar.

En principio es un cubo orientado con los ejes y con el mismo ancho-alto-largo.

Es decir, que más o menos con esta función me bastaría, conociendo la posicion/orientacion/frustum/view de la cámara que podría ir en una matriz y sabiendo la posición y el tamaño del cubo.

Código [Seleccionar] Expand

bool EsVisible( MATRIX matCam, POINT Pos, float Tam)

{
    // es visible o no
}

Si existe por ahí esta función o una parecida, o alguien la tiene hecha, me permitiría reservar energías para otros quebraderos de cabeza que tengo pendientes.

si no... pues a joderme y a hacerlo toca.

Pues parece que no ha puesto el código, sino el pseudo.

Me va a tocar traducirlo, entenderlo, devanarlo, adaptarlo, y codificarlo como no encuentre algo mejor, algo ya hecho  :cry:

Esperemos que valga la pena, mientras si alguien sabe donde hay una función que le pueda hacer un copy/paste directamente pues mejor.


pd: acabo de ver tu mensaje senior, voy a leerlo.

Si no vas a modificar la textura, puedes eliminar tu copia (la 1), así liberas RAM.

Las pruebas:

Apple añadió una extensión para poder mantener la copia del usuario como copia de memoria de sistema manejada por OpenGL, para así ahorrarse el duplicado http://www.opengl.org/registry/specs/APPLE/client_storage.txt (En el "Overview" está explicado muy claro). El problema es que esta estensión no es muy común en windows, al menos mis drivers ATI no la soportan.

saludos!

sigo sin verlo claro y de todos modos dice que "algunas implementaciones mantiene la copia normalmente" pero no dice que siempre.

A lo mejor eso sucedía cuando la memoria VRAM era muy excasa y no existía el puerto AGP. Donde podías tener 8 MB de VRAM + 128 de RAM y las trasferencias PCI eran muy lentas. Entonces sí tiene sentido mantener la copia.

Pero actualmente algunos ordenadores pueden llegar a tener incluso más memoria residente VRAM + AGP que memoria de sistema libre, por lo que tener un duplicado de todas las texturas penalizaría los recursos gravemente.

Es probable que las implementaciones hayan evolucionado de manera que  las texturas más usadas permanecen en VRAM o AGP (que en la actualidad puede llegar hasta los 512 MB), y sean eliminadas de la memoria de sistema, y algunas texturas que no tienen preferencia y están siendo habitualmente subidas sí se conserven en la memoria de sistema.

No estoy seguro de todo esto, pero yo a ti si te veo muy seguro y a lo mejor tendrías asegurarte de cual es el mecanismo real de las actuales implementaciones de OpenGL en cuanto al mantenimiento de texturas porque lo de mantener por duplicado todas las texturas no lo acabo de ver claro.

Tal vez tendrías que chequear la memoria para saber qué está pasando realmente, el "Video Memory Watcher" está bien para verlo en tiempo real.

[mueve]

Lo que hace OpenGL es una copia en memoria de sistema (2), y luego una copia en VRAM cuando se necesita (3), descargandola cuando no. Funciona como dices, excepto que no "mueve" la textura a VRAM, sino que copia la textura a VRAM cuando es necesario. Esto significa que la copia interna de OpenGL en memoria de sistema (la 2) siempre está ahí. Este comportamiento es igual que cuando se crea una textura en DX con D3DPOOL_MANAGED.

Creo que si no me muestras una fuente fiable que explique que eso ocurre así, no me voy a poder creer nunca que Las texturas se guarden por duplicado. Es ilógico e innecesario ese gasto de memoria.