[Larrabee rules]

Larrabee rules. ¡Y que cada uno se programe su propia API! :D

PD: Ahora pa' que sea un fracaso... :D

[Ron Fedkiw]

Ron Fedkiw y Jos Stam son buenas referencias en el campo de CFD.

Ron Fedkiw tiene un montón de papers sobre el tema  y Jos Stam tiene un buen paper sobre simulación de fluídos en video-juegos.

En ninguno de los casos utilizan SPH.

También tienes el capítulo de las GPU Gems, Fast Fluid Dynamics Simulation on the GPU.

En cualquiera de lo casos es necesaria una buena dosis de conocimientos en cálculo diferencial e integral. :lol:

Saludos.

Por cierto no son 3 matrices? La de perspectiva no se como se llama.

La perspectiva es un tipo de proyección, o sea que hablamos de la misma matriz.

Saludos.

[aquí]

Hola.

Código [Seleccionar] Expand

/* projection du point (objx,objy,obz) sur l'ecran (winx,winy,winz) */
GLint gluProject(GLdouble objx, GLdouble objy, GLdouble objz,
          const GLdouble model[16], const GLdouble proj[16],
          const GLint viewport[4],
          GLdouble * winx, GLdouble * winy, GLdouble * winz)
{
 /* matrice de transformation */
 GLdouble in[4], out[4];

 /* initilise la matrice et le vecteur a transformer */
 in[0] = objx;
 in[1] = objy;
 in[2] = objz;
 in[3] = 1.0;
 transform_point(out, model, in);
 transform_point(in, proj, out);

 /* d'ou le resultat normalise entre -1 et 1 */
 if (in[3] == 0.0)
   return GL_FALSE;

 in[0] /= in[3];
 in[1] /= in[3];
 in[2] /= in[3];

 /* en coordonnees ecran */
 *winx = viewport[0] + (1 + in[0]) * viewport[2] / 2;
 *winy = viewport[1] + (1 + in[1]) * viewport[3] / 2;
 /* entre 0 et 1 suivant z */
 *winz = (1 + in[2]) / 2;
 return GL_TRUE;
}

Código [Seleccionar] Expand

/*
* Transform a point (column vector) by a 4x4 matrix.  I.e.  out = m * in
* Input:  m - the 4x4 matrix
*         in - the 4x1 vector
* Output: out - the resulting 4x1 vector.
*/
static void transform_point(GLdouble out[4], const GLdouble m[16], const GLdouble in[4])
{
#define M(row,col) m[col*4+row]
 out[0] = M(0,0) * in[0] + M(0,1) * in[1] + M(0,2) * in[2] + M(0,3) * in[3];
 out[1] = M(1,0) * in[0] + M(1,1) * in[1] + M(1,2) * in[2] + M(1,3) * in[3];
 out[2] = M(2,0) * in[0] + M(2,1) * in[1] + M(2,2) * in[2] + M(2,3) * in[3];
 out[3] = M(3,0) * in[0] + M(3,1) * in[1] + M(3,2) * in[2] + M(3,3) * in[3];
#undef M
}

Sacado de aquí.

Saludos.

Una vez creada la matriz de vista con D3DXMatrixLookAtLH (internamente genera los vectores right, up y look), puedes extraer los mismos a través de la propia matriz generada.

Corresponden a las columnas 1ª, 2ª y 3ª, respectivamente.

Saludos.

[Hartman y Gribb]

¿Has probado con el documento de Hartman y Gribb?

Aunque la implementación que tienes se parece a la que describe en el paper, por lo que es posible que sí lo hayas leído.

Saludos.

De todos modos un BMP tiene compresión RLE. Asi que un BMP ocupara menos que una imagen "descomprimida".

Pero en memoria de video se almacena descomprimida (que creo que es la duda que tiene sms) salvo que se comprima en algún formato S3TC en tiempo de carga.

Saludos.

[S3TC]

Si no comprimes la textura en algún formato S3TC (y el hardware lo soporta), el tamaño será el mismo que la textura sin comprimir.

Saludos.

Yo tal como veo las cosas ahora, tampoco la dejaría. Pero bueno, eso también va a depender de a qué te quieras dedicar exactamente y el nivel que quieras alcanzar.

Yo personalmente me arrepiento de no haber hecho más hincapié en matemáticas (sobre todo en cálculo) y en física. Mi nivel académico es el de COU, que es lo esencial para la programación gráfica 3D, tanto a nivel matemático como físico. Sí es cierto que he hecho avances por mi cuenta a través de libros, pero cuando llega la hora de crear simulaciones más complejas como por ejemplo utilizar las ecuaciones de Navier-Stokes para simulación de fluidos, o simular la dispersión de la luz en la atmósfera, echo mucho de menos un mayor conocimiento en matemáticas y física. Que sí, que puedes coger el código del famoso solver de Jos Stam y el shader de no se quién para el render de la atmósfera, pero a mí lo que me interesa es entender lo que hago para después poder mejorarlo, optimizarlo o lo que sea.

Sí es cierto que intento paliar eso con libros pero sinceramente, es complicado y además tampoco puedo dedicarle todo el tiempo que sería necesario (temas de trabajo, jejej). Además, me imagino que siempre es mejor tener a alguien que sepa del tema y te explique in situ.

Saludos.

Enhorabuena, siempre da gusto ver que alguien hace uso de las creaciones de uno. :)

PD: juas, idiot software... :lol:

[Fast Extraction of Viewing Frustum Planes from the World-View-Projection Matrix]

Creo que el documento al que se refiere senior wapo es

Fast Extraction of Viewing Frustum Planes from the World-View-Projection Matrix

de Gil Gribb y Klaus Hartmann.

El sistema del que habla es el que utilizamos nosotros en Haddd/Jade.

Saludos.

[Aquí]

Yann Lombard mencionó hace tiempo un método que parece ser muy rápido. Aquí tienes el hilo, más abajo pone el código.

Yo no lo he probado así que no sé cuán eficiente será, pero si Yann lo dice... :lol:

Saludos.

¿Con que no funciona quieres decir que el programa da un error al ejecutarlo o que la imagen parpadea?. Si es lo último, prueba a sobrecargar el método OnEraseBkgnd de la vista y haz que devuelva FALSE.

Sólo es una idea, la verdad es que mis tiempos de OpenGL pasaron hace muchos años. :P

Saludos.

[link]

la verdad es que el efecto que necesito es oscurecer el jugador ( por ejemplo)  cuando  pase por una sombra.

Sigues teniendo la opción 3D que mencioné (grid o textura) y además tendrías la opción de precalcular los shadow volumes de la geometría estática y posteriormente utilizarlos al renderizar tus objetos dinámicos (Doom III también precalcula muchos shadow volumes de los mapas, aunque en este caso no sólo los utiliza para proyectar sombras sobre los objetos dinámicos sino también sobre el propio escenario). También tienes la opción de precalcular los "depth shadow maps" y posteriormente proyectar sobre los objetos dinámicos.

En realidad proyecta texturas para mantener compatibilidad con placas viejas donde no hay shaders

Sí, efectivamente utiliza un método similar al que se describe en el link que puse más arriba (el de Ron Frazier). Es curioso que incluso en "ET:QW" siguen utilizando ese sistema. Efectivamente si fisgoneas en la carpeta de recursos, hay una carpeta de luces en la que puedes ver una textura 2D para la atenuación en XY y otra 1D con la atenuación en Z.

De doom 3 pasa que no usa lightmaps para nada.

Sí, es cierto, toda la iluminación es dinámica pero por lo que he podio ver (y ciertamente no estoy seguro al 100%), creo que el diffuse se consigue con proyección de texturas (no se hace el NdotL, por lo que he podido ver en el "uber-shader" que viene con Doom III), aunque el specular sí se calcula utilizando Blinn-Phong. De ahí que comentara lo de que la proyección de texturas es una opción. Pero vamos, como digo no pongo la mano en el fuego... :P

Saludos.