Hola,
tengo una duda sobre como configurar un entorno para programar en linux. Vaya por delante que estoy acostumbrado al entorno de Visual Studio en C++ y al hecho de añadir librerias en el proyecto.

Para linux, me estoy basando en CMake, pero hay algunas cosas que creo que no he comprendido bien. Primero: donde van las librerias? Esta claro que la forma mas comoda es usando apt-get, pero esas librerias quedan en los local y shares de tu linux. Entonces, como se distribuyen despues los programas?

Tengo mucho mas claro el concepto windows, donde todas las libs van a un folder, donde linkas estatico para que vaya al codigo directamente o dinamico, y entonces distribuyes las dlls. Eso se puede hacer en linux? Yo estuve probando con lua + luabind. Linko bien con luabind pero despues me dice que necesita lua. Y lua parece que solo le sirve si esta en /usr/local/...

Alguien me puede dar algun consejo de como montar un entorno de programacion? Cual es el ciclo de trabajo?

Muchas gracias.

Pero ahi esta el punto. Tu sabes en un árbol que una vez seleccionado el nodo, lo pintas todo hacia abajo. Es la ventaja de la ordenacion jerarquica. Pero en cambio, si usamos arrays es para recorrer y pintarlo todo. Entonces mirando esto:

sin embargo tengo unos amigos fanaticos de la optimizacion de codigo que insisten en que lo mejor es tener arrays separados para cada cosa, es decir, un array de camaras, uno de meshes, uno de luces, etc.

Pero si tenemos por ejemplo un array de camaras, como lo gestionamos? Y uno de meshes? Como hacemos culling?

["forward-compatible" (3.1) or "core" (3.2) profile]

Preguntando por gamedev me dijeron esto:
Mi pregunta:

Hi,

I'm new in opengl 3.x and I'm reading that all fixed pipeline has been deprecated. I've compiled old opengl code but creating a new render context (calling GL version 3.x) and no message about deprecation appears in the compiler. Is there a way to instruct the compiler to output a warning message when I do use deprecated functionality?

Las respuestas:

Not really, but you can download a gl3-only header.

Alternatively, you can request a "forward-compatible" (3.1) or "core" (3.2) profile, which will raise an error if you call any deprecated methods. Unfortunately, this is runtime-only protection.

But does gl3 only header be attached to a determined version? Or you select the version as you request the render context?

And, about the second method, I do understand that you are talking about the use of wglCreateContextAttribsARB funtion as explained in http://www.opengl.org/registry/specs/ARB/wgl_create_context.txt , aren't you?

gl3.h is for 3.0 and up. This is for your compiler.

It is your responsibility to check if the user`s system supports GL 3.0 or 3.1 or 3.2 while your exe is running on his machine.

Osea, por lo que entiendo es que podemos crear un render context para GL 3.1 o 3.2 e incluir la cabecera GL3.h. Esto haria que si usamos funciones deprecated el programa falle.  Por otro lado podríamos pedir un  "forward-compatible" (3.1) or "core" (3.2) profile. Si miramos el texto de http://www.opengl.org/registry/specs/ARB/wgl_create_context.txt vemos la seccion de los parametros que podemos dar para pedir un render context:

Código [Seleccionar] Expand

New Procedures and Functions

    HGLRC wglCreateContextAttribsARB(HDC hDC, HGLRC hShareContext,
     const int *attribList)

New Tokens

    Accepted as an attribute name in <*attribList>:

WGL_CONTEXT_MAJOR_VERSION_ARB 0x2091
WGL_CONTEXT_MINOR_VERSION_ARB 0x2092
WGL_CONTEXT_LAYER_PLANE_ARB 0x2093
WGL_CONTEXT_FLAGS_ARB 0x2094
WGL_CONTEXT_PROFILE_MASK_ARB 0x9126

    Accepted as bits in the attribute value for WGL_CONTEXT_FLAGS in
    <*attribList>:

WGL_CONTEXT_DEBUG_BIT_ARB 0x0001
WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB 0x0002

    Accepted as bits in the attribute value for
    WGL_CONTEXT_PROFILE_MASK_ARB in <*attribList>:

WGL_CONTEXT_CORE_PROFILE_BIT_ARB 0x00000001
WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB 0x00000002

Ahi tenemos la manera de crear contextos que limiten la version compatible por debajo de GL

De todas maneras tengo muy claro que sea aconsejable porque puedes tener sorpresas con las librerias de terceros que puedan usar features de GL, aunque para hacer pruebas de compatibilidad si que parece muy util.

En cambio para forzar un warning todavia no he descubierto casi nada.

Pero, como distinguen que tienen que dibujar? Es decir, tienes un array de camaras pero tienes que saber que dibujar.

Pues no he encontrado nada de eso. Si que existe una funcion de comprobacion de version, pero despues no informa de nada sobre el fixed pipeline. Me lo tengo que mirar mas a fondo, pero de momento ni una linea.

Yo no creo que borren nada para poder dar retrocompatibilidad. Simplemente se les iran acumulando bugs por que ya no estaran soportadas, pero no creo que se lien a borrarlas. Creo que la funcion de la que  hablas es cuando creas el render context, que el win32 ha campiado y ahora tienen una especial para OpenGL 3.x., pero no dice nada sobre deprecated.

Hoy me mirare las cabeceras de GLEW a ver si puedo encontrar algunas notas.
Esto es lo que he encotrado en una presentacion de Khronos

Deprecation mechanism

Step 1 Core feature
-
In core, fully supported. Willbe in the next API version
Step 2 Core (Deprecated feature)
-
In core, marked as deprecated
-
Maybe fully or partly removed in a later version
-
New features need not define interactions with deprecated ones

Step 3 ARB approved Extension
-
Removedfrom core -> an ARB extension (no suffix)
-
Extension spec identifies the removed functionality
-
Vendors may support the extension if markets require it

Step 4 Removed from ARB extension list
- Could be an EXT or vendor extension, if vendor markets still require it (still no suffixes required)

Y con un comentario aparte:

Deprecation is a four step process. First, a feature is in the core. Next, it is still in the core but clearly marked deprecated in the specification. Next, the ARB will remove it from the core specification and move it into an ARB extension. As you know, extensions are optional to implement by hardware vendors, the core specification is not optional. As a last step the ARB can decide to demote the feature even further, and then it becomes up to a hardware vendor to decide to support the feature as an extension, or not.

La presentacion completa aqui:
http://developer.download.nvidia.com/presentations/2009/GDC/OpenGL3_Introduction_GDC_2009.pdf

Como ya dije, no es mas que curiosidad. Lo único que he encontrado hasta ahora son diferentes maneras de tratar arboles con el fin de que el recorrido proporcione diferentes ventajas, como mejoras en la ocultacion, la gestion, etc.

Pero me preguntaba si había otras maneras que os sonaran mas experimentales, sobretodo basados en los nuevos tipos de procesadores multithreading para consolas y para ordenadores.

A todo el mundo le pasa cuando ve por primera vez un ciber-pollo  :P

No, si eso ya lo sabia. Solo que kd-tree, bsp, octree... son arboles. No se... pensaba que habia otros tipos de algoritmos no jerarquicos o bien con una gestion diferente. Solo era curiosidad.

Hola, acabo de leer en algunos mensajes sobre motores basados en arboles.  En general, que yo sepa, es la tecnica habitual, es decir, es scene tree. Pero me preguntaba si hay alguna otra tecnica habitual para representar escenas ademas de ponerlas de manera jerarquica. Alguien conoce algun motor que use otras tecnicas?

Estoy leyendo este http://www.amazon.com/exec/obidos/ASIN/159863528X/ref=nosim/gamedev

Es la segunda edicion y la verdad es que ya empiezan fuertes por que te dicen que el modo inmediato casi no lo enseñan y desde el primer momento ya empiezan con VBOs. Estoy avanzando poco a poco.

Okis, muchas gracias

Hola a todos,
me estoy leyendo un libro de opengl donde hablan del OpenGL 3.x. Lo que viene a decir el libro es que el inmediate mode, esta deprecated. Ok hasta aqui. El caso es que creo el contexto tal como dice el libro, y parece que va bien y dibuja bien, pero no hay ni rastro de mensajes en el compilador que adviertan que las funciones estan deprecated.

No deberia lanzarme algun warning el compilador?

Gracias

Este error es por que no encuentra la lib (archivo .lib). Pon este archivo dentro de la ruta de ficheros lib de tu IDE.

Hola a todos:

me estoy leyendo un tutorial de nehe sobre rotaciones. Esta aqui. Es un ariculo de camara basada en quaternions. El caso es que tengo dudas en la funcion setPerspective. Me explico: cuando lo resuelve con quaternions lo hace asi:

Código (cpp) [Seleccionar] Expand


void glCamera::SetPrespective()
{
GLfloat Matrix[16];
glQuaternion q;

// Make the Quaternions that will represent our rotations
m_qPitch.CreateFromAxisAngle(1.0f, 0.0f, 0.0f, m_PitchDegrees);
m_qHeading.CreateFromAxisAngle(0.0f, 1.0f, 0.0f, m_HeadingDegrees);

// Combine the pitch and heading rotations and store the results in q
q = m_qPitch * m_qHeading;
q.CreateMatrix(Matrix);

// Let OpenGL set our new prespective on the world!
glMultMatrixf(Matrix);

// Create a matrix from the pitch Quaternion and get the j vector
// for our direction.
m_qPitch.CreateMatrix(Matrix);
m_DirectionVector.j = Matrix[9];

// Combine the heading and pitch rotations and make a matrix to get
// the i and j vectors for our direction.
q = m_qHeading * m_qPitch;
q.CreateMatrix(Matrix);
m_DirectionVector.i = Matrix[8];
m_DirectionVector.k = Matrix[10];

// Scale the direction by our speed.
m_DirectionVector *= m_ForwardVelocity;

// Increment our position by the vector
m_Position.x += m_DirectionVector.i;
m_Position.y += m_DirectionVector.j;
m_Position.z += m_DirectionVector.k;

// Translate to our new position.
glTranslatef(-m_Position.x, -m_Position.y, m_Position.z);
}

Aqui lo que no entiendo es por que primero multiplica qPitch x qHeading, despues lo sube a la pila de matrices, y despues vuelve a multiplicarlos pero al reves qHeading x qPitch para sacarles el vector de direccion. El escritor del articulo también lo hace con matrices:

Código (cpp) [Seleccionar] Expand


void glCamera::SetPrespective()
{
GLfloat Matrix[16];

glRotatef(m_HeadingDegrees, 0.0f, 1.0f, 0.0f);
glRotatef(m_PitchDegrees, 1.0f, 0.0f, 0.0f);

glGetFloatv(GL_MODELVIEW_MATRIX, Matrix);

m_DirectionVector.i = Matrix[8];
m_DirectionVector.k = Matrix[10];

glLoadIdentity();

glRotatef(m_PitchDegrees, 1.0f, 0.0f, 0.0f);

glGetFloatv(GL_MODELVIEW_MATRIX, Matrix);
m_DirectionVector.j = Matrix[9];

glRotatef(m_HeadingDegrees, 0.0f, 1.0f, 0.0f);

// Scale the direction by our speed.
m_DirectionVector *= m_ForwardVelocity;

// Increment our position by the vector
m_Position.x += m_DirectionVector.i;
m_Position.y += m_DirectionVector.j;
m_Position.z += m_DirectionVector.k;

// Translate to our new position.
glTranslatef(-m_Position.x, -m_Position.y, m_Position.z);
}


Pero tampoco lo entiendo. Primero aplica las rotaciones, despues recupera la matriz modelview para recuperar un vector de direccion y despues cargar la identidad y volver a rotar y volver a recuperar la modelview y recuperar la direccion de j. Por que necesita hacer esto? No seria mejor recuperar la matriz una sola vez? Por que lo hace dos veces? Por que primero rota por heading y por pitch y despues solo por pitch?

A ver si me podeis pasar algo de info para niños de dos años. Entiendo las rotaciones basicas pero no logro ver por que hace esto.

Bueno, ya resolví el tema. Fallo por mi parte pues tenia incluido un fichero de cabecera que no tocaba.

Gracias a todos por vuestra ayuda.