Hot answers tagged

27

With modern OpenGL's VBO's are the way to go, fixed function stuff (including glBegin/glEnd and the stuff in between) has been deprecated since 3.0 and removed since 3.1. With the OpenGL Core Profile, OpenGL ES 2.0+ and WebGL you don't even have access to the old stuff. Some people think learning the old stuff first is better because it's a bit easier, but ...


23

Is there a substantial overhead to allocating / deallocating VBOs (I mean the mere act of setting up a buffer)? Define "substantial." It is generally wise not to create them in the middle of frames; they should be set up during initialization or wherever. But this is true of most OpenGL objects, like textures, renderbuffers, or shaders. If I'm updating ...


21

If you're wondering about OpenGL coverage, a good place to start is the Steam Hardware Survey. http://store.steampowered.com/hwsurvey?platform=pc Unfortunately, it seems to be broken right now and it doesn't display any stats for videocards. :\ I've also read things like XP only supports up to a certain version DirectX 9 is comparable to OpenGL 2.1, ...


18

The way OpenGL works, whenever you use non-VBO data, the driver has to make a copy of it - in practice creating a temporary VBO - since nothing stps you from modifying your user-space naked arrays between calls to OpenGL. There may be some driver-side trickery to make the temp allocation faster, but there's nothing you can do to avoid the copying. So yeah, ...


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 ...


10

What you're looking for is instancing. You simply call glDrawArraysInstanced​ or glDrawElementsInstanced​, passing the number of instances that you want. There are two ways to then determine per-instance data: The gl_InstanceID vertex shader input tells you which instance is currently being processed. Your vertex shader can have an internal mechanism for ...


9

and vertex arrays seem to be deprecated. Instead, if I understand correctly, Not quite. Vertex arrays are the foundation for vertex buffer objects. Only the storage moved from client to server side. What if I have a scene that has a lot of smaller geometry? Merge smaller geometry sets into larger VBOs. There's no need to have one VBO per geometry batch. ...


9

For some statistics about hardware compatibility you could look at Steam survey: http://store.steampowered.com/hwsurvey/ Although it lists DX10 and DX11, the hardware compatibility is the same as OpenGL 3 and OpenGL 4 respectively. Though note that OpenGL driver installation state on people is usually worse than DX. Windows XP doesn't support DX10 or DX11, ...


9

This is a complex question with a lot of small details that really matter, the performance will vary based on platform and application. So you should profile for possible bottlenecks before investing in optimizations. That said, firstly, I assume you should reduce uploads and updates as much as you can, for example use instancing. Secondly, note that GPUs ...


8

I think you want to change your attribute pointers, specifically the offsets you have listed. &vertices[0].position should be 0, &vertices[0].normal should be 12, &vertices[0].uv should be 24, and so on. Since getting the address of a struct member gives you the absolute address instead of the address relative to the beginning of the struct. ...


8

You cannot use separate index buffers in the way you intend to. But since you are writing your own importer, you can very well reorganise the in-memory data so that both the position and texture information are indexed the same way. This possibly means duplicating information in the process, but that cost must be put in regard to the overall bandwidth gain ...


7

With VBOs you generally have two major advantages. Advantage 1 relates to fully static data and comes from being able to keep your vertex data in memory that is more optimal for the GPU. Advantage 2 relates to dynamic data and comes from being able to specify your vertex data at any point in time prior to using it for rendering, which can pipeline better. ...


7

This answer is more or less in flux, due to the recent advent of this. In general, what you want to avoid is calling glVertexAttribPointer wherever possible. There are several tools for this; the biggest is the use of BaseVertex indexed rendering. This allows you to put multiple models into the same buffers, with the same vertex formats. Then, you draw each ...


7

Basically, it's not easy to get the vertex data back from the video card once it's there. Keeping the vertex data available to the CPU allows for a number of things, here are a few: As melak47 suggests, it allows the developer to free up video memory by freeing a VBO, while being able to quickly replace the data without needing to read from disk again. It ...


7

In this code, normals are not indexed. They most certainly are. They merely share the same index as the position. What you want is not generally possible. All vertex attributes must use the same index. You must convert your multi-indexed data to single-indices per vertex. There are techniques you could use to avoid this, but they generally require semi-...


7

For small data like this, you want glBufferSubData, sweet and simple :) Later on you probably should look into glMapBuffer though, as it is how you work with data larger than a few kilobytes quickly.


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

The last param to your texcoord pointer is an offset in bytes, not floats, so it's 12 (or 3 * sizeof (float) if you prefer).


5

The thing you seem to be missing is the concept of transforming objects. A mesh doesn't have a position in the world; it's just a collection of vertex data. When you render the mesh, you transform that vertex data from its default location to a place in the world. This is what all of that matrix stuff people use does; vertex positions can be transformed by ...


5

I haven't found any literature about the modern way to do it. That's generally because the "modern way" to have character animation is to use skeletal bone weighing, not vertex blending. However, if you insist on doing vertex blend-based animation, you can. The simplest way is to simply send the two keyframes you want to blend between as the attributes. ...


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 ...


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

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 ...


4

You should have duplicate vertices on corners. That is a common practice. In the end you will have 2 vertice arrays, one for black and one for white cells. If my math serves me well - 64 vertices in each array.


4

As has been stated many, many times before, glVertexAttribPointer takes the buffer object that was bound to GL_ARRAY_BUFFER at the time the function is called. Changing the GL_ARRAY_BUFFER binding will have no effect on rendering unless you make the glVertexAttribPointer calls again.


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

You are currently putting the position data into one VBO (vertexBuffer[0]) and the color data into another one (vertexBuffer[1]). But when drawing you bind both buffers one after the other, so the second binding will just override the previous one. Then you set the pointers as if both attributes were in the same buffer. This is slightly messed up. The gl......


4

I pasted together a running version here (just for demo purposes, I hacked around your existing names and structures) Like I said, your indices were wrong. How you got your MVP matrix I don't know, but it still looks wrong, maybe you transposed it or printed it out transposed. Also, the way you used glBindAttribLocation() and glBindFragDataLocation() is ...


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