se hace con SetUnhandledExceptionFilter

 Todo el mundo tiene una tarjeta 3D hoy en dia, yo usaria Direct3D9 o OpenGL. En ambos puedes usar una proyeccion ortográfica. En OpenGL de hecho puedes usar point sprites.

 Los nombres decorados los puedes obtener en el VC usando la opción de crear archivo map.

 Joer, cuanto tiempo, que recuerdos.

Yo creo que lo que mató tu colaboración en el Glest fue la distancia, porque no es lo mismo sin verse las jetas todas las semanas ;), porque por aquel entonces andabamos un poco verdes todos, aunque prometíamos :).

Saludos!

 

Te pondé un ejemplo sencillo. Una persona corre 5 km todos los días y otra corre1 km todos los días. A la hora de correr un maratón quien crees que estará mejor preparado? Aplica este ejemplo a la vida de estudiante. Estudiar una carrera no es una tarea nada fácil, requiere muchísimo esfuerzo y dedicación a diario, e suna verdadera carrera de obstaculos. Es muy lógico que alguien que termine una carrera tenga una capacidad mayor que alguien que no la haya hecho.

Estoy radicalmente de acuerdo. (despues de matarme 6 años no iba a decir que no han valido de nada ;) ).

 

openGL r00lz tongue.gif

(lo siento, no he podido evitarlo)

Totalmente de acuerdo, pero ojala hubiese una documentacion de OpenGL la mitad de buena que la del SDK de DX.

 

Quizás esto no venga al caso, pero ...¿qué tipo de animación utilizais para el juego ? ¿bones, keyframe?

Estabamos pensando en hacer skinning, para animar el piloto de la misma forma, pero aun lo estamos pensando (usando bones rigidos se podria animar casi todo), de momento estamos haciendo pruebas para los materiales.

El morphing es lo que usabamos en el Glest, y barajamos el reutilizarlo, pero esto nos limitaria mucho la parte dinamica del juego, ya que no se podria poner nada parecedo a una fisica decente.

 Hola,

Los calculos de luz hay que hacerlos siempre con los vectores en el mismo espacio. En el shader que pones ahí las posiciones de los vértices estan en espacio del objeto (porque no los has multiplicado por la matriz de vista), y me temo que la posicion de la luz esta en el espacio de vista (porque uno intuitivamente suele colocar las luces con respecto al origen de coordenadas, no con respecto a los objetos que iluminan).

Si este es el problema, la solucion rápida de hacer es pasar los vectores al espacio de vista, que en el caso de los vertices se haría multiplicando por la matriz de vista (en el shader), y en el caso de las normales por la inversa (en el shader). Sin embargo con esto estas realizando muchas transformaciones innecesarias, porque esto equivalería a pasar la luz al espacio del objeto, multiplicando por la matriz de vista inversa una sola vez para cada objeto (en la CPU).

Por ejemplo, si el objeto (sin rotar) tiene como centro la posicion (0, 1, 0) y la luz esta en (0, 5, 0), la posicion de luz que has de pasar sería (0, 4, 0).

Saludos.

 Hehe, gracias por los comentarios, al principio me daba un poco mal rollo publicarlo, porque ahora estoy expuesto a cualquier tipo de críticas sobre mi forma de programar, pero creo que al final será positivo.

Saludos.

 

martiño: Ya observer ese problema cuando empecé.....como no tenia mucha idea creia q la funcion que definia que trozo de la textura tenia q dibujar lo haia mal........incluso recree el archivo grafico por si estaba mal......me pase por el irc y me dijeron lo mismo que tu, que el filtro bilinear me estaba dando los fallos.....lo solucione poniendo este filtro (la verdad no entiendo mucho la diferencia, pero si funciona pues funciona xDD):
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);

El filtro GL_NEAREST es muy cutre, simplemente pone el pixel del color del texel mas cercano, si tienes una textura de mucha resolucion no se va a notar, pero si tienes una textura de tamaño normal se vará el poligono a cuadraditos, como en los primeros juegos 3D.

Los filtros que se usan habitualmente (en los juegos comerciales) son:

El bilineal:

         glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_NEAREST);
         glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);

El trilineal:

         glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR;
         glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);

Estos dos filtros usan mipmaping, con lo que tienes que especificar los mipmaps para cada textura. La forma mas facil es con gluBuild2DMipmaps.

 Hola,

Solo queria llamar la atencion un problema bastante grave que tienen los mosaicos de tiles, que es el filtrado de texturas en los bordes de los mismos.

Cuando se usa filtrado bilineal para determinar el color de un pixel de usan los texels adyacentes de los niveles de mipmap correspondiantes, y las texturas de tiles se van a mezclar. Es decir si tienes un tile de tierra al lado de uno de hierba cuando tengas una celda de hierba que este a lo lejos, el los bordes con toda seguridad vas a ver unos cuantos pixeles del color de la tierra.

Quizas pueda solucionarse proporcionando mipmaps filtrados manualmente que no mezclen los tiles y dejando un borde entra tile y tile, pero no es un tema trivial.

Saludos.

 Pues gracias, era lo de multiplicar por 100 lo que me fallaba porque ya habia visto esos metodos y los habia probado, pero como no me daban el mismo valor en el editor de materiales pensé que no eran.

 Hola,

Como puedo expotar el specular level o la glossiness de un material standard en el sdk del 3dsmax? porque las clases StdMat o Mtl no tienen métodos para recuperar estas propiedades.... De hecho no tienen metodos para recuperar ni la décima parte de las propiedades que hay en un material estandar, solo las muy basicas.

 Creo que una razón importante para usar OpenGL y no DX, cuando lo que quieres es aprender, es que DX en cada versión se tira a la basura y se rehace de nuevo (esto da una idea de lo bien diseñada que esta el API).

Así que si tienes código en DX8 y quieres utilizar alguna capacidad que se incorporó en DX9, tienes que portar todo a DX9 (y a DX10 cuando salga, etc...). En OpenGL el código es compatible hacia atras, OpenGL 2.0 por ejemplo añade nuevas funciones, pero las antiguas siguen funcionando igual.

Hoy en día las tarjetas ATI+Nvidia suman el 90% del mercado y soportan OpenGL perfectamente, asi que lo de que con DX llegas a mas gente no creo que sea una razón.

A mi el API de OpenGL me parece mucho mas elegante y cómoda (yo no diria mas fácil, diria menos latosa), el único problema que le veo es la falta de una documentación de referencia seria, cosa que DX si que tiene.

 He estado mirando un poco mas la IGame y:

- El problema de la malla consolidada sigue ahí, lo que dije hasta ahora es todo falso. Porque aunque hay una lista unificada de caras, ese no era el problema, el problema es que los indices para los vertices, las coordenadas de textura y las normales no son iguales y hay que hacer todo a mano.

- Ademas no he visto que se pueda pillar la malla en un instante concreto de tiempo, por lo que si se quieres exportar una malla para vertex morphing (del estilo MD2 o MD3), creo que no se puede hacer (si alguien sabe como que me lo diga).

Saludos. Martiño.