Possible? Shaders using only gpu stored world objects into buffer /textures

I have slowly googling, reading,checking shaders trying to learn by-the-metal how much can i load all space sim ships models in gpu memory (buffer?buffers? textures to hold data structures) and only send per frame 2 vec4 our pos and orientation?

Trying to learn in simple and direct understanding if its feasible?

Im pretty new in opengl (learned about shaders in directx when they first come out)… so many years till i grasped that book but never coded as was too busy in my official job.
So 6 months ago i restarted and focusing in opengl… trying to understand the basics by-the-metal (i started as a machine code/assembler on the 80s and 90s just for you my opengl knowledge fellows to see how low level am i interested in learning exotic performant way to achieve this long time idea of store all/most 3d models in gpu and only stream our pos+orientation.

extra: seems in open gl we can only attach one buffer at a time if 1 specific type (flagging read only, stream or write)… simple doubt on this concept… does this mean all re-assigning buffer A or buffer B to same attach/buffer type can only be done in Cpu side ? How can a shader only play with only gpu memory (multiple buffers and hack using 3d structures as way to store multi dimensional data structures)? Thanks

It is entirely feasible, and it’s what you will end up with if you follow any modern OpenGL tutorial.

Vertex attribute data is uploaded once (when the model is loaded), only the object’s transformation (typically a uniform mat4) changes each frame. The transformation of vertices from object space to clip space is performed by the vertex shader.

[QUOTE=GClements;1289031]It is entirely feasible, and it’s what you will end up with if you follow any modern OpenGL tutorial.

Vertex attribute data is uploaded once (when the model is loaded), only the object’s transformation (typically a uniform mat4) changes each frame. The transformation of vertices from object space to clip space is performed by the vertex shader.[/QUOTE]

Ha good to know, i was expecting so thats why I decided to join the community as after some months googling and checking modern way of use GPU (comparing with old times where every frame we would send all vertices - and prior cliping done in cpu etc).

Now going more practical… seems theres this concept of only 1 buffer can be BINDed to 1 single specific type ? So is it possible to load multiple buffers into GPU (i guess and each one gets his own id)… but then how can shaders access a particular buffer from the ones loaded ? Or does this must to be done in CPU when doing all the binds and assembler a program ?

openGL is a “client-server” system, you only do stuff on the cpu side, openGL does the rest on the gpu side. you (the cpu side) can bind a buffer to several different targets on the GL context, for example: GL_UNIFORM_BUFFER is such a target, in addition to that “general” target, the context provides an array of “binding points” for that target. you can bind buffer A to binding point 1 and buffer B to binding point 2 (both GL_UNIFORM_BUFFER) and use them both in a shader. the number of binding points is limited, and the buffer size for each binding point is also limited, depending on the target and gl version (and possibly supported extensions / GL implementation [driver]).

the “flags” (for example: GL_DYNAMIC_DRAW) for a buffer are only hints for the driver on how you plan to use that buffer

bind a buffer to a binding point (cpu-side):
glBindBufferBase(GL_UNIFORM_BUFFER, 1, mybuffer);

and declare a block in your shader (source code):
layout (std140, binding = 1) uniform MYBUFFER { int mybufferdata[1234]; }

and access “mybufferdata” as you wish …

[QUOTE=john_connor;1289034]openGL is a “client-server” system, you only do stuff on the cpu side, openGL does the rest on the gpu side. you (the cpu side) can bind a buffer to several different targets on the GL context, for example: GL_UNIFORM_BUFFER is such a target, in addition to that “general” target, the context provides an array of “binding points” for that target. you can bind buffer A to binding point 1 and buffer B to binding point 2 (both GL_UNIFORM_BUFFER) and use them both in a shader. the number of binding points is limited, and the buffer size for each binding point is also limited, depending on the target and gl version (and possibly supported extensions / GL implementation [driver]).

the “flags” (for example: GL_DYNAMIC_DRAW) for a buffer are only hints for the driver on how you plan to use that buffer

bind a buffer to a binding point (cpu-side):
glBindBufferBase(GL_UNIFORM_BUFFER, 1, mybuffer);

and declare a block in your shader (source code):
layout (std140, binding = 1) uniform MYBUFFER { int mybufferdata[1234]; }

and access “mybufferdata” as you wish …[/QUOTE]

Ha great, I see… theres 2 things: the “general” one and then an array of indexed buffers…

  1. I guess the “general” one is the one that GL will stream into our vertex shader one by one.
  2. as an example, imagine i stream in the “general” buffer just 3 vec3 locations+someId (my own loc and 2 locations of 2 other ship in space)… would it be possible for me to pick the someID of a model and stream/generate all its geometry (ships model stored in one of the indexed buffers for example) ? I understand geometry shaders are the ones that allow one to expand/create geometry on fly… so ion this case vertex shader would not need to do too much work - just pass along the 3 vec3 locations+someId and then it would be the geometry shader that would do all the work getting all geometry from indexed buffer + offsetting it to the vec3 location received - but then where to do the perspective/rotation etc matrixes multiplication of each generated vertex outgoing from geometry shader…

Sorry if i seem to confused… but your 2 previous answers confirmed some basics, and now im just wondering the shaders pipeline architecture needed to achieve my goal. Thanks so much for helping me with basic insights.
As soon i feel comfortable with the basic to the metal, then look forward to start coding… but first just trying to understand the primitive basic stuff we have to play with in OpenGL.

[QUOTE=emanueol;1289035]Ha great, I see… theres 2 things: the “general” one and then an array of indexed buffers…

  1. I guess …[/QUOTE]

you dont need to guess:
https://www.khronos.org/opengl/wiki/Vertex_Specification#Vertex_Buffer_Object

[QUOTE=emanueol;1289033]
Now going more practical… seems theres this concept of only 1 buffer can be BINDed to 1 single specific type ? So is it possible to load multiple buffers into GPU (i guess and each one gets his own id)… but then how can shaders access a particular buffer from the ones loaded ? Or does this must to be done in CPU when doing all the binds and assembler a program ?[/QUOTE]
Buffers are typically regions of video memory. Data is copied into them using glBufferData/glBufferSubData or by mapping them as client memory.

Vertex attributes are associated with buffers using glVertexAttribPointer(). That causes data for that attribute to be read from the buffer which was bound to the GL_ARRAY_BUFFER binding point at the time of that call.

Alternatively, 4.3 added a different interface where specification of the format and the buffer are separated. This uses glBindVertexBuffer() and glVertexAttribBinding() to specify the buffer, and glVertexAttribFormat() to specify the format.

[QUOTE=GClements;1289031]
Vertex attribute data is uploaded once (when the model is loaded), only the object’s transformation (typically a uniform mat4) changes each frame. The transformation of vertices from object space to clip space is performed by the vertex shader.[/QUOTE]

oh i now understood better what you mean…
let me digest a bit more your answers + john’s link and will come back.
i feel probably time to download a dev environment at this stage… any suggestion? taking in account i used borland c++ (my prefered), visual c++(hated the model/view mfc btw lol) and assembler.
In past years vc++ evoluted to .net but i like the simplicity old borland tools gave…
2nd) i read theres couple c utility libraries that make the basic window setup easier across platform (windows, linux, ?..) as well right?

so what should be my minimum shopping-list (aka download) ?

thanks getting there and look forward to start playing with ideas :wink:

On Windows, I’d suggest using MSVC. You aren’t forced to use frameworks such as MFC or dot-NET.

You’ll probably want GLUT or GLFW (simple cross-platform UI toolkits to handle window management and input events), GLEW (which lets you use OpenGL versions >1.1 without having to explicitly use wglGetProcAddress() to obtain function pointers), and GLM (a C++ vector math library; amongst other things, this provides work-alikes for the legacy matrix functions).