My previous post on figuring out a terrain implementation is here: https://lemmy.world/post/8540418
Player Controller used is also available ^codeberg^
I was quite upset for a long while that I could not figure out how to optimize my terrain systems. This I have now figured out.
What I am working on is three different processed terrain components:
- Topology Data (TPD) # 3D Positions of where each terrain point/node should be
- Texture Data (TXD) # Which texture each terrain point uses
- Special Data (SPD) # Special data for specific terrain points
I have finished rendering a multimesh of the topology data and it runs smoothly on my rather old computer just as I need for all my games.
The problem of mapping a collision system to the multimesh was something that I did not like attempting to solve on my previous tests from last year. I have found a solution. I misunderstood what was causing the lag and assumed collisionshapes could cause as much fps drop as meshinstances.
This system is built to load in separate parts.
- Generate terrain if necessary
- Chunk terrain data
- Render multimesh
- Instance collisionshapes for individual terrain points
My next step is either of the following:
- Connect vertex points for smooth terrain
- Create python script (or godot software) for heightmap editing and creation
- Figure out generation of single texture image to blanket over multimesh
I do intend to make this terrain destructible. I decided some at least four months ago that I would only render the terrain if an update signal was pushed either from a multiplayer server or the client side.
I will create a terrain editor for the engine sometime but that is not on the main plan. Height map conversion to TPD format will come first. Caves and underground are completely possible as well of course with the most recent commit.
This development will give me a huge step forward in all of my projects as many of them require this sort of terrain system. Also I was too lazy to figure out that one terrain plugin I suppose.
