Hola, no das demasiados detalles de tu problema. A que te refieres con que codeblocks no te reconoce las lineas de código?, te refieres a que da error al compilar o que no funciona el autocompletar ?
Yo no uso codeblocks, pero me aventuro a decir que si el error es de compilación seguramente te falta un include, si no te hace el build completo te faltara/n alguna/s libreria/s.

Saludos,

[Advertencia:]

Hola!

Si quieres cambiar el chip de verdad con OpenGL, debes dejar atrás la fixed pipeline y entrar en el mundo de los shaders.
Puedes usar la fixed pipeline también, pero que sepas que esta funcionalidad esta deprecated.

Te recomiendo la especificación de OpenGL ES 2.0, que es para mobiles pero es un subconjunto del OpenGL de escritorio,
más reducido y que solo tiene la parte programable. Desde ahí, saltar a OpenGL de escritorio es muy directo y facil.
http://www.khronos.org/registry/gles/specs/2.0/es_full_spec_2.0.25.pdf

Y una guia/tutorial con énfasis en "OpenGL moderno": http://www.arcsynthesis.org/gltut/

Y por supuesto, el sitio oficial: http://www.opengl.org/



Advertencia: el cambio de fixed pipeline a programable no es facil, tomatelo con calma. ;)

[.OBJ]

Hola,

El formato .OBJ  puede guardar las normales por vértice. Si no las tiene, puedes abrirlo con Blender y exportarlo con las normales, es una opción del exportador de Blender.

Lo de calcular las normales a mano también es una buena idea.  :)

Saludos,

[siguiente vertice]

Hola Nostromo.

Sí, estoy usando GLGE (una biblioteca bastante buena, por cierto), pero digamos que en ciertos puntos quiero emplear directamente javascript para crear un programa de OpenGL y un shader. Sobre lo que dices de pasar el atributo, ¿el valor de selected en el shader lo actualiza automáticamente OpenGL dependiendo del vértice que estemos actualmente empleando? Es decir, ¿opengl mueve automáticamente el índice del que toma el valor el atributo selected? Sí es así, genial, aparte me aclararía un montón de cosas :).

Si. A OpenGL se le pasan varios arrays o uno solo, depende de como te organices. Estos arrays, tienen la información por vértice de la posicion, normales, coordenadas de textura, y lo que quieras como en el caso de selected.

Supón que tenemos un shader con 2 atributos:

attribute float vec3 position;
attribute bool selected;
...



Lo que haces es asociar cada attribute del shader con un array(o buffer).
A OpenGL también le dices cuantos elementos del array hay por cada vértice. Ejemplo:
float VertexPositions[NUMERO_VERTICES*3]; 
En este array tenemos 3 elementos(floats) por vertice. Que son los floats para la posicion(x,y,z). En este caso pondriamos:
glVertexAttribPointer(positionAttrib, 3, GL_FLOAT, false, 0, VertexPositions );      

Fijate que le decimos a OpenGL que el attribute position tiene 3 float.
Y hacemos lo mismo para selected. En este caso cada selected tendría 1 byte.

Luego cuando le decimos a OpenGL que dibuje triangulos:
glDrawArrays(GL_TRIANGLES, 0, NUMERO_VERTICES);

OpenGL coge 3 elementos de VertexPositions y los coloca en un atributo dentro del shader.

Para el atributo selected cogeria 1 elemento. Y así con todos los attributos.
Los arrays son de distinto tamaño pero tienen contenido para el mismo numero de vértices.

Tras "enviar" los attributos al shader. La GPU lo ejecuta. Y se repite lo mismo para el siguiente vertice.

Hay dos maneras de dibujar(draw) en OpenGL. Una manera es la que te he puesto aquí. Se trata de enviar la información de los vertices, y cada tres vértices consecutivos en los arrays se dibuja un triangulo. Digamos que con esta forma de hacerlo no se comparten los vertices entre triángulos.

Otra forma de dibujar es tener otro array que contiene indices a vértices. Estos indices tienen valor desde 0 hasta el numero de vértices que tengamos. 3 indices definen un triangulo.
Y le decimos a OpenGL que dibuje los triángulos a partir de estos indices. Esta segunda forma se hace llamando a glDrawElements.

Espero haberte aclarado este tema un poco.

animación del modelo. Voy a cambiar la pregunta: ¿la posición de un vértice en una malla cambia cuando se realizan operaciones de traslación/rotación o la posición final es independiente de estas?

La posicion final del vertice que se calcula en el vertex shader es independiente de la posicion(el attribute posicion) de entrada al vertex shader.
Ahora bien, tu puedes cambiar las posiciones de entrada. Depende de lo que estés haciendo.

Independientemente de lo anterior lo que dices de pasarle los atributos al shader sería la solución, pero desgraciadamente no sé como seleccionar un vértice en concreto para establecerlos. Como ya dije, soy un novato completo, tengo muuucho que aprender y estoy en ello , o sea que se agradece de corazón vuestra paciencia :D.

La cuestion es ¿como le estas pasando los "attributes" al shader? ¿Los estás pasando a mano con glVertexAttribPointer o estas usando una librería/engine?

Si los pasas a mano solo tienes que duplicar las llamadas que haces para pasar el attributo "posicion", suponiendo que se llame así.
Te pongo un ejemplo con los pasos para hacerlo a mano:

1. Crear un attributo nuevo en el shader, llamemosle "selected":
attribute bool selected;

2. Obtener el indice de este atributo del shader (Esto es C, en WebGL deberían haber llamadas similares):
    int selectedAttrib = getAttribLocation(shader, "selected");

3. Decirle a OpenGL donde están los valores de ese atributo:
    float VertexPositions[NUMERO_VERTICES*3];  //
    bool VertexSelected[NUMERO_VERTICES];  //  este es el nuevo array
    ....
    glVertexAttribPointer(selectedAttrib, 1, GL_BYTE, false, 0, VertexSelected );           
    glEnableVertexAttribArray(selectedAttrib);
    ...


Más o menos sería así hacerlo a mano en C. Aunque por las preguntas que has hecho, intuyo que estás usando una librería o un ejemplo de código que no entiendes.

Ten paciencia con este tema. Usar OpenGL ES 2.0 directamente, que es lo que se usa en WebGL, es difícil de aprender.

Hola.

Creo, con el manual de OpenGL ES 2.0 en la mano, que gl_vertexID no existe en esta versión.
Porque no le pasas al vertex shader el atributo que te interese? Puedes pasarle los atributos por vertice que quieras.
Hay un pequeño limite (MAX_VERTEX_ATTRIBS) en el número de atributos que puedes pasar, pero en la practica no creo que tengas problema.

Saludos.

Joooder era eso, gracias, ya me carga la textura, aunque con el color invertido, pero es un comienzo :D Tanto mover las cosas de sitio...

Para glu yo nunca he inicializado nada y no he tenido problemas. Aunque sólo he usado gluPerspective y poco más. Que yo sepa son más funciones sobre la misma base.

La que sí que me sigue sin funcionar es

glTexImage2D(GL_TEXTURE_2D, 0, 3, biWidth, biHeight, 0, GL_RGB, GL_UNSIGNED_BYTE, imagen);

Que era la función que iba a usar al principio, pero de ésta no se cómo sacar los errores que produce, sabes cómo? Sólo la he conseguido usar con la librería corona, aquí sustituyéndola no hace nada, y como no tiene valor de retorno no se sacar los errores.

El error lo puedes ver con la función glGetError(). 

Ok.

En el código, lo que veo es que primero cargas el BMP y esto hace llamadas a OpenGL, y despues inicializas el contexto de OpenGL.
Deberias inicializar OpenGL antes de cargar el BMP.
Puedes probar a intercambiar las dos llamadas que están juntas.

Otra cosa...¿Glut necesita iniciarse? No lo recuerdo.

Suerte!

Pero... ¿No Inicializas OpenGL y creas un context para llamar a funciones OpenGL?

[coordenadas de mundo]

Holas,

Sobre lo último que comentas creo que no es buena idea leer demasiadas cosas de la memoria de la GPU. El ancho de banda de las conexiones CPU/GPU es limitado y leyendo datos saturas esta conexión, es una cuestión de rendimiento.

Para un juego, yo creo que puedes estar tranquilo manteniendo las coordenadas de mundo de los objetos en la memoria principal. Cuantas coordenadas(vertices o el centro del objeto) necesitas por objeto pues ya depende de como implementes colisiones/fisica y todo eso.
Date cuenta que la matriz MVP por objeto contiene la translación del objeto, y conseguir las coordenadas transladadas finales para un objeto es una suma de vectores, es una operación muy rapida.

Por otra parte piensa que lo que le envias a la GPU es lo que se va a ver por la pantalla. Es decir, habrán muchos objetos que no los mandarás y, sin embargo, estos objetos que no envias a la GPU tendrán su vida propia, sus coordenadas, etc...

También decir que existen casos en que la información del estado/posición de los objetos si que puedes mantenerla en la GPU, y actualizarla en la GPU(shader) como es el caso de un sistema de particulas que no quieres que interaccione con el entorno.

No soy un experto en OpenGL ES 2.0, no te tomes lo que diga como una verdad absoluta.  ;)

Saludos,

Hola

zwiTTER  ha puesto los puntos importantes para valorar la estimación.
Por ampliar un poco puedes leer esto:
http://www.gamasutra.com/view/news/32809/Exclusive_Behind_The_Scenes_Of_Minecraft.php
Este articulo apunta a otro de la revista game developer magazine que seguro que tiene datos mas precisos del desarrollo del Minecraft.

Tampoco infravaloraria el tema del motor grafico. El apartado grafico, el render, es bastante distinto a lo que ofrecen los motores que hay por ahí. Que no te engañe el aspecto del juego, en Minecraft lo que importa es la escala del mundo. Esto se traduce en personal para desarrollar un motor especifico para este tipo de juegos.

Suerte con tu busqueda.

Saludos.

Hola,

Te falta multiplicar por 2:
float b =  2 * (posRay.x * dirRay.x + posRay.z * dirRay.z);

Se te olvido multiplicar por 4:
float det = b*b - 4*a*c;

Se te olvido dividir por 2a:
                float i1 = (-b - d)/2*a;
      float i2 = (-b + d)/2*a;

Creo que te vendria bien hacer, para que tu lo visualizes mejor, un esquema con las coordenadas y los ejes de tu mundo.
Viendo esta linea de codigo:   "if (t0.y < EPSILON || t0.y > m_height) { ......."  entiendo que tu cilindro "crece en altura" en el eje y.
El caso es que las formulas estan hechas asumiendo que el cilindro crece en el eje z y tenga una base(tapa) en el plano x,y.

Yo de ti primero probaria sin transformar nada. Hasta que te salga algo coherente. Y cuando te salga... entonces metete con la transformacion

[M]

Hola.

Busca en amazon http://www.amazon.com/Geometric-Computer-Graphics-Morgan-Kaufmann/dp/1558605940
Como sabrás, a veces puedes ver dentro del libro con "Search Inside". Busca "linear component cylinder" e intenta ir al apartado 11.3.4 pag. 508
Ahí te viene la explicación de un método de intersección linea-cilindro.

Te pongo un breve resumen del método que propone:

El método se basa en poner el cilindro en una forma estandar, a saber:
- Debes calcular una transformacion M para poner el cilindro con
 1. La base del cilindro asentada en el plano x,y
 2. El centro de la base alineado con el centro de coordenadas (0,0,0)
 3. El cilindro crece con altura h alineado a z
 4. El cilindro tiene radio r

Ahora, para calcular que un punto esta en el cilindro (sin contar las tapas):
Se tiene que cumplir (A)         x^2 + y^2 = r^2    y    0 <=z <= h

El rayo L(t)=P+t·D  tienes que transformarlo a las nuevas coordenadas del cilindro.... multiplicando por  M  

substituyes las componentes de L(t) en (A) y te sale un ecuación de segundo grado con la incognita t . Con la t calculada sacas z y compruebas que este en el rango 0 <=z <= h , (para que no este en el cilindro infinito).
Si el punto calculado esta en el cilindro se le aplica la transformación con la inversa de M para conseguir el punto en las coordenadas del mundo.

Para el calculo de la intersección con las tapas: calculas la intersección con el plano de la tapa y compruebas que  el punto (x,y)  cumple x^2 + y^2 <= r^2     Si cumple se hace lo mismo, se le aplica la transformación con la inversa de M y ya tienes el punto (x,y,z)

nota: En el libro se define M como la tranformación de las coordenadas de la  forma estandar a las coordenadas del mundo. Yo lo he puesto al revés, pero sigue siendo valido el resumen :)


Saludos

Hola.

Te pongo un enlace a un hilo de los foros de XBLIG que trata ese tema.
http://forums.xna.com/forums/t/36822.aspx


Saludos

Si, yo me referia a un acceso al registro de una maquina que se pueda administrar. La maquina podria ser el servidor u otra maquina que tenga acceso al registro via remota; siempre pudiendo administrar la maquina "cliente" claro.

La verdad que acceder al registro del cliente que navega por la web es algo delicado...