Replies: 1 comment
-
Copy paste from #89 Currently we have a lot of vertexbuffers for all sorts of different things. This causes a lot of lag when spawning or loading & updating chunks. All of these operations need to be executed on the UI/Rendering thread. To fight this we should reduce the amount of allocations & updates. For example: Chunks have multiple vertexbuffers, 1 for each renderstage required. (Renderstages seperate different block types like translucent, animated or solid blocks) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
VRam
These are some concepts/ideas i could come up with to reduce the amount of memory used on the graphics card.
Terrain data
We can reduce the amount of memory used by terrain data by removing "duplicate" vertices and instead using an indexbuffer to point to vertices. Now imagine minecraft's terrain, most of the terrain is matching terrain. Think of the planes biome for example, most of the blocks there are grass blocks. Every single one of those stores 4 vertices per visible face. For all of these matching in both texture and position we remove atleast 1 vertex from memory and replace it with an index in the indexbuffer.
Imagine we have a 16x16 area consisting only of grass blocks. (2 dimensional, for easier calculations)
Lets calculate the vertex count for this area.
Vertex count: 16 * 16 * 4 =1024
Memory usage: 1024 * 32 = 32768 bytes (Assuming a vertex takes up 32 bytes of memory)
Now we know that on the perimeter blocks we can only save 1 vertex for every block. So lets adjust for that.
Vertex count: 1024 - (16 * 4) = 960
Memory usage: 960 * 32 = 30720 bytes
Great! That is reduction step 1.
For every other block we can remove 1 vertex for every corner because the neighboring blocks can provide that info for us. So that's a total of 4 vertices for every other block. Awesome!
Vertex count: 960 - (15 * 15 * 4 ÷ 2) = 510
Memory usage: 510 * 32 = 16320 bytes
That is about a 50% reduction in memory used for our 16x16 grass area. That's not bad!
(16320 / 32768) * 100 = 49.8046875%
Now, we can even keep this in mind when we are generating the vertex data for a block. If all neighboring blocks are the same and they do have vertices assigned to them, we can skip the vertex calculations for this block and just point to the neighboring block's vertices instead, thus save some precious cpu time as well!
Another benefit besides using less memory is that the upload to the gpu will take less time, thus resulting in a more stable framerate.
Entities
For entities using the same model we can skip the vertex calculations and only store the rotation and positional data for each bone.
We can apply the same logic to entities that share the same texture, re-use and thus reduce memory usage.
This comes with the extra benefit of not having to send any resources for this entity to the gpu, thus we don't need to block the rendering thread resulting in more stable framerates.
More information about this method of entity rendering can be found in #105
Textures
We can reduce the amount of memory used for terrain textures by improving the texture atlas generation. They currently have a lot of unused areas.
Ram
Need to investigate what is currently eating up all the ram first...
Beta Was this translation helpful? Give feedback.
All reactions