Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





Menu

Mostrar Mensajes

Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menu

Mensajes - ZüNdFoLGe

#1
Es una buena idea, el proyecto tiene que ser para PC, asi que sería cuestión de usar un kinect-pc.

Me gusta la idea, la tendría que pulir un poco, y debería elegir un engine 3D que permita extenderlo para agregarle estas características. Se me ocurre Ogre3D, que opinas???? a pesar de que nunca lo he usado, el que sí usé fue Torque3D pero me parece que no ofrece mucha libertad como para extender "el protocolo de entrada" (almenos cuando lo usé nunca se me ocurrió modificar nada).

Gracias XÑA por el aporte, cualquier otra sugerencia es bienvenida.
#2
Buenas, hace mucho tiempo no escribo en el foro, pero he vuelto...

esta vez consulto por ideas para el proyecto de grado, por el momento me propusieron tomar un motor 3D FREE ya existente (por ejemplo OGRE3D) y extenderlo con "algo" que no exista aún.

Es decir, agregarle una nueva capacidad y luego hacer una aplicación/juego que utilice esa nueva capacidad.

Qué podría ser? Se me ocurre incluir el uso de GPS por ejemplo, pero no se aún. En cuanto al motor debería ser uno que permita extenderse y modificarlo.

IDEAS ????

Gracias!!!
#3
Programación gráfica / Manejo de escena con Octree o Quadtree
30 de Noviembre de 2010, 12:35:38 PM
Hola, estoy un poco liado con este tema.

He decidido usar una estructura para el manejo de escena, tal como octree o quadtree (he descartado BSP por tema de simplicidad). Entiendo el concepto detras de esto, pero no lo he podido llevar a codigo.

Actualmente en el renderer lo que hago es renderizar cada componente de la escena invocando a su renderer concreto, es decir para cada objeto invoco un metodo render() donde renderizo el conjunto de triangulos correspondiente. Idem para el terreno (aplicando LOD, pero en definitiva se renderiza de manera similar a los objetos).

Como se supone que debo "particionar" estos conjuntos de triangulos para poder renderizar un subconjunto de ellos, dependiendo de donde este ubicada la camara?

Agradezco si alguien me puede aclarar esto, o si tienen algun link con algun ejemplo sencillo de entender.

Gracias de antemano
#4
General Programadores / Versionando en visual studio
16 de Octubre de 2010, 04:29:52 PM
Acabo de echarle un vistazo al plugin de TortoiseSVN para visual studio y parece estar muy bueno, por ahora me decanto a usarlo.

Que utilizas para manejo de versiones en Visual Studio?

Tal vez me pierda de algo mejor.

Gracias de antemano por las recomendaciones/comentarios.
#5
Programación gráfica / De OpenGL a DirectX
15 de Octubre de 2010, 04:18:01 PM
Hola,

hasta ahora he estado siempre con OpenGL y voy a probar un poco de DirectX.

Para los que estuvieron en esta situacion, en que cosas notaste "mayor diferencia" entre OpenGL/DirectX?

No pretendo discutir OpenGL vs DirectX, solo que voy a empezar a usar DirectX y me gustaria saber a modo general en que cosas se nota mayor diferencia para uno que viene trabajando con OpenGL.

Gracias de antemano por vuestros comentarios.
#6
Programación gráfica / Re: Intersectando rayo con Cilindro
15 de Junio de 2010, 05:50:16 AM
Finalmente he podido renderizar el cilindro, me he bajado el codigo del POV-ray para fijarme como intersecta el rayo con las cuadricas y de ahi adaptarlo a lo que ya tenia. Aqui va la imagen, por defecto el observador esta en el punto (0, 0, 0):



Ahora estoy con un nuevo problemita, y es que cuando muevo la camara la direccion del rayo no esta saliendo de "el ojo del observador", a pesar de que a mi entender estoy actualizando bien la direccion a medida que muevo la camara. Asi es como se ve la imagen cuando coloco al observador en el punto (-400, 0, 0):



Asi es como estoy seteando a la direccion del rayo y la del observador:


    for(int y = 0; y < IMAGE_Y; y++) {
        for(int x = 0; x < IMAGE_X; x++) {
               
            position observador,  direccion;

            observador.x = -400;
            observador.y = 0;
            observador.z = 0;

            direccion.x = (WINDOWS_X/IMAGE_X)*x - WINDOWS_X/2;
    direccion.y = (WINDOWS_Y/IMAGE_Y)*y - WINDOWS_Y/2;
           
            direccion.z = WINDOWS_Z;

     color col = traza_RayTracing(observador, direccion, 1,-1,objects,lights,count,countLights);


Aparentemente viendo como queda la imagen que les mostre (que la esfera queda como un huevo, como si fuera un elipsoide) cuando yo cambio la posicion del observador (lo que hago es cambiar observador.x, observador.y) la direccion del rayo sigue partiendo del 0, 0, 0... creo que ese es el unico motivo para que las imagenes se vean "ahuevadas" como muestra la figura.

Si pruebo restar direccion - observador para obtener la direccion "actualizada" no logro ver los objetos, la imagen se va de foco. Evidentemente algo estoy haciendo mal. Si alguien detecta que estoy cometiendo algun error en el calculo de la direccion en el codigo que adjunte agradezco una mano.

Gracias de antemano,
#7
Programación gráfica / Re: Intersectando rayo con Cilindro
11 de Junio de 2010, 04:15:03 AM
Primero que nada muchas gracias a ambos por las respuestas. Saque provecho de ambas y he avanzado, aunque todavia no se logra ver bien el cilindro.

De acuerdo al articulo en amazon que ha mencionado nostromo, el codigo lo tengo exactamente igual, excepto que el algoritmo de amazon multiplica por una matriz que representa  una transformacion inversa, la cual desconozco como esta compuesta. Esto lo hace antes de realizar los calculos:



Matrix4x4 transform, invTransform;
transform = cylinder.getTransformMatrix();
invTransform = transform.Inverse();
rayAuxiliar.direction = ray.direction * invTransform;
rayAuxiliar.origin = ray.origin * invTransform;



Seguramente mi error sea conceptual y precisamente este en esa parte de la transformacion de coordenadas, porque el resto del codigo esta igual que en el algoritmo antedicho.


Este es mi codigo:

int Cylinder::Intersect( Ray& a_Ray, float& a_Dist )
{

// origen del rayo, yo para "trasladarlo" al sist. de coord. del cilindro (que es donde posiciono al cilindro) le resto el centro del cilindro,
       //el centro es el punto (0, 0, 0), y obviamente la operacion no surte ningun efecto.
       // Aqui debe ser donde tengo el error pero no me doy cuenta cual es la transformacion que debo aplicarle al origen del rayo

       vector3 posRay = a_Ray.GetOrigin() - m_Centre;

// dir rayo, a la direccion del rayo no le estoy aplicando ninguna transformacion, la dejo como esta, pero sospecho que esto esta mal

vector3 dirRay = a_Ray.GetDirection();

       // de aqui para abajo esta todo igual al algoritmo de amazon que menciono nostromo

int retval = MISS;
float a = dirRay.x * dirRay.x + dirRay.z * dirRay.z;

float b =  (posRay.x * dirRay.x +
posRay.z * dirRay.z);

float c = (posRay.x * posRay.x) +
(posRay.z * posRay.z)  - 1;

float det = b*b - a*c;

if (a > EPSILON  &&  det >= EPSILON) {
float d = sqrt(det);
float i1 = (-b - d)/a;
float i2 = (-b + d)/a;

vector3 t0 = a_Ray.GetOrigin() + i1 * a_Ray.GetDirection();
// no valido
if (t0.y < EPSILON || t0.y > m_height) {
valid[0] = false;

} else {
valid[0] = true;
}

vector3 t1 = a_Ray.GetOrigin() + i2 * a_Ray.GetDirection();
if (t1.y < EPSILON || t1.y > m_height) {
valid[1] = false;
} else {
valid[1] = true;
}

num[0] = i1;
num[1] = i2;
float minor;
if (valid[0] && valid[1]) minor = getMinValue(num[0], num[1]);
else {
for(int i=0; i<2; i++) {
if (valid[i]) minor = num[i];
}
}

if (minor < a_Dist) {
retval = HIT;
a_Dist = minor;
}
}

return retval;
}


El cilindro lo estoy dibujando con estos datos:
Radio = 1
Centro = (0, 0, 0)
Altura (h) = 6

Aun sigo luchando y estoy leyendo este articulo de Juan Mellado http://www.inmensia.com/articulos/raytracing/interseccion.html?pag=2 , pero he estado muchas horas con esto y seguramente mi error sea conceptual.
#8
Programación gráfica / Intersectando rayo con Cilindro
10 de Junio de 2010, 04:51:00 AM
Estoy tratando de implementar un raytracer, por ahora iba bastante bien hasta que me choque con el cilindro (hasta ahora llevo bien las demas primitivas: plano, esfera, cubo, triangulo).

El problema es que no doy pie con bola para que se vea el cilindro en pantalla (que se vea bien), con el codigo que muestro a continuacion el cilindro se ve punteado, sin color y con la sombra mal calculada (todos estos rollos son consecuencia de que hay un fallo en el calculo de la interseccion entre rayo y cilindro, que es con lo que estoy liado) . Tambien se esta renderizando como cilindro infinito (sin tapas) y en realidad lo estoy acotando (o lo estoy haciendo mal).

Me he guiado de este  tutorial (hasta ahora me ha sido muy util), cuyo autor creo que merodea estos foros (Juan Mellado):
http://www.inmensia.com/articulos/raytracing/cilindroycono.html?pag=1

Se que puede resultar bastante tedioso ponerse a ver un codigo de raytracing, pero si alguien por casualidad lo mira y puede echar una luz estare agradecido.

De la misma forma si alguien sabe de algun link con algun ejemplo sobre  interseccion entre rayo y cilindro se agradece que lo comparta (a pesar que ya he visto varios ejemplos y sigo sin dar pie con bola).


int Cylinder::IntersectRay( Ray& a_Ray,  float& a_Dist )
{
int retval = MISS;

float a = a_Ray.GetDirection().x * a_Ray.GetDirection().x + a_Ray.GetDirection().z * a_Ray.GetDirection().z;

float b = 2 * (a_Ray.GetOrigin().x * a_Ray.GetDirection().x + a_Ray.GetOrigin().z * a_Ray.GetDirection().z);

float c = (a_Ray.GetOrigin().x * a_Ray.GetOrigin().x) + ((a_Ray.GetOrigin().z * a_Ray.GetOrigin().z) ) - m_SqRadius;

        // calculo el determinante
float det = b*b - 4*a*c;

       
if (a != 0  &&  det >= 0) {  // si hay puntos de corte los calculo

float i1 = (-b - sqrtf(det))/(2*a);
float i2 = (-b + sqrtf(det))/(2*a);

if (det == 0) {
a_Dist = i1;
return HIT;
}

if (i1<0 && i2<0) return MISS;

                // obtengo el menor (positivo) de entre los 2 valores
float minor = getMinor2F(i1, i2);

// llamo "I" al punto de interseccion, calculo sus componentes a partir de la ecuacion del rayo
vector3 I = vector3(a_Ray.GetOrigin().x + minor* a_Ray.GetDirection().x,
a_Ray.GetOrigin().y + minor* a_Ray.GetDirection().y,
a_Ray.GetOrigin().z + minor* a_Ray.GetDirection().z
                   );

if (minor < a_Dist) {
// verifico las intersecciones en las "tapas" del cilindro
if ((I.x * I.x + I.z * I.z) <= 1 && (I.x * I.x + I.z * I.z) >= 0) {
a_Dist = minor;
retval = HIT;
}

}
}

return retval;
}
#9
Finalmente me decanté por usar una implementación casera que he visto en los foros de gamedev, lo modifiqué a mis necesidades, en un principio había estado probando el 3dslib pero la documentación la verdad me pareció demasiado escasa, no quise caminar sobre lo obscuro.

Por otro lado he estado analizando el cargador de modelos milkhsape3d (ms3d) en la web de NEHE, pero también lo descarté, necesitaba un formato más "portable", como lo es OBJ.

Qué cargador suelen usar en sus juegos? Por qué usas ese en particular?

Gracias de antemano


#10
joder estaba trabajando a mano vertice a vertice era imposible poder asociar las texturas asi....

acabo de ver que el formato de la descripción de cada vértice del conjunto de polígonos que compone el modelo esta compuesto por las componentes de v1/vt1/vn1, y con ello sé la posición del vértice, las coordenadas de la textura y la ubicación de la normal

Gracias hombre
#11
He implementado mi propio cargador de modelos .obj  y  hasta ahora va todo sobre ruedas, excepto al mapear una textura al modelo.

Para expresar mi duda presento el siguiente ejemplo:    cargar un prisma y aplicar al mismo una textura (ver JPG). La textura la hice al vuelo en paint asique no se pongan detallistas... :P




en la especificacion del modelo (.obj) el prisma podemos verlo asi (es el mismo del jpg):

v -24.000000 7.838379 10.793568
v -24.000000 1.911621 10.793568
v -18.500000 7.838379 10.793568
v -18.500000 1.911621 10.793568
v -18.500000 7.838379 -16.793570
v -18.500000 1.911621 -16.793570
v -24.000000 7.838379 -16.793570
v -24.000000 1.911621 -16.793570
# 8 vertices

vt 0.000000 1.000000
vt 0.000000 0.000000
vt 1.000000 1.000000
vt 1.000000 0.000000
# 4 texture coordinates

vn 0.000000 0.000000 1.000000
vn 1.000000 0.000000 0.000000
vn 0.000000 0.000000 -1.000000
vn -1.000000 0.000000 0.000000
vn 0.000000 1.000000 0.000000
vn 0.000000 -1.000000 0.000000
# 6 normals


Ahora  en la funcion de renderizado, yo dibujo el modelo triangulo a triangulo, tomando los vertices correspondientes. Por este motivo me surge la duda de como mapear la textura "al conjunto de triangulos que compone el modelo".

Esto lo hago asi:


glBegin(GL_TRIANGLES);
for(int i = 1; i < TriangleCount; i++) // for each face
{
glTexCoord2f(0.f,0.f);  // A LO BESTIA PARA VER LA TEXTURA
glNormal3f(Verticies[Triangles[i].v1].Normal.x, Verticies[Triangles[i].v1].Normal.y, Verticies[Triangles[i].v1].Normal.z);
glVertex3f(Verticies[Triangles[i].v1].Pos.x, Verticies[Triangles[i].v1].Pos.y, Verticies[Triangles[i].v1].Pos.z);
           
glTexCoord2f(0.f,1.f);  // A LO BESTIA PARA VER LA TEXTURA
glNormal3f(Verticies[Triangles[i].v2].Normal.x, Verticies[Triangles[i].v2].Normal.y, Verticies[Triangles[i].v2].Normal.z);
glVertex3f(Verticies[Triangles[i].v2].Pos.x, Verticies[Triangles[i].v2].Pos.y, Verticies[Triangles[i].v2].Pos.z);
           
glTexCoord2f(1.f,1.f);  // A LO BESTIA PARA VER LA TEXTURA
glNormal3f(Verticies[Triangles[i].v3].Normal.x, Verticies[Triangles[i].v3].Normal.y, Verticies[Triangles[i].v3].Normal.z);
glVertex3f(Verticies[Triangles[i].v3].Pos.x, Verticies[Triangles[i].v3].Pos.y,Verticies[Triangles[i].v3].Pos.z);
}
glEnd();


En este caso como indico en los comentarios he hecho el mapeo a lo bruto para ver la textura, pero se que esta mal indicar las coordenadas de la textura de esa forma.

Entonces, sabiendo que tengo las coordenadas de la textura en el .obj, como hago para aplicar correctamente las texCoord a los triangulos en el renderizado? Es decir, como hacer para "envolver" el prisma con la textura a partir de las coordenadas de textura del .obj? Supongo que debe haber alguna forma generica para cualquier figura geometrica, y ahi reside mi duda.

Agradezco cualquier tipo de ayuda  :D

Gracias de antemano
#12
Cita de: TrOnTxU en 17 de Abril de 2010, 10:44:27 AM
??? No hay diferencia? Bueno, creo que dejaré esto de programar, ... creo que vi unas opos por ahi para barrendero, igual ...

Creo que no sería mala idea... sin menospreciar a ningun barrendero...

Cita de: Juan Mellado en 17 de Abril de 2010, 12:50:39 PM

for (int j = 0; j < gs.length; j++) {
     GraphicsDevice gd = gs[j];
     GraphicsConfiguration[] gc = gd.getConfigurations();

     for (int i=0; i < gc.length; i++) {
        Rectangle gcBounds = gc[i].getBounds();
...


Efectivamente...recién veo tu post, este hilo se había cortado 1 mes sin respuestas.

Lo he resuelto de esa manera, con la excepción de que manejo los valores de las coordenadas del graphic device para saber de qué monitor se trata. Ya que el orden en que getScreenDevices almacena los devices no es siempre el mismo.

Gracias y Salu2
#13
Cita de: tamat en 14 de Abril de 2010, 03:37:06 PM
GLSL no reemplaza la pila de matrices, GLSL es un lenguaje de shaders.

GLSL + Optional features = OpenGL Mathematics (GLM)

perdón, tal vez fui poco explícito en el mensaje anterior (debí haber escrito "Entre los "sustitutos" he visto implementaciones basadas en GLSL e implementaciones caseras del stack."

Gracias por la URL, hay material muy bueno y completo

salu2
#14
Off-topic / Re: la ESTAFA DEL "CAMBIO CLIMÁTICO"
14 de Abril de 2010, 03:46:56 PM
Cita de: astrologo en 30 de Marzo de 2010, 03:21:21 PM
En fin... lo que me preocupa es lo que se esconde tras ese "gesto"... lo raro es que hoy día los mass media no sólo pregonen las opiniones a favor del cambio climático, y silencien por completo las otras (que están al menos tan bien documentadas y justificadas como las que son contrarias).... Señores... que publiquen los registros de temperaturas de las estaciones de medición repartidas por todo el planeta (no la de las ciudades), o las de los satélites, o las de ambos... y que nos expliquen por qué las temperaturas medias globales están bajando los últimos años...  :..

A mi lo unico que "me preocupa" en parte es eso de las predicciones de los mayas (google: mayas 2012), de que supuestamente en el 2012 es el fin de una generacion o algo asi (no necesariamente es el fin del mundo como dicen por ahí). Hoy en día no se puede creer mucho en las nuevas "profesías" porque siempre hay $$$$ por detrás. También estan por todos lados las profesías de nostradamus que en cierto aspecto coincide en algo con la de los mayas (google: nostradamus 2012).

que opinan sobre esto?  ???
#15
Sí, por lo que he buscado al parecer se consideran deprecadas desde de la version 3.

Entre los "sustitutos" he visto GLSL e implementaciones caseras del stack.

Salu2





Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
Muchísimas gracias.