Hot answers tagged vbo
20
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 ...
19
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, ...
16
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 ...
13
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, ...
10
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 really a choice between performance and flexibility, but I'll list my opinions about it.
One single VBO
The positive sides are:
Just one draw call to draw your scene. This increases performance. Although your application may require multiple draw calls, you can still have a single VBO and let the count and offset decide your drawing.
Not ...
6
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 ...
6
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 ...
5
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 ...
5
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 ...
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
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 ...
4
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 ...
4
Answer 1:
Of course you can, without texturing capabilities vertex buffers would be next to useless. A VBO is just a chunk of binary data with the format you specify (position channel, normal channel, texcoord channel, etc.) that gets interpreted by a shader. When drawing an object, you are telling the GPU to fetch that batch of data and apply the ...
4
I think you want to change your attribute pointers, specifically the offsets you have listed. &vertices[0].position should be 0, &vertices[0].uv should be 24, &vertices[0].normal should be 12 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. ...
3
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.
...
3
For dynamic, animated objects reducing draw calls is not that easy as much data is required for each instance. You can pass multiple transformations at once as long as you have constant registers left and use GL_ARB_draw_instanced to let opengl draw the VBO multiple times with an automatically incrementing instanceId that you can use to access the ...
3
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.
2
Saving it as a very simple text format or binary (wavefront obj is a common one) and then parsing it in the usual way. This is exactly the same as any other data parsing task. A vertex buffer object is essentially just an array of data that's held in video card memory. You'll probably want to read the data into system memory first and then convert it to a ...
2
Your first problem is here:
gl.glBindBuffer(GL4.GL_ARRAY_BUFFER, 0); // With out this line my code throws the exception
That's unbinding your buffer object before the glVertexAttribPointer call. You need to have a buffer bound in order for that to be a reasonable call. It's the combination of having a buffer bound to GL_ARRAY_BUFFER and calling ...
2
glutInitContextFlags(GLUT_FORWARD_COMPATIBLE | GLUT_DEBUG);
Never, ever, ever, EVER use FORWARD_COMPATIBLE for ANYTHING.
If you want a core OpenGL context in FreeGLUT, ask for it with the right function:
glutInitContextProfile(GLUT_CORE_PROFILE);
You never need the FORWARD_COMPATIBLE bit set. I know that a lot of code does it, and if I could, I would ...
2
Personally I'd say try it and see. You may get better performance during that 70% to 80% of the object's lifetime, you may not, and much of that will depend on how well (or not so well) your driver and hardware handles VBOs used in this manner (and - of course - whether or not this part of the pipeline is actually a bottleneck for you; it may not be, in ...
2
Some observations:
First, there's no error checking in the code.
The obj loading seems incorrect.
The vertices are copied into mesh.vertices (l. 212-214 in BlockRenderer). Using the DefaultCube, mesh.vertices contains 12*3 vertices, and the index buffer 36 ints.
Problem seems that the indices reference into the original verts array and not into ...
2
Searching through 5000 elements every time you add a element could already become a CPU bottleneck. You are dealing with real-time graphics here, so if it takes a few ms it's already too much. Iterating over 5000 elements is probably much less than a ms, but iterating 5000 times over up to 5000 elements quickly adds up. Say iterating over 5000 elements takes ...
2
You might want to take a look at sparse voxel octrees and you should be able to find some implementations.
You want a dynamic VBO. Every frame, you work out which boxes in the octree you want to draw, calculate the position of the box's corners, add them to the dynamic vbo as vertices and create a supporting index buffer to detail which points join to which ...
2
the problem didn't come from the part of code I showed you.
I just read some doc and found the problem.
To have Qt and OpenGL working together properly, you have to set an OpenGL context.
But you have to make sure that you set it before any call to an OpenGL function (or at least a drawing function i guess). So, to have it working, I just added a line in the ...
2
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 ...
2
Functions such as glVertex are marked as deprecated in modern OpenGL and don't even exist in OpenGL ES, so indeed VBOs are preferred way of drawing static and dynamic objects.
If the data is not changing you don't need to send it to the GPU every frame - instead you do that once (e.g. at the beginning of the level) and when the time comes bind the right VBO ...
2
This is not a simple question - but the philosophy is simple - seek out like things and bundle them together so that the pipeline never starves for data nor stops to change gears.
Secondly, do NOT create the same thing again and again - if you have a cube, build the vertex buffer and index buffer once - use instancing, and use the world matrix to change ...
1
Common issues I've seen with VBOs usually center around the stride length and setting the correct byte offsets for the vertices, texture and normal coordinates. Make sure you're using the correct values for the stride length. It's usually easiest to set these to constants since you know they're unlikely to change.
Only top voted, non community-wiki answers of a minimum length are eligible
