As the final project for the AR/VR course, we were given the task to design a prototype that simulates surviving on Mars. Our team has developed a VR app which simulates farming in greenhouses on the red planet. If humans are ever to settle colonies on our neighbouring planet, the logistics of food, water and air will have to be handled. Through our research, we believe we've found a good basis on how such a colony could be fed, and what kind of crops provide the best oxygen/food/water ratio.
The goal for the final product is to both educate users on what kinds of crops are viable to grow on Mars, as well as how to run such an operation efficiently and sustainably. Our prototype features the groundwork of the vision we have for the finished application.
During production, we've strived to stay scientifically accurate when it comes to environment, crop requirements and human requirements. We've calculated the amount of water needed for each plant, how much oxygen crops produce per day and how many crops it would require for our population. This data has then been added to a causal loop diagram to simulate how the systems on Mars would operate. This section will present that data to you.
Mars is famously a barren planet of dust and rocks, having nothing that could qualify as soil. Earth soil consists of 45% minerals and a varying composition of organic material, water and bacteria. Mars however is covered in a layer of oxidized iron dust, which gives the planet its' famous red hue. This dust also contains other nutrients like sodium, magnesium and potassium, but not enough to support growing plants. No wonder mars has no vegetation!
But there are ways to make our own soil that is able to sustain plant life. The most important elements for plant nutrition is nitrogen, phosphorus and potassium, with sulfur, magnesium and calcium being secondary in importance. Martian "soil" already contains magnesium and potassium, and there exists water frozen on Mars which could help hydrate the soil. But we would need at least 2 of the 3 important elements to support plant life, where do we find those elements?
That's right. Human feces contain our remaining elements phosphorus and nitrogen, and have been used in agriculture for centuries. While there can be health risks to using untreated human feces as fertilizer, the process of drying it out removes the risk of parasitic or bacterial infections while still preserving the necessary elements for fertilizing soil. A toilet system on the Mars colony could be made to reclaim as much water as possible from human waste, and to process the remains into usable fertilizer. The ISS orbiting earth already recycles water with a 98% water reclamation rate, so the technology does exist. And with careful use of water in the greenhouses, the whole system should stay sustainable, with additional water gathering available in martian permafrost.
A martian colony would require as much reuse as possible to stay sustainable by itself. Sending supplies from Earth is too costly and take too long to arrive, which is why the colonists would have to live by 'Waste not, want not' to survive.
So we've already talked about the water reclamation system used on the ISS, but this only reuses the water already found within the system. What can be done to get enough water to get the colony and farm up and running, without having to resort to expensive cargo transports of water from earth? Well, we just dig it up.
During unmanned missions on Mars, there has been discovered permafrost 1-3km thick all over the planet. During a study conducted by NASA, they concluded that using microwave technology it was very simple to melt the permafrost and make water for any potential colonies. Using small unmanned crafts, we can collect bits of permafrost and bring it into another facility which melts the ice, filters it and introduces the water into the system.
Mars is a harsh environment to grow in, even when supplemented with our state of the art fertilizer. So the crops we elect to grow have to be robust generalists that can survive without specialized growing conditions. They also have to provide nutrition to our colonists and have to provide adequete oxygen production through photosynthesis.
Undergraduate students have, in collaboration with NASA, attempted growing various crops in simulated Mars like soil, and found that various crops grow surprisingly well and taste almost no different than their terrestrial counterparts. As long as the soil is kept hydrated, maintaining a consistant 50%-60% humidity rate, crops like potatoes, carrots, onions, kale and garlic could grow like regular. And while sunlight is only 43% as strong on Mars as it is on Earth, it is still strong enough to support photosynthesis in leafy crops.
Photosynthesis only requires sunlight, water and carbon dioxide, and works optimally when the plants get some hours of dark to rest. Optimally, crops in the greenhouses would produce oxygen for 16 hours, supplementing sunlight with growth lamps when needed. Plants would then get the remainder of the martian 24,5 hour day off in the dark to rest.
So we've solved the questions of plant growth, fertilizer, air, food and water. But all of this requires power! How would such an operation stay powered on?
In most martian colony models, the use of solar power is very common. Relatively cheap when set up properly, and infinitely available. Though as we stated earlier, sunlight is only 43% as strong on Mars as on Earth, so the power generated from solar power would be very lacking compared to the yield on Earth. Additionally, Mars' surface is very prone to dust storms, so the panels wouldn't produce any power during a storm or even at night.
Nuclear power would provide a constant flow of power during any part of the day. Radioisotope Thermoelectric Generators, or RTGs, have been used for unmanned missions to mars to power rovers, but would have issues providing enough power to en entire colony. Though they would still be useful for small unmanned crafts performing tasks on the martian surface. Such as small diggers that can dig up martian permafrost, and bring it back to be used in the colony.
Kilopower Heat Pipe reactors however, using fissile uranium, produce a lot of power and a lot of heat. As such, using one would greatly benefit the colonies since the power it would provide is sufficient, and the heat it gives off can be used in addition to the colony heating system to keep the colony's temperature at a comfortable level. The downside to these generators however is that the fuel they require isn't readily available on Mars. Though it might be possible to find fuel through mining, there is no guarantee. As such, fuel for the generators would have to be shipped to mars when required. But nuclear fuel lasts a very very long time, so refuel runs like that would not be required often enough to be an issue.
Therefore, we propose a combination of solar power and nuclear power to keep the colony running. Solar power, while weaker on Mars, is still a semi permanent energy source, and nuclear power is a long lasting energy source which works around the clock. Together they could make up for eachothers differences and would be safer in case one experienced a problem.
Our prototype follows very accurate data and values, calculating the correct amount of hydration needed for each variation of crop, how long they take to grow and how much oxygen they produce. We simulate the needs of 20 colonists, the power generation and usage of the whole colony and the water reclamation and mining operation.
To make sure our project simulates a sustainable, balanced system, we employed the use of system analysis and dynamics to read the output of our farming simulation before developing the prototypes themselves. This work consisted of identifying relevant factors that would impact the system and factors that impact the factors. This is all tallied up in an item table which keeps track of items in our system and the actions and controls that influence them. Additionally, since we can't know every small detail and miniscule change, we make assumptions relating to each item to keep the system going.
To further track each item and make sure each control we've added makes sense, we then make flowcharts that follow each item. This way we can keep track of where the items are at each step of their journey, and if there are any oversights we've made. In these flowcharts, the segments within boxes are called Stocks, which is where the item is stored within something. The segments with no boxes are called Actions, and describe when the items transfer from one stock to another.
Finally the flowcharts are converted and plugged into the causal loop diagram, which represents our system as a whole. Reading this, we can see read through loops how different factors interract with eachother. These loops are either marked with a B or R based on if the loop is balanced or reinforcing.
A balanced loop keeps itself in check and doesn't spike out any part of the system. a balanced loop has at least 1 positive arrow and one negative arrow, and never an even number of negative arrows as that would cancel them out. A reinforcing loop has either only positive arrows or an even number of negative arrows. These loops have the potential to spike out a system, meaning that when they start going in one direction, they keep going in that direction. It's important that reinforcing loops are kept in balance by having them rely on factors within balanced loops so that they don't spiral out of control.
To read a CLD, it's easiest way is to first pick one of the bolded items, and follow the actions around the loop. After reading each loop, you'll understand the system as a whole.
Our system analysis determined that the system we had in place would result in a sustainable operation, and would be prime for further simulation.
We wanted to design an app that was educational and fun to use, while being intuitive for everyone. As such, we designed the application to use hand tracking so that it would be easy to pick up and play for users who were not familiar with VR. We also wanted the style to be low poly, saturated and cartoony. This was mainly to keep the visuals appealing, but also to reduce performance issues that might occur with highly detailed models.
To prevent the user from teleporting around, we place them on top of a platform overlooking the greenhouse while little robots drive around and keep watch on the plants. The robots will then send warnings to the user if they detect anything amiss with the crop they are inspecting, letting the user decide what is the best course of action.
Our original prototype was made in ShapesXR to provide a look at what we imagined the app could be. Shapes let us create a VR based 3D slideshow which took the user through a simple playthrough of the application, letting them interact with the UI, fix issues and harvest crops. this was all recorded and made into this demonstration video.
Staying true to our research, the prototype simulates the growth of plants within the greenhouse as well as the daily use of food, water and oxygen for 20 colonists. While speeding up how long each day lasts to prevent playthroughs taking many months, every other value is in line with data found in research. Each different crop type has its' own target hydration level, provides differing calorie amounts and has it's own crowth cycle. The simulation is also easily scalable, with fields adapting crop spawning based on size and time scaling being easily edited. While not implemented in the current prototype, it would be very simple to add a way to change how long each day lasts during simulation.
Each aspect of the farm's code works through layering each part of the farm from the individual plants, to their fields to the farm itself. The farm tracks each day passing, telling each field a day has passed. The fields keep track of their hydration and checks if individual plants have become blighted through overhydration. The farm also tracks oxygen production and usage, as well as water use and reclamation. All of these values are viewable on the holoscreen found on the desk inside the simulation.
To keep the prototype intuitive to use, we don't use controllers in the prototype. We instead use hand tracking to make it less daunting for users who aren't familiar with VR controllers. Using Meta building blocks for hand tracking, we have UI buttons and scaling movable UI panels that feel good to use and follow spatial design methods. By pinching their index fingers on each hand close to eachother, the user can bring up the UI and scale it to their desired size. When released, the UI panel will stay at the same size in the same spot where it was placed. When pinching their fingers again, the UI instantly transports to the users hands and is able to be scaled again. If the user wants the panel gone, simply scaling it down by bringing hands together will hide the UI from view.
The little robot AI uses a simple AI navigator and navmesh to travel around the world. We added a couple modifier volumes to prevent the robots from always walking across the fields, having them prefer to use the flooring between when possible. Upon arriving at a field, the robot picks out a couple crops and wanders over to them while performing their check. If the field contains an issue, the robot pings the player with a warning which they then resolve through the UI panel.
To save on performance, most code is event based on a set timer. Most code is only called whenever a day passes, and is set up to instantly trigger a return if there is no reason for the code to run. Using enumerators to timegate these events, we save a ton of memory which would be dumped if we were calculating time through delta time every frame.
To reach our goal of minimum 72 fps on the standalone prototype, we had to rework some assets.
Each object in the scene has a maximum of ~3000 triangles, or 1500 quads. Staying with as few polygons as possible while keeping the visuals appealing assures a better experience. Every object in the scene is also marked as static, with the exception of the robots and the scaling UI. Static objects cannot change during runtime, so therefore the program doesn't have to allocate as much memory to each object. This also affects lighting, since the baked lightmaps apply best to static objects.
Baking lightmaps is also more efficient, as baked lights do not use up memory to constantly tell the shaders if they are lit or not. Originally we wanted to have the sun rotate around to show the passage of time, but use of realtime or mixed lights was too taxing, we opted to keep the light constant and baked.
We also swapped from using 3D models on the plants to using cross-sectioned quads, effectively reducing poly count per plant from 600 to 8. The plant texture was also set to a particle, so that it was not lit but rather had a slight emission to still be visible when in lower light areas. Plants are instantiated during runtime, so they are never baked onto the lightmap. Therefore, a lit texture is not required. Particle textures also take up less memory, since they don't have as many channels as a regular texture. We only needed the albedo and alpha channels, and those are exactly what the particle texture use.
Next, each texture we used was set to a maximum resolution of 1024px, and most objects in the scene actually just uses colored material. Most of these materials are also set to unlit to save on memory, but some that are affected by shadows are set as lit. Most objects are far away from the user during play, so they don't need the extra details, and 1024px provides enough detail for our prototype.
Finally we implemented occlusion culling so we don't render objects that aren't in view of the camera. There is no reason to use memory on objects the user wouldn't be able to see anyways, and occlusion culling cancels the draw call for each occluded object.
We prototyped a simple playthrough of the simulation using Bezi to create an easily sharable concept. The web version uses the same assets as the prorotype APK, and shows what interactions can happen during play.
The web based prototype can be tested here; https://bezi.com/play/8f3fd9e3-c2b5-4f6b-b09b-dedfe3e9a0cd
Our standalone prototype was developed for Meta Quest 2 in Unity. While taking care to stay as scientifically accurate as we can, it provides the experience we set out to create, with minor differences due to technical limitations and to optimize performance. We are very happy with the results.
Development of Web based prototype in Bezi
Set up functionality with states
developed playthrough
System analysis and dynamics
Initial Causal Loop Diagram
Flow charts
Assets
3D modelling
Robots
player platform
desk
chair
Textures and materials
Design
Base gameloop
artstyle
Development of standalone prototype in Unity
Programming
Optimization
Scene setup, lighting
developed playthrough
Development of Web based prototype in Bezi
scene setup
System analysis and dynamics
Initial and final Causal Loop Diagram
Item tables
Flow charts
Design
Base gameloop
Gameplay mechanics
Research
growth requirements and cycles for each crop
martian soil chemical compound and how to fertilize it
chemical compound of human waste
water reclamation, mining and melting
average oxygen production and consumption from crops
average daily requirements and "biproducts" of the average human