raylib internal buffers (2D vs 3D)
WARNING: This implementation is no longer available,
rlgl batching mechanism has been redesigned to use a single set of buffers to deal with LINES, TRIANGLES and QUADS, it solves below mentioned issues... and probably it adds some new ones. I'll try to update this page at some point...
raylib was primary conceived for 2D game programming, but with some basic 3D support. Every new raylib version, 3D support has been improved to the point of including shaders and postprocessing effects. Dealing with 2D and 3D in an easy way required some technical trade-offs that may not be a perfect solutions for 2D or 3D, but work very well for both systems coexistence.
Three separate internal buffers
raylib creates a bunch of vertex buffers (VBO) at initialization. Those buffers are used independently for 2D and 3D drawing and are updated in a frame-basis (dynamic buffers). The size of the buffers have been adjusted for a good performance. Depending on the information stored in each buffers-group, we have:
|Usage||# VBOs||VBOs data||Description|
|Stores information for lines drawing, two vertex per line.|
|Stores information for triangles drawing, three vertex per triangle.|
|Stores information for quads drawing, four vertex per quad + 6 index per quad.|
Buffers are created at
InitWindow(), vertex data is stored into buffers with every
Draw*() function and buffers are processed for drawing on
EndDrawing(). Internally, they are processed by function
Depending on the element being drawn, vertices are stored in either
QUADS buffers. That could suppose a problem because despite including z-depth information, buffers are processed in a very specific order:
(1) LINES -> (2) TRIANGLES -> (3) QUADS
DEPTH_TEST is enabled, QUADS-based shapes will be always drawn in front of TRIANGLES and LINES; if
DEPTH_TEST is enabled, drawing is resolved as expected thanks to the depth-buffer... until we use semi-transparent shapes.
ISSUE: Alpha Blending
Due to the fact that the three buffer types are processed independently,
LINE fragments are generated before
TRIANGLE fragments, and both are generated before
QUAD fragments. For that reason, despite having
DEPTH_TEST working OK, a semi-transparent
TRIANGLES based shape in front of a
QUADS based shape cannot be blended. Similarly, a semi-transparent
LINES based shape in front of a
QUADS based shape cannot be blended. That's a problem.
ISSUE: 2D and 3D mixing
In addition to the above problem, we have 2D vs 3D mixing. We use the same buffers for 2D drawing and 3D drawing. When changing to 3D mode (
Begin3dMode()), buffers are processed and reseted to deal with 3D vertex data. Similarly, when switching back to 2D mode (
End3dMode()), buffers are processed and reseted to deal with 2D vertex data again.
Sharing buffers for 2D and 3D is simple and works OK, but presents a problem when mixing 2D and 3D:
DEPTH_TEST. 2D screen elements are drawn in front of or behind the 3D elements; we don't want that.
An issue was introduced to try to find a solution for all this problems: Issue 89
A first idea was adding additional
TRIANGLES buffers only for 3D, but it was discarded due to the extra complexity and memory usage for raylib. Considering that most of the time raylib users will probably use the library for 2D games and even in the case of using 3D, loaded 3D models are stored in separate static buffers. No need to overload the library with a new set of dynamic buffers.
After some thinking, one solution was introduced, probably not the best one, but it gives a balance between 2D and 3D drawing, depth testing and blending.
DEPTH_TEST for 2D and enable it only for 3D. The problem with this solution (a part of not having
DEPTH_TEST on 2D) was the blending between elements from different buffers (i.e.
QUADS). It was partially solved moving some commonly-used 2D elements (
QUADS usage. That way,
DEPTH_TEST and blending works OK with those elements. (Probably a final solution would be moving all the elements drawing to a single buffer type: QUADS).