redferret / planet

A simulation that simulates geological processes as well as hydrological, biological, and other complex systems that can exist on a planet

Planet

planet's Issues

Hydrosphere

Since the resolution of the planet isn't going to be such that rivers can form easily, instead the current model for erosion is good enough, more testing should be done along with possible visualization of dissolved sediments and sediments that are being transported.

1. Hydrosphere needs at least two layers for convection to happen, salt and fresh water help drive this system.
2. Hydrosphere will erode and deposit sediments and move water, may be best to implement water movement in the Geosphere to this system instead.
3. Hydrosphere needs a temperature for both layers. Motion of air currents drive surface water creating currents.

Stack Overflow in GeoCell - [probable]

The GeoCell, on line 461, will sometimes enter a large recursive call loop and cause a stack overflow. The reason is unknown.

Fast Hydraulic Erosion Implementation

The simulation's current erosion algorithm is very poor. We are going to implement the fast hydraulic erosion algorithm as show in this PDF or this PDF

Testing Requirements

• When the Simulation is ready to be built on the current framework, ALL functionality must have a unit test associated with it.
• TestWorld must be used as a way to test certain Tasks and processes with unit testing.

Geosphere

The Geosphere needs to be able to do the following

1. Plate Tectonics
2. Rock Formation (Sediment to Sedimentary) and (Sedimentary to Metamorphic) etc.
3. Add to either the GeoCell or Stratum the ability to have ground water.
4. Movement of groundwater - May need to implement a design that can easily move water based on how much water is in a layer and what layers can have water. For instance solid rock isn't solid, it's mostly cracked allowing water to quickly move through and into other sedimentary layers that act as a slow absorbing sponge.
5. Volcanic Activity due to hot intrusive rocks or extrusive volcanic activity.

Architectural Design Requirements

The framework is based on Tasks which perform algorithms that work on that data stored in the SurfaceMap.

How Tasks should be built

• Each Task associated with a Surface (Geosphere, Hydrosphere, ... ) must be private and nested as an Inner-member class and extend the actual Task in another file to organize code.
• Each factory must have a resource that can't be shared between all threads (i.e. Delay objects). This means that factories are useless to produce tasks with no resources, (member variables).
• Constructors in Tasks can be used but only to initialize certain data. It's recommended to use the 'construct()' method instead especially for using sub tasks.

Resources

• Resources should always be released if multithreading is being used.
• Never check-out more than one singleton resource, always wait for a set of resources

Commenting
ALL methods, Tasks, or classes must have Java Doc written unless the method, Task, class, or Test is eloquent enough to do without the Doc description but parameters must be described.

Also see Architectural Design page

Biosphere

Implement the Biosphere

Atmosphere

Implement the Atmosphere

Metamorphic Task

Even though implementation hasn't started the task that creates metamorphic rock is broken and causes threads to starve. Infinite loop is probably the reason.

Add heat map

Randomly distributed heat will cause heat to build up more so in certain places below the crust. The hotter the material is below the crust the higher the probability will be for an x amount of lava to be added to the surface. Also the hotter the faster it loses heat, volcanoes result in major cooling.

1. Heat is applied randomly to each cell.
2. Probability variable updated
   1. Check for a volcanic eruption
      1. Lower heat
3. Remove heat based on the current temperature

Add to project, basic volcanoes

The simulation is now at a good start to place random volcanoes. The system needs more unit tests as well.

Change Views in BasicJView

Add the ability to change what can be seen on the surface.
Something simple:
Page up - Cycle up the images being drawn
Page down - Cycle down the images being drawn
Home - Cycle through different views (won't change when cycling up or down images

Planet class

The Planet class no longer needs to be abstract. The two methods initPlanet and setupThreads could easily be called inside the Planet constructor removing the need to extend the Planet class.

Geosphere Implementation

Implement the Geosphere:

• Plate tectonics
• Time scales
• Metamorphic Rock
• Volcanoes

PlanetObject in SurfaceThread

The PlanetObject is not abstract enough to be siting in the SurfaceThread. This should be removed or changed

Decouple SurfaceThread minimum height check

The SurfaceThread needs to have it's updateMinimumHeight method moved into it's own Task to preserve the abstraction of the SurfaceThread

Implement OGLDisplay

The OGLDisplay needs to be built up and implemented into the project. This object will be similar to the BasicJView class it will just render using OpenGL rather than using Java graphics.

GUI

Create a GUI for the Planet simulation

Display transition bug

The BasicJView contains a bug that doesn't seem to create a bounds for changing the views; after switching to the mantel view, continuing to press page-up then pressing page-down, the view doesn't switch back to the strata view.

Cell corruption

There is a problem still with having multiple threads working on the surface that causes some cells to become corrupted, typically only at the edges of each thread's boundaries and more specifically through the center horizontally if using 4 threads on a relatively small map (64x64).