Engine System Update #1
In designing and creating my terrain generator, I will be using these updates for two purposes. Purpose one is to meet the requirements of the project. Purpose two is to use these updates as a means to plan out my thoughts as I work. That being said, these updates will be living documents that will be updated as I work.
Update 1 Goals:
Research and plan how I plan to generate terrain. SUCCESS
Plan out initial inputs in Lua file and how I plan to generate terrain. SUCCESS
Set up Terrain builder project similar to geometry builder. Whereas the geometry it generates will be just a simple plane for now. SUCCESS
Set up initial Lua file, with thought out inputs. SUCCESS
Set up initial class and handlers for reading in the terrain geometry (Similar to standard geometry probably). This is to get to a testing phase, the interface of using terrain can be thought out more later. FAILED
Terrain Generation Plans:
To simplify the terrain generation process, I will tackle the whole process in a series of steps. Each step adding on complexity to the whole terrain generation process. The end goal of the project is to have a easy to use terrain builder that can build terrain geometry binaries into an engine for a user to use.
Generating a basic square plane of two triangles.
Subdividing that square via width and height inputs
Create a working Perlin Noise algorithm to dictate a height map via X and Y coordinates.
Implement that Perlin noise algorithm into the subdivided square to get a terrain with a basic height map.
Add vertex coloring for different heights.
To be planned when I get there….
Initial Inputs For Terrain Lua File. You can see me initial lua file shown below:
Terrain Plane Width
Terrain Plane Height
Subdivision Count Width
Subdivision Count Height
Max Altitude of Terrain
Perlin Noise Seed
Initial Lua file
Terrain Builder Interface. For now.
Geometry Terrain File:
Building the geometry terrain file. I figured that all this would have to contain is the pure geometry of the terrain. Generating the terrain during run time would be too expensive to do. That being said. The terrain binary is practically the same format as my geometry type. However, because I can’t expect other users to have the same geometry format as I do, I can’t expect that they would load such geometry files the same way.
My current plan is to create a very simple interface that lets the user extract the geometry data from my terrain binary file. The user from that point should be able to load the geometry into their own game object very easily to display the terrain. What do you think of this? Does this sound valid before I do it? I was planning on implementing this by next update.
Accomplished Points:
Got lua file set up
Got Terrain Generator Project Set Up
Got basic binary creation set up with asset build process
Got a plane showing up. (I used my geometry to display the terrain because they are practically the same format)
Questions:
My question up above if taking that terrain extraction approach sounds good.
If I am meeting requirements for this project in general, with what has been described so far.
Goals for next time:
Due to changing projects halfway through, I lost a good amount of time that I’ll have to double down next update. The goals for next update:
Vertex color optional challenge in the past. (This is to better visualize the terrain)
Perlin Noise implemented algorithm.
Perlin Noise generated terrain
Basic Terrain Geo Extraction Class for runtime