Hot answers tagged

18

VAOs do not contain "glBindBuffer" state, with the exception of GL_ELEMENT_ARRAY_BUFFER's binding state. What you're not understanding is that glBindBuffer(GL_ARRAY_BUFFER) doesn't do anything. Well, it doesn't do anything as far as rendering is concerned. Try it; right before calling glDraw*, call glBindBuffer(GL_ARRAY_BUFFER, 0); your rendering will work ...


18

VAO stores data about vertex attribute locations. (And some other data related to them.) "VBO bindings, active shader program, texture bindings, texture sampling/wrapping settings, uniforms" are completely unrelated to it. You may ask why it doesn't remember VBO binding. Because you don't need to bind VBO to draw something, you only need to bind it when ...


6

I would expect glDrawArrays to be fastest on both the GPU and CPU for this scenario, primarily because you're saving the GPU memory bandwidth otherwise used for fetching the index data and the CPU cost of managing the index buffer. I do not expect glDrawRangeElements to be any faster than glDrawElements - in fact, I would expect it to be slightly slower. ...


5

Your main question seems to be: What would be the best way to draw frequently (really frequently, basically every frame) changing geometry with modern OpenGL? In most ways, there's no big difference between 2d and 3d OpenGL. The graphics pipeline has that one extra coordinate, Z, which won't be used as much in 2d, but that's about it. There's a few ways ...


5

I can't say to be expert of this subject, and in my game project(s) I have concentrated more on 3D side, so my 2D side is pretty simple generally using things made for 3D side; and obviously, my perspective is at gaming side, so my 2D graphics is more about blitting sprites than geometry. From that perspective, 1) Squares and rectangles are pretty easy. I ...


5

The VAO stores the glVertexAttribPointer state. Changing the VAO does not affect the current glBindBuffer, nor does changing the glBindBuffer affect the VAO. Only the glVertexAttribPointer call affects the VAO, by recording the buffer in use at the call. So the answer to your question is no. One option if you want to reduce the number of objects is to put ...


4

Since m_VAO is valid in constructor but not in draw(), it seems that the destructor was called before draw(), perhaps by copying an instance of the Polygon class. P.S. Errors like these could be prevented by following the Rule of three.


4

Here is a simple but effective explanation , basically a buffer object has information which can be interpreted as just simply bits of raw data, which on its own mean nothing, so it is PURELY the data which can be looked at any way really i.e float vbo[]={1.0,2.0,34.0...} and the way OpenGL was designed to work is that you must DEFINE what the data that ...


4

I try to answer the question. I think that you should go with indices, for few reasons: 1) In any case, indexing is free operation at GPU side, you don't take penalties there. (added) Of course, indices are random access operations, and can hurt GPU memory cache performance. 2) Indexing may allow GPU vertex cache to make those few optimizations for ...


4

If this is for desktop OpenGL or OpenGL|ES 3 and you're doing a common 2D sprite-style engine, you won't have a lot of repeat geometry. Everything is quads. You only need a single vertex buffer and index buffer (describing a quad). Use instancing to put all the transformation matrices for your scene objects into a single buffer and then draw that single ...


4

How to I implement a variable number of threads that all execute at the same time? Build/use a container class (I would call it a ThreadPool) for holding threads or thread references (note that std::thread is only movable and not copyable), each time one of the threads is started it is not joined by default. Wehn ThreadPool is going to be destructed you ...


4

It only stores the vertex binding and the index buffer binding That is all the parameters of glVertexAttribPointer plus the buffer bound to Vertex_Array_buffer at the time of the call to glVertexAttribPointer and the bound Element_Array_buffer. Uniforms are part of the current program. Everything else is global state. In doubt you can check the state ...


4

Yes, sending your mesh data to the GL every time you render it would be very wasteful. You should only be doing that if your data has changed from one frame to another (e.g. you are computing animations in the CPU). Otherwise, you shouldn't have to re-submit data if the model/mesh was not changed. Apparently, the problem with your program is that you are ...


4

There are not 16 attributes with fixed meaning. In old (pre 3.x) OpenGL there are a limited number of fixed function vertex attributes, and it is possible to use these in VAOs in compatibility contexts only. These correspond to generic vertex attribute (see the following discussion) slots as follows: 0: Position. 1: Vertex weight. 2: Normal. 3: Primary ...


3

Question 1: As always, it depends, and on many factors. Not only it depends on how much stuff you're drawing, but also on the particular video card, drivers and OS. In general, the old way of doing things (immediate mode and fixed pipeline) will probably be fast enough for your needs. However, you should probably consider doing things the modern way (...


3

you can step away from glDrawArrays and instead use glDrawElements and use a GL_ELEMENT_ARRAY_BUFFER​ buffer that hold the indexes of the vertexes you want to draw the element buffer would then contain {0,1,2,9,10,11,...} and so on. In you comments I see that you want this to draw a "light" object for quick updates, you can add all other triangles after ...


3

No, you shouldn't attach the VAO to a Shader Program. The VAO has to be linked with a Vertex Buffer, which makes it somewhat not shareable. You can only share it to the same extent you would share a Vertex Buffer. Whereas a Shader Program is highly shareable (you may be able to render all objets with the same program). The purpose of the VAO is to reduce ...


3

you can use separate attrib format so you can update the offset and stride of the vbo serpately from the format: //during initialization glBindVertexArray(vao); // set the details of a single attribute glVertexArrayAttribFormat(vao, posAttrLoc, 3, GL_FLOAT, false, offsetof(Vertex, pos)); // which buffer binding point it is attached to ...


3

How does opengl know which buffer to draw when glDrawElements is called(since there are 3)? It uses all three; it uses all the buffers you enabled, bound and referenced. They're all "drawable information." i have absolutely no idea how it would possibly know that the first buffer is the one that contains the vertexes, and the others non drawable ...


2

I do not understand the problem. If you do not call the join(), they won't be waited for. You should call the join() only right before you absolutely need the data they produce. The other threads wont be stopped if you call join() on one of them. See the join() reference: http://www.cplusplus.com/reference/thread/thread/join/ VAOs are not shared in between ...


2

I don't see any glActiveTexture or glBindTexture calls in your drawing code. As far as I know, VAOs handle vertex attributes only. You have to make sure the right texture unit is active and your texture is bound in your drawing routine.


2

I have no idea why would you want to draw each n-th triangle, and I cannot imagine a situation in which you would want to do that. ...but supposing you do have a legitimate reason to do that... I would say you can't, because glVertexAttribPointer is used to set the layout for the data at the vertex level, not the triangle level. In fact, OpenGL has no idea ...


2

glBufferData(GL_ARRAY_BUFFER, pd.size(), &pd.getPosition(offset)[0], GL_STATIC_DRAW); glBufferData(GL_ARRAY_BUFFER, mesh.getUVs().size(), &uvs[0][0], GL_STATIC_DRAW); glBufferData(GL_ARRAY_BUFFER,mesh.getVertexNormals().size(), glBufferData(GL_ELEMENT_ARRAY_BUFFER, (GLsizei)3 * mesh.numFaces(), mesh.getFaces().data(), GL_STATIC_DRAW); Assuming ...


2

Alright, so transformations in general are best done with matrices. Translation, Rotation, and Scaling can all be done using a **single matrix*. *Since you will be working with vector 3's and 4's, what you end up using is a 4x4 matrix. There are several libraries out there such as GLM for handling the mathematics generally used in opengl, but whatever ...


1

I base my water shader off of this work, its directX based but I'm sure with a bit of work you can convert it over but ill go over how I do it so you have an idea\recipe. First up I make a copy of the current frames back buffer to use as the refraction buffer or you can draw everything again and use clip planes but I only do that for the reflection buffer ...


1

Your question has nothing to do with direct state access. Your problems would still happen if you weren't using DSA functions. glNamedBufferStorage(StaticModelData::instanceDataID, sizeof(InstanceData)*10, nullptr, 0); That last value tells OpenGL how you intend to access the storage from the CPU. By passing zero, you're saying that you're not going to ...


1

First to ensure all vertices are rendered: Ensure that backface culling is disabled with GlDisable(GL_CULL_FACE) Disable depth testing glDisable(GL_DEPTH_TEST) OR ensure you are clearing the depth buffer bit before drawing glClear(GL_DEPTH_BUFFER_BIT) Second glBufferData(GL_ARRAY_BUFFER, sizeof(vertices),&vertices[0], GL_STATIC_DRAW); is incorrect. ...


1

The debugger's messages are pretty clear : "clean" core OpenGL should use VAO's and VBO's, not access client-side (i.e. RAM) data. That it works on their end is likely a consequence of their graphics drivers being too lenient.


1

With modern OpenGL, you can solve this elegantly by using instancing and texture arrays. Texture arrays Please see https://www.opengl.org/wiki/Array_Texture for an overview. Using a texture array you can retain the same texture coords for all faces in all cubes (i.e. 0.0, 1.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0) with the only thing you need to specify any ...


Only top voted, non community-wiki answers of a minimum length are eligible