I am rendering around 5000 objects. My mesh class (http://pastebin.java-gaming.org/b35985a9848) which loads .obj files and creates a VBO for them is only instanced once (it loads Cube.obj), then the draw method is called whenever one of these object's update method is called. I gained a bit of performance by moving the buffers to the objects and only updating them if the objects position/orientation changes. Am I just doing it wrong?

Also if you could tell me how to change the loading code from BufferedReader(Faster for line by line) to Scanner (Faster for parsing).

On my test rig (Testing on low end first)AMD Athlon 2 1.6GhzRadeon x12003GB RAM6-10 Frames per second (Using my own and TWL's counter)When profiled with netbeans (Game loop commented to not loop) glDrawArrays is 1056 ms (51% of the loop time).Edit: I run at 60FPS when glDrawArrays alone is commented out.

My main computer, built for gaming runs it at the capped 60 (3Ghz Phenom II, Radeon HD 4870, 4GB RAM).It does have shaders but it's a simple proj*model*view*vertex glFrag=1,1,1.I would like to run this on low end systems better. I'm not very good at optimization.

Your GPU is really slow. If that's the bottleneck there's not much you can do except draw less. Luckily (?) your CPU seems quite slow too, so hopefully that's the bottleneck at the moment.

I think you've misunderstood how vertex array objects work. glEnableVertexAttribArray() is also supposed to be stored in the VAO when you create it, not enabled and disabled manually each time you render.

Since you're drawing lots of the same object, you should bind the vertex array only once, then call glDrawArrays() as many times as you need instead of rebinding it before each draw.

He's using one VBO per vertex attribute, so passing in stride=0 and offset=0 is valid. They're only relevant when having multiple attributes packed in a single VBO. - Stride is the byte distance between each element. Here you'd pass in how many byte each vertex takes. Passing 0 tells OpenGL that the data is tightly packed. - Offset is simply the first byte index OpenGL should start reading from.

For a VBO only containing a vec3 position and a 32-bit RGBA color for each vertex, you'd set up the attributes like this:

Your code might indeed by CPU limited. How many times is calculateModel() called in Matter? The fact that calculateModel() is called from setPosition/Rotation/Scale() is a bit worrying. That code might be run 3 times per update or more if you move your objects around a lot.

A simple test you can do to determine if you're CPU or GPU limited is to simply comment out glDrawArrays() in Mesh.Draw() but leave everything else intact. If the program runs at almost the same speed as before, you're CPU limited. If you get a big FPS boost, you're GPU limited.

Thanks. I wasn't sure how to explain that properly so thanks for filling in, Riven. ^^

IMHO the (C) specification of that method is really poor, as 'a stride of zero means the data is tightly packed' implies that stride means the space between data of the same type (either vertices, texcoords, normals, etc), which is clearly not the case.

* Riven is not impressed.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Ok so it's my GPU not my code that's causing it to be slow? (Commenting out glDrawArrays brought it up to the 60 cap)Nice to know. Also nice explanations of vertex buffers. So with vertex buffers you can calculate exactly how many bytes you want to buffer to the shader, and separate them into attributes?

Ok so it's my GPU not my code that's causing it to be slow? (Commenting out glDrawArrays brought it up to the 60 cap)Nice to know. Also nice explanations of vertex buffers. So with vertex buffers you can calculate exactly how many bytes you want to buffer to the shader, and separate them into attributes?

I think it's safe to assume that it's GPU limited. Too bad I guess, since that's much harder to optimise it. You should disable Vsync though so you can measure uncapped FPS values.

One thing you can try is to reduce the screen resolution. If that improves the FPS it means that the rendering is fragment limited (AKA fill rate limited), so using a lower resolution will increase performance. If there's no difference, your program is vertex limited (you're drawing too much small geometry). In that case the only solution is to reduce the number of vertices, e.g. reduce the number of cubes.

Ok, at native resoultion it is the same frame rate so it's just the video card being weak, not me. I only used that ObjLoader because it was the only one I could find that worked, and I have no idea how to do it myself (What's an indice?). I do not have much experience with this stuff (learning from trial and error, which means if it works I use it). This forum is friendly, quick, and helpful; I think it will become one of my go to places. Thank you.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org