PDA

View Full Version : Drawing different things and Alternatives to gluseprogram() ?



puregainz
03-12-2017, 02:50 PM
Hello again fellows!

I am trying to achieve rendering a game board made of tiles on the left side of my window, but I also want to build a GUI/Menu on the right side of my window, how do I manage both different renderings ? which method is best ?:

1) Send the vertices of the menu in the same buffer as for the game rendering (like at the end) and make conditional code in my vertex shader


if (gl_VertexID > n){
//do menu rendering things
}else{
//do game rendering things
}

But that seems really heavy and not adapted to GPU computation
Regarding this method, in the vertex shader it is possible to do:


gl_Position = vec4(...); //standard 1 vertex is sent
//or
gl_position = vec4[n](); //send n vertices from 1 set of VBO inputs values

Is it possible to "call" gl_position = " multiples times and that way using 2 VBOS and process their data differently ?
(I think it's not, based on the different feeding rate of VBOs to the vertex)

2) To render a frame: I use 2 programs one for the board and one for the menu, I am unsure about this method.
I know that to bind another VBO you need to call glattribpointer again, it doesn't seem right to do that.
But when creating 2 shader program it isnt needed right ?
I'm working on OpenGL 4.2, and OpenGL 4.5 tells me that using gluseprogram() is expensive and has other methods to so, what is the predered way in OpenGL 4.2 ?

3)Some people talk to achieve 3D games HUD to draw to another framebuffer and do "Associative Alpha Blending" to combine the buffers together,
I haven't investigated this method yet, but that seems Overkill knowing I don't want to overlap the 2 drawn features (and not at the pixel level)

Any advices ?

john_connor
03-12-2017, 05:05 PM
Is it possible to "call" gl_position = " multiples times and that way using 2 VBOS and process their data differently ?
(I think it's not, based on the different feeding rate of VBOs to the vertex)

no, 1 vertex can only have 1 position on the screen



2) To render a frame: I use 2 programs one for the board and one for the menu, I am unsure about this method.
I know that to bind another VBO you need to call glattribpointer again, it doesn't seem right to do that.
But when creating 2 shader program it isnt needed right ?
I'm working on OpenGL 4.2, and OpenGL 4.5 tells me that using gluseprogram() is expensive and has other methods to so, what is the predered way in OpenGL 4.2 ?

a "vertex array object" (VAO) is what you need: make for each (shader) program a new VAO, and set / enable their attribute pointers once, the VAO will store these values, you only have to bind them when you want to use them
https://www.khronos.org/opengl/wiki/Vertex_Specification#Vertex_Array_Object



3)Some people talk to achieve 3D games HUD to draw to another framebuffer and do "Associative Alpha Blending" to combine the buffers together,
I haven't investigated this method yet, but that seems Overkill knowing I don't want to overlap the 2 drawn features (and not at the pixel level)

Any advices ?

use a library, its easier and faster. if you only want to render some rectangles with text on them, surely you can render these things yourself, but things will get a bit complicated if you want more ...

http://anttweakbar.sourceforge.net/doc/
http://ogldev.atspace.co.uk/www/tutorial48/tutorial48.html
very easy to use, many examples / tutorials available, and it looks pretty good ...

GClements
03-12-2017, 10:40 PM
I am trying to achieve rendering a game board made of tiles on the left side of my window, but I also want to build a GUI/Menu on the right side of my window, how do I manage both different renderings ? which method is best ?:

You probably want to use separate programs for the two cases. You almost certainly want to use separate vertex arrays.



I'm working on OpenGL 4.2, and OpenGL 4.5 tells me that using gluseprogram() is expensive

It's not so expensive that you should try to shoehorn everything into a single shader program.

When you see advice about minimising state changes, particularly program changes, it means that a reduction from 100 changes each frame to 50 changes is a worthwhile optimisation. If the number of program changes is in single digits, then it doesn't matter.