Opengl, Shaders Y Blend

[zupervaca]

 si en la mayoria de ejemplos he visto que usan el PSIZEn, lo de las 2000fps es normal ya que tengo que renderizar triangulo a triangulo con fors (grrr) por culpa de esti rollo, lo del "super buffer" parece una coña :P (deberian llamarlos "super vaca"), pero viendo todas las maneras que tiene opengl para renderizar no me extrañaria que metieran alguna mas para estos buffers

saludos y gracias

[BeRSeRKeR]

 Yo siempre había odído hablar de esa posible extensión como "übber buffer" pero vamos que es lo mismo porque creo über en alemán significa super. :D

Saludos.

[visualcubb]

3.- Depende de si tienes o no desactivado Vsync, esto reduce el rendimiento por la sincronia con el monitor.

Si tiene activado el Vsync le tendria que ir a la frequencia del monitor, no?

Efectivamente colega, afortunadamente existe una extensión en OpenGL que permite desactivar el Vsync y así la aplicación da el máximo de FPS posible.

[vincent]

3.- Depende de si tienes o no desactivado Vsync, esto reduce el rendimiento por la sincronia con el monitor.

Si tiene activado el Vsync le tendria que ir a la frequencia del monitor, no?

Efectivamente colega, afortunadamente existe una extensión en OpenGL que permite desactivar el Vsync y así la aplicación da el máximo de FPS posible.

No conocia el tema de la extensión. Yo siempre lo hacia desactivandolo en las propiedades de la pantalla...  B)  

[visualcubb]

lo del "super buffer" parece una coña :P (deberian llamarlos "super vaca"),
saludos y gracias

No lo es colega, si lees las especificaciones de GL_VERTEX_BUFFER_OBJECT hay una referencia bien superficial a la idea del super buffer que ya lleva pensada bastante tiempo.

[visualcubb]

si en la mayoria de ejemplos he visto que usan el PSIZEn, lo de las 2000fps es normal ya que tengo que renderizar triangulo a triangulo con fors (grrr) por culpa de esti rollo,

Creo que algo estás haciendo mal ahí, nunca he tenido que renderizar triángulo a triángulo con OpenGL, ni siquiera usando GLSL, todo lo contrario...

Quizás deberías revizas las especificaciones de OpenGL o algunos ejemplos para verificar.


Saludos.

[visualcubb]

3.- Depende de si tienes o no desactivado Vsync, esto reduce el rendimiento por la sincronia con el monitor.

Si tiene activado el Vsync le tendria que ir a la frequencia del monitor, no?

Efectivamente colega, afortunadamente existe una extensión en OpenGL que permite desactivar el Vsync y así la aplicación da el máximo de FPS posible.

No conocia el tema de la extensión. Yo siempre lo hacia desactivandolo en las propiedades de la pantalla...  B)

La extensión es mucho mejor, así te aseguras que sin importar lo que el driver tenga configurado, siempre se va a desactivar Vsync.

Saludos.

[zupervaca]

 los ejemplos que he encontrado usan el psize o renderizar triangulo a triangulo, ¿como lo haces tu?

saludos

[visualcubb]

los ejemplos que he encontrado usan el psize o renderizar triangulo a triangulo, ¿como lo haces tu?

saludos

Hola zupervaca, ¿puedes explicar con más detalle cuál es tu problema y si es posible colocar algún seudocódigo?.

Así va a ser más fácil ayudarte.

[zupervaca]

 el problema que tengo es sencillo, pero de dificil solucion, necesito renderizar unos vertices con un shader, estos vertices debe de estar en la memoria de video (toda su informacion) y ser estaticos para sacar el maximo provecho, cada vertice se compone de posicion, normal ... y del blendweight el cual desde opengl no se puede especificar si no es con un glattribpointerarb, pero este buffer siempre que accedes a el lo sube a la memoria de video con lo que se pierde rendimiento.
la mayoria de los ejemplos que he visto renderizan triangulo a triangulo y los mas avispados usan una coordenada de textura extra, el psize o cualquier otro valor que no sirva para nada, pero claro eso me parece un pelin "chapuza" ya que como mi motor 3d permite renderizar en direct3d u opengl no se va a poner en opengl que la coordenada de textura 7 sirva para lo mismo que el blendweight de direct3d, no se si aun me explico bien del todo.
la estructura de vertice seria algo asi:
vertice
{
float x,y,z,BLEND;
}
ese blend en direct3d se define sin problemas y siempre esta en la memoria de video, pero en opengl parece ser que si no usas glVertexPointer, glTextureCoodPointer, etc el bufer se vuelve a subir por el agp o el pci-express, lo he probado y efectivamente se vuelve mas lento usando los attribpointer o vertexpointer que usando una coordenada de textura extra.
la gente que usa el psize lo hacen triangulo a triangulo y la gente que usa la coordenada de textura extra usan el drawelements.

saludos

[Xam]

 @zupervaca
A lo mejor me equivoco y estoy metiendo la pata. Pero me parece, viendo por donde va el hilo, que no has hecho mucho caso a mi comentario ni al de Pogacha. Así que me voy a repetir un poco.

Yo no he podido utilizar todavía los vertex_buffer_objects (agradecería que sí alguien los ha probado ya nos pueda aclarar el tema). Pero según lo que  entiendo (de la especificación de OpenGl 2.0 y de la especificación de la extensión GL_ARB_VERTEX_BUFFER_OBJECT) no habría ningún problema en almacenar en la memoria de video toda la información que se quiera ( o se pueda) asociada a un vértice.

Según visualcubb ....

... si quieres usar GL_VERTEX_BUFFER_OBJECT, la razón de esto es que esta extensión hasta donde tengo claro solo guarda en memoria los arreglos que corresponden a propiedades primitivas de los polígonos, como los vértices, las texturas, las UV, las normales y el color, si quieres agregar un arreglo más, ese se queda en ram de sistema y no de video ...

... pero viendo el ejemplo que viene en la especificación de la extensión ( por ejemplo aquí ) ...

Código [Seleccionar] Expand


     
       // Los comentarios que empiezan por '// **' no vienen en el ejemplo los he
       // metido yo.

       #define BUFFER_OFFSET(i) ((char *)NULL + (i))  
   
       // Create system memory buffer  
       data = malloc(320);

       // Fill system memory buffer  
       ...  

       // Create buffer object  
       BindBufferARB(ARRAY_BUFFER_ARB, 1);  
 
       // Initialize data store of buffer object  
       BufferDataARB(ARRAY_BUFFER_ARB, 320, data, STATIC_DRAW_ARB);  
 
       // Free system memory buffer  
       free(data);  
 
       // Frame rendering loop  
       while (...) {  
 
           // Define arrays  
           BindBufferARB(ARRAY_BUFFER_ARB, 1);  
           VertexPointer(4, FLOAT, 0, BUFFER_OFFSET(0));  
           ColorPointer(4, UNSIGNED_BYTE, 0, BUFFER_OFFSET(256));  
           // ** VertexAttribPointer( ... )
 
           // Enable arrays  
           EnableClientState(VERTEX_ARRAY);  
           EnableClientState(COLOR_ARRAY);  
           // ** EnableVertexAttribArray( ... )
 
           // Draw arrays  
           DrawArrays(TRIANGLE_STRIP, 0, 16);  
 
           // Disable arrays  
           DisableClientState(VERTEX_ARRAY);  
           DisableClientState(COLOR_ARRAY);
           // ** DisableVertexAttribArray( ... )  
 
           // Other rendering commands  
           ...  
 
       }  
 
       // Delete buffer object  
       int buffer[1] = {1};  
       DeleteBuffersARB(1, buffer);  
 


... parece que no habría mucho problema en poder almacenar en memoria de video y luego utilizar para el render todos los atributos extra que se quiera (o que se pueda) para un vertice.

[zupervaca]

 lee el inicio de 2.9 de la especificacion, hace un breve comentario sobre el 2.8

[Xam]

 Te refieres a esto:

2.9 Buffer Objects

The vertex data arrays described in section 2.8 are stored in client memory. It is
sometimes desirable to store frequently used client data, such as vertex array data,
in high-performance server memory. GL buffer objects provide a mechanism that
clients can use to allocate, initialize, and render from such memory.

Si es así, no entiendo tu respuesta. Ese párrafo es totalmente congruente con lo que he escrito en mi anterior mensaje. Le ves algún problema?

[visualcubb]

 Hola zupervaca, leí tu problema y en realidad no es ningún problema, si el valor que quieres enviar es uno solo puedes usar perfectamente GL_VERTEX_BUFFER_OBJECT y con eso te aseguras de que tu modelo siempre esté en la memoria AGP, solo tienes que enviar el cuarto parametro en el glVertexPointer diciendole que cada vertice tiene 4 parámetros y usarlo en el shader, nada mas.

Espero que te haya quedado más claro, si no, te puedo poner un ejemplo aquí.

[vincent]

 Si no me equivoco uno de los problemas que tienen los Vertex Buffer Objects es que no puedes saber a priori de cuanta memoria dispones, con lo que, si te pasas, el programa te peta.

Pero va más rápido, si señor. En la web de nVidia encontraras algún ejemplo.

Saludos!