Why use VBOs/VAOs/FBOs/etc?

[Zhon]

I’ve been messing around with opengl in java for a couple months (using lwjgl) and I’ve always wondered why is it important to use these complicated things.
All I’ve been doing is drawing things directly using gl primitives.
I know how to use display lists and shaders, and everytime I try to learn things like vbos, using matrices and other stuff, I drop it.

All I’ve been doing is messing around with basic games like, 2d rpg scroller, 3d simple first person shooter, simple zelda-like rpgs…
In a 800x600 display with nothing drawn, I get a fps range of ~750, when I have my game’s graphical engine ready, the fps drops about only ~30/50 fps, then when I implement a physics and logic engine, the fps decreases by 100~150, like in my 2.5d minecraft/terraria game:
http://i.imgur.com/gbVAW7w.png http://i.imgur.com/HLXitTv.png

So why should I learn these complicated stuff? Will it make my graphical engine much more efficient than just using primitives?
Sorry for my mediocre English (I’m brazilian) and thanks in advance

[theagentd]

@Zhon

In a 800x600 display with nothing drawn, I get a fps range of ~750, when I have my game’s graphical engine ready, the fps drops about only ~30/50 fps, then when I implement a physics and logic engine, the fps decreases by 100~150

First of all don’t compare FPS values like that. It’s confusing and misguiding. If you have 200 FPS and drop by 150, a frame just took 4 times as long time to render, while going from 750 to 600 is almost nothing. Instead measure time in milliseconds per frame.

I don’t think you know what FBOs are. They allow you to render to textures which isn’t relevant in your case I believe.

Considering that your game becomes slower when you add physics and other CPU calculations, it’s safe to assume that your game is CPU bound, not GPU bound. From the screenshots I’d guess you’re only drawing around ~1000 vertices per frame so you’re not vertex limited and at 800x600 you’re hardly fragment limited (fill-rate limited), so if you want to optimize it you should focus on optimizing CPU performance. This is EXACTLY where VBOs and display lists come in. They allow you to in a much more CPU-efficient way instruct the GPU what to do.

Since you’re hardly having any performance problems it’s hard to justify optimizing it. As long as you have basic frustum culling working I wouldn’t worry about performance in your case.

[concerto49]

At least for FBO it’s not just performance. You can do post processing and other stuff using it.

In terms of performance – it’s not just your PC? If you want to make it playable think about the PCs that are a lot slower out there. Some people can’t afford fast equipment but want to play.

It gets more important as you go 3D anyway. 2D isn’t as much of an issue these days.

[princec]

@concerto49

It gets more important as you go 3D anyway. 2D isn’t as much of an issue these days.

So you’d think but actually 2D is every bit as demanding as 3D still.

Well, good 2D.

Cas

[Cero]

@concerto49

It gets more important as you go 3D anyway. 2D isn’t as much of an issue these days.

@princec

@concerto49

It gets more important as you go 3D anyway. 2D isn’t as much of an issue these days.

So you’d think but actually 2D is every bit as demanding as 3D still.

Well, good 2D.

yep, absolutely not true, due to the nature of what you do in 2D, its a lot to push to the gpu.
Good 2D, like muramasa or rayman origins, with many layers and stuff, is even more hard to do fast than 3D games… well if its not cutting edge 3D stuff

[relminator]

With the same amount of fragments, 2d should be slower than 3d.

We usually draw from front to back in a 3d scene with znear being as far from z0 and zfar as near as possible to reduce fillrate.

You can’t do that in a 2d scene since you always have to draw from back to front.

Of course, there are some cards that can optimize back to front rendering but they are quite new.

Sorry, replied via phone.

[theagentd]

@relminator

With the same amount of fragments, 2d should be slower than 3d.

I sample 5 textures, transform normals from tangent space to object space and write to two RGBA16F textures per pixel. 3D games usually require much more complex shaders, much more bandwidth (in the case of deferred shading), more anti-aliasing and higher screen resolutions. Even with early-Z optimizations, we still get massive overdraw for lighting and post-processing.

[relminator]

@theagentd

@relminator

With the same amount of fragments, 2d should be slower than 3d.

I sample 5 textures, transform normals from tangent space to object space and write to two RGBA16F textures per pixel. 3D games usually require much more complex shaders, much more bandwidth (in the case of deferred shading), more anti-aliasing and higher screen resolutions. Even with early-Z optimizations, we still get massive overdraw for lighting and post-processing.

,

The same amount of “simple” non-transformed fragments.

[theagentd]

@relminator

The same amount of “simple” non-transformed fragments.

Then why?

[Roquen]

@relminator

You can’t do that in a 2d scene since you always have to draw from back to front.

No you don’t. Any cases where you might choose to render back-to-front are identical in 2D and 3D (say transparency and you don’t want to be fancy about it).

[Riven]

@Roquen

@relminator

You can’t do that in a 2d scene since you always have to draw from back to front.

No you don’t. Any cases where you might choose to render back-to-front are identical in 2D and 3D (say transparency and you don’t want to be fancy about it).

Isn’t that the whole issue at hand? In 2D you’re expected to have every sprite nicely translucent at the edges, whereas in 3D you can get away with your typical antialiasing, defining shapes not by transparant pixels in sprites but by geometry.

That’s the single reason good 2D games are prone to be suffering from overdraw, caused by mandatory back-to-front rendering.

[relminator]

@Riven

@Roquen

@relminator

You can’t do that in a 2d scene since you always have to draw from back to front.

No you don’t. Any cases where you might choose to render back-to-front are identical in 2D and 3D (say transparency and you don’t want to be fancy about it).

Isn’t that the whole issue at hand? In 2D you’re expected to have every sprite nicely translucent at the edges, whereas in 3D you can get away with your typical antialiasing, defining shapes not by transparant pixels in sprites but by geometry.

That’s the single reason good 2D games are prone to be suffering from overdraw, caused by mandatory back-to-front rendering.

This and the fact that you can upload static models on the gpu then optimize rendering further by using strips. 2d scenes are usually done with tris and vertex arrays.

[theagentd]

[quote=“Riven,post:11,topic:41626”]
I’m pretty sure 4x MSAA is more expensive per pixel than enabling blending, plus you have the MSAA resolve overhead.

@relminator

This and the fact that you can upload static models on the gpu then optimize rendering further by using strips. 2d scenes are usually done with tris and vertex arrays.

Strips are slower than indexed rendering on most OGL2+ hardware, so there’s no real difference to 2D here. Besides, you’re usually not vertex limited in neither 3D nor 2D if you have proper culling (and LOD for 3D) in place.

It’s actually possible to render 2D front-to-back with correct blending. This requires an alpha channel in the frame buffer though, but may have slightly better performance since your GPU should be able to avoid a ROP write for occluded pixels, but I haven’t tested it.

EDIT: Also, some people seem to be under the impression that an occluded pixel (= a pixel that failed the depth test) is free. This is not the case, but an occluded pixel may be cheaper. At best, the depth test is done before the pixel shader, and the pixel can be culled before the pixel shader is run, giving it a constant cost regardless of how expensive the pixel shader is. However if the alpha test is enabled, the pixel shader modifies the depth of each pixel or the pixel shader calls [icode]discard;[/icode] somewhere, the decision to cull the pixel has to be done after the pixel shader is run, in which an occluded pixel is just barely cheaper than a non-occluded pixel.

[Roquen]

[aside mode]
The discussion of which is harder: 2D vs. 3D is somewhat silly. Using only a small handful of “state-of-the-art” techniques for either will throw you way over a highest end consumer GPU configuration cycle budget. So like pretty much everything: it depends.

Wouldn’t you guess that most 2D games that do indeed render back-to-front still get it wrong by not appropriately using precomputed alphas? And also that in a fair number of these cases that the “defect” goes unnoticed because it’s not pronounced enough and/or simply because people are used to rendering that’s wrong? (Likewise in 3D with rendering in gamma space and the tv/movie “effect” of night looking like a blue filter…which it doesn’t…we’re just used to being shown very defective images).
[/aside mode]

Back on my point. My issue is with the words “always” of relminator’s original statement and Riven’s “mandatory”. This kind of thinking is self fulfilling. If you thinking you “can’t”, you’re right…but that doesn’t mean you “couldn’t”. Always back-to-front is certainly the easiest to code. In a fair number of cases it may well indeed be the best solution.

Trivial counter examples. Visual design is based on classic console hardware: some number of tiled background planes with priorities mixed with some number of prioritized sprites. I’ve certainly seen games with multiple backgrounds which are behind all sprites. Back-to-front rendering obviously isn’t required and these logical layers can be rendered in a single pass. Likewise this can be partially extended to other background planes formed from logical layers (with of course the tricky part being edges). If it’s common that these further forward background planes have reasonably large opaque real estate then minimally one could render all opaque tiles front-to-back and in a second pass render all transparent back-to-front…in other words, the classic solution one would do in 3D. It seems pretty common to see games logically based on even older hardware, which only support color-key transparency. Assuming proper sampling and the only allowed scale factors are integers. Alpha-test and render front-to-back. I haven’t thought deeply about this but it could be feasible to extend this sprites/tiles with full alpha range: first pass renders fully opaque texels front-to-back and a second pass draw the same geometry back-to-front (again with alpha-testing). Win/Loss? No idea…wild hare thought and certainly scene type and fragment shader complexity dependent if it ever is. Other thoughts: various order independent transparency techniques could be considered, such as various flavors of depth peeling.

[theagentd]

In case anyone’s wondering, front-to-back blending is around 25-30% faster than back-to-front blending in my test. It all depends on how much overdraw you have and how transparent your pixels are. If everything you draw is 50% transparent, it won’t be much faster. If most pixels are opaque (for example sprites with anti aliased edges), you can get a lot better performance with front-to-back blending!

[RobinB]

3D rendering is harder for humans i guess, adds an extra dimension to think of.
Since you’re talking about front to back rendering, give some samples so we can see for ourselves

[Zhon]

Wow oh wow, I got flying in this conversation :yawn:
So, in a 2D game it is better to draw things using vbo/vaos instead of imediate drawing?

[RobinB]

immediate mode is never an good solution in opengl (except some testing / debugging) since its depricated anyway.
vbo’s and vao’s speed up your code, and forces the programmer to program some clean drawing code.
So at least you will get cleaner code and faster drawing (much much faster).