Buffer Backed Terrain (for Bullet physics optimization)#303
Open
yahel-ck wants to merge 4 commits into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This change adds a
BufferTerrainclass which is exactly the same as the currentTerrainclass but stores the height data in aFloatBufferrather than an array.I use this to share the height data with the physics library (LibGDX's Bullet wrapper) instead of copying the height data which can cost a lot of CPU and RAM usage.
Sharing the height data with the current Terrain class is impossible because Bullet needs the data to be stored in a direct buffer, which the java array cannot be converted into.
I chose to implement this in a new class and not change the current
Terrainclass because that would be too big of a change.The changes I made in summary:
TerrainInfointerface to expose the relevant information for theTerrainMaterialwithout relaying on a specific terrain implementation.BaseTerrainclass which is a copy of the currentTerrainwith an abstractgetHeightmethod instead of a heightData array.TerrainandBufferTerrainimplementBaseTerrainwith a backing float array/buffer.I haven't changed anything editor related, so the editor still uses the original
Terrainclass and behavior is exactly the same.I personally use this optimization for in-game procedural generation.
Using this optimization in the editor and in asset loading can be implemented in a separate PR, this change is mostly useful for direct use with the Mundus runtime/commons.