[Project] Orbital Dogfight

edited in Projects
Thank you for checking out this Orbital Dogfight project. I'll be posting content randomly for those who want to follow along.

From some first attempts at planet making to the latest progress...

This first pic is just a conceptual drawing for unwrapping a quad sphere to its cube map format. As I understood it this method was the best for mapping out planets. But, instead of doing this procedurally I would manually build the planet using Rhino 5 and Grasshopper. This would allow me to customize its surface and generate LODs (level of detail) at any level of detail . Instead of using noise at various scales I used World Machine combined with Wilbur to generate the height maps that would be used as tiles in the scheme below.


Of course this method required that the seams in the tiles be addressed. I did this in Photoshop by transforming the position and rotation of the tiles so that each outside seam became an inside seam. This allowed me to blend the heights maps across seams, effectively eliminating them. Here is a visual of the transformation space for the cube map... basically makes it inside out.


The images are color coded for reference to see where the UVs are going.


By this time the height maps have been processed through Wilbur and World Machine. The process goes:  Wilbur is used first. I import a rough gray scale image as a primer into Wilbur and run erosion cycles on it till I am happy. The exported image is then fed into World Machine and setup for tiled output. World Machine adds the final landscape touches like coastal erosion and also generates textures for the associated height map output. These can be splat maps.

Here is the planet height map undergoing the transformation below it. It is returning to the standard cube map format after being made seamless.


Here is the Grasshopper script and an iteration of the planet it generates. By the time it was working properly I had also written a custom Rhino script to map UVs onto the generated meshes.


Here is the same planet rendered with no textures except a transparent blue on a separate mesh sphere representing the ocean. I thought " hey I'm getting close."


What I did not account for was the huge memory space these tiles and their associate textures would take up. There was some foreshadowing though. Let me pose a problem to you.

I have a planet with 24 tiles and 24 textures, how long does it take to apply 24 textures to 24 materials to 24 meshes? If you are fast about 30 seconds per...ahh only 12 minutes.. not bad.. but not for a sustained pace. Now lets take a Planet with 5 LODs. On the highest level LOD we would need to set 6x4x4x4x4x4 tiles.... 6,144 TILES! umm hmm math ahh 51.2 hours!!!!.... sheeit!! Game ender?

No. So I bit the bullet and starting learning things I did not know and eventually wrote some code. At the time I thought this was some hot stuff if you know what I mean.

using UnityEngine;

public class enMassTexturing : MonoBehaviour {
	public string m_filePath;
	private MeshRenderer[] m_gameObjects;
	private Object[] m_files;
	void Start(){
		m_files = Resources.LoadAll(m_filePath);
		m_gameObjects = GetComponentsInChildren<MeshRenderer>();
		Debug.Log("found: " + m_gameObjects.Length + "children MeshRenderes");
		Debug.Log("found: " + m_files.Length + "texture in folder");
		for(int i = 0; i < m_gameObjects.Length; i++)
			Texture m_texture = (Texture)m_files[i];
			m_gameObjects[i].sharedMaterial.mainTexture = m_texture;

The script worked and processed all 6,144 tiles in under 30 minutes. It saved me from what was an ambition ending wall of time and I finally got the planet into Unity. This meant the dev cycle was possible in some way and could commence. This was great!


Jumping that little hurdle gave me more confidence to move forward but the file size limitation still loomed large and I wasn't anywhere near the level of detail desired (true planet like earth needs about 10-15 LODs). I knew these were game critical elements but without immediate answers the only option was to go forward. I decided this was okay and begin the next phase...flight. A few take away(s) first.

It is possible to create your own custom planet not using procedural code. The major drawbacks are file size and organization. I would not recommend this route unless your planets will be smaller or less realistic. However the major benefit to this method is customizability. By incorporating Wilbur and World Machine more realistic erosion patterns resulted compared to the procedural equivalent with tuned noise. Writing my own planetary shader is probably the next step..


So at first it was easy. Unity 5 came with an Aeroplane prefab you could drop in your scene and fly with a keyboard. Total crap by any flight sim standards but it worked to get me started. The first issue one encounters in altering the code for planetary flight is that the Unity's gravity system considers UP to be the Y axis and this does not work for planetary flight. This may seem obvious but now UP needs to be the opposition direction of gravity's force, which is in a direct line from your mass center to the planet's center. So solving that... then... it starts to get harder. The methods in the flight controller rely on calculating the angle of pitch and so forth from a flat world (go flat earth idiots) but as we rotate around the planet pitch angle will depend on how we are oriented to the planet. So this must be accounted for. I would go into more detail now but I'll save it for the orbital elements section.

That's the post for now. The game is further along so this blog should be updated soon as I capture some more recent content. Thanks for reading. 


1853 x 922 - 688K
Sign In or Register to comment.