A realistic, huge and open space environment?

Hi, I've been thinking about how to create a realistic space sim in Unity. What does it need and what Unity can do to make it as realistic as possible.

First of all I'll list what I would want to see in it:

• 1. Open environment - Space is vast and empty, and you can travel seamlessly to another solar system.
  
  2. Huge stellar objects - Planets are big, I'd hope to go for 1:1000 scale from real size of Earth when compared to player character size. Orbiting satellites (moons, etc.) included of course.
  
  3. Atmospheric Entrance and Planetary Surfaces - This is not a biggie, but would be cool to be able to land on a planet, in to a forest or a city perhaps.
  
  4. Spaceship Interiors - Not necessarily needed as seamless entrance from space to a ship, would be difficult with the already huge scale of outside space I think.

I already have created a rather realistic Newtonian space simulator for flying inside planetary gravitational fields. That's working nicely but due to the floating point imprecision the physics go wonky after going straight for a while.

I want to start a discussion on how people would go about creating these things, if possible. Crude hacks and ingenious solutions are all welcome. I'm more interested in the possibility than actually getting it all to work as a good game (though that would be awesome).

Now, on to what I've thought about this:

• * * *

1. Open environment

Seamless space can be done through not moving player, but everything else around the player. Haven't properly tested this, but in theory I think it could work. Floating point imprecision can be avoided far away from player by making sure that the player can't really see outside a usable range.

2. Huge stellar objects

I've tested 1:1000 Earth and Moon, and gravitational fields have been very successful. I also tested atmospheric drag that increases as the player approaches surface from the edge of atmosphere. This worked ok.

Feeling of huge stellar objects were all successful with 1:1000 scale when compared to real world and the player's size in Unity.

3. Atmospheric Entrance and Planetary Surfaces

I haven't tested these, but the physics simulation of atmospheric entrance can be done quite easily I think.
In my opinion the necessary points are gravity pull, atmospheric drag and heat generated by cutting through the atmosphere. The last part can be purely graphical or it can also have a meaningful effect, as in heat damage to ship.

4. Spaceship Interiors

I'm thinking this needs to be done as a separate level. If the space environment is huge, it will need a miniature scale for ships and huge scale for planets to get a proper comparison and a usable range in floating point imprecision.

Creating an interior in a miniature scale could easily break physics when I think about it, and it really isn't that necessary to create a seamless airlock system.

• * * *

Now, what thought do these points bring out in your minds? Tell me what you think of my points and what comes to your mind when you think of how you would solve these issues.

 

i'm making something similar...

i make the ship so little, and the planets huge, same as stars (these are maded with light and particles only).

To complete the magic-trick, the camera near-plane is at 0.003 and the far-plane is at 1000.

My actual problem are the asteroids and the comets... (don't forget that my universe have 13 galaxies)

 

About 1. Open environment

Yesterday, I tested moving the universe instead of player. I did it simply by moving universe opposite to player movement each update, and moving player back to origo.

Crude hack, but even the collisions and bouncing off 'stationary' space objects seem to work fine. So far I'm happy with this. Next I will try creating a star or a planet so far away that it will suffer from floating point imprecision, and move towards it, checking how this system responds to it.

EDIT: More tests on this subject

I first tested by simply placing a ball at 1.5e+07 in z-coordinate and by accelerating towards it, the game screen looked like a ship was approaching a planet at insane velocity

Next I tried using a decimal-vector class I made to represent huge distances. Mind you, decimal values can hold 28 digits, so a 7 digit number is nothing to it. I made a script which moves the player's coordinate in decimal vector, and placed the balls on scene with decimal coordinates of their own to represent their relative position to universe origo (not to be confused with scene transform coordinate origo).

The scripts moved the balls by mostly casting a decimal into a float vector (transform.position), and whenever the ship got anywhere near to practical range of these balls, they all moved smoothly on screen, and collisions with objects and ship looked ok too.

So, this is an ok solution to floating point imprecision, and lifts off a lot of limitations in creating vast space scenes. I don't think this is the best solution, but usable so far.

 

"I understand how the engines work now. It came to me in a dream. The engines don't move the ship at all. The ship stays where it is and the engines move the universe around it."
--Cubert Farnsworth

 

That's pretty cool!

 

Glad you like it, and yes the Futurama reference has come up to my mind more than once while thinking about this

I'm thinking the main problem for a game to work with this is that collider-based functions far away from origo would still suffer from floating point imprecision if AI needs to do it.

The only really working way could be to have a client-based hit detection from each peer, and to handle all AI ships as clients too, each having their own client process, which would shoot up the requirements a lot - not fun.

I can see that using different type of AI for those entities inside a player's active area and for those outside them. Maybe it would have to ignore any collision checking outside...

 

Hi Labis, hi all,


I'm on a similar path as you. My project is an Elite-like and RTS based sim with realistic stellar systems.

Your idea of moving the universe instead of the camera is what I've already used on VB6 some years ago in a steallar systems editor. It works nicely and I don't see why it shouldn't in Unity.

Anyway, as I'm new to Unity (just downloaded it, didn't even test), just a hint : does it manage double numbers ?

I've launched a discussion on my project here :
http://forum.unity3d.com//viewtopic.php?t=41259

Perhaps our projects could progress hand in hand, and we could check if there are other similar projects out there so we could join our forces ?

 

Unity can use double precision, but most API calls use single precision floats for speed.

 

Well, good luck and keep an eye out for playability.

The thing with realistic space-sims is that real space is boring as hell. It's about 99.999% empty and the travel times are nothing I want to play in a game, even if you give me 0.5 c.

Also, there are some articles on Gamasutra regarding realistic space physics and motion that I heavily recommend reading. The summary is basically the same again - real space physics don't make good gameplay.

 

Spore did a really good job at scaling the universe when you zoom out, and completely abstract space travel. You might want to go to such an extreme for galactic travel, for example.

You could make your universe smaller (less empty space between planets and star systems) and give the illusion of increased speed (visual and sound effects) when moving further away from planets, then from solar systems, and give the illusion of slowing down when getting closer to them.

By fracturing your galaxy into many sectors and using a galactic map to travel between them you would:
1- Solve the 3d space coordinate issues
2- Make travel between points of interest (astral bodies) more interesting
3- Help your players not feel completely lost in a huge galaxy.

 

I think for space travel and alike, EVE is one of the best examples of how it should be done. Alternatively X3 is a good example too.

But those two aside of Privateer are the only games I know that don't use "port around" for traving in the infinity

 

Eve does in fact use the 'port around' approach. Each solar system running on a separate machine or cluster of machines, separated by stargates. Within each solar system, they appear to use some scale tricks to make it seem huge.

Interestingly, they also use a dynamic 'grid' system for interest management, with the size of the visibility grid adjustable on the fly. This is abused at times, using leapfrogging tricks to extend the grid hundreds of thousands of kilometers. (So you can see the enemy fleet movements that would otherwise be hidden.)

My take on it, is that moving the entire universe is not the most efficient manner of eliminating the floating point imprecision problem. What happens when you move into an asteroid field for example?

Imo, it would be easier to just add an artificial fourth value into the mix. In a space sim, you have relatively tight collections of objects that are separated by vast distances.

So instead of moving every object in the universe each frame, you do it once when the w coordinate changes. eg: Flying from one solar system to another or even to another planet.

Therefore, as long as the scale of your w-space is such that at it's edges you don't encounter all your objects and camera having turrets syndrome due to floating point imprecision, you're golden. You can at that point do what any good game programmer does, simply fake flying into empty space. Hell, empty inter-stellar space could simply be a w-space = 0 for that matter making empty space real.

 

I accomplished the scale whilst being able to walk around inside our ship by having two cameras. The ship stuff was on one layer, the planets/stars/etc moved on another. Both cameras had the same mouse controls but separate controls for moving (WSAD on the ship, unless you interfaced with the helm, in which case you'd start flying the ship).

The "space" camera could only see stars, planets, etc...and had a skybox of a starfield. The "ship" one could only see the ship, and had no skybox but it's depth was above the space camera. The space one moved very slowly so the scale seemed very big. Then I overlayed the ship onto space and boom...you could walk on the ship and fly the ship in space with both scales intact. The best part of this is that since both the ship and space are in the same scene together and using different scales, both can be at 0,0,0, and the ship will never move from that position (although it will appear as if it is) meaning physics on the ship are fine due to almost no floating point inaccuracy.

 

I was worried about this same thing myself. I think most of these issues can be fixed by placing small numerous objects into containers and not moving the individual objects with the universe mover script.

The processor should be able to handle calculating all children much easier than applying the move script on all of them one by one.

This is also what I thought of, dissecting the space into a grid. I haven't got around to really implementing my thoughts much as of yet, but will at some point.

Basically this kind of system should rely heavily on instantiated prefabs, but it also should save plenty of data inside scripts for those prefabs to be synced as the game goes on.

Also, when it comes to EVE, it's a bit different in the way that there's nothing smaller than the smallest ship, and no insides. Correct me if I'm wrong though.

 

This is exactly what i have been looking for. I've posted this questio in my thread here: http://forum.unity3d.com/viewtopic.php?t=56285
but have been unable to find out just how to make this work. Any advice is appreciated.

 

So how did you manage to overcome the rotation of the universe around the ship i have tried rotating objects around others and i got poor results once the object it was rotating around was no longer at the direct centre of what i was rotating

 

This is where i'm currently at my self. I can move the world around the player but rotations get messed up if i have the world do the rotating. I think we need to have rotation set to our local player and movement set to world. But then i don't know how to translate the local player rotations to the world Z movement so that the world moves in the direction the player is facing.

 

I was prototyping an "Elite" type game a few years ago, and hit the same problem of inaccuracies with floating point numbers.

I ended up making distances between planets/moons 10% of real values, to fit the solar system in.

I also made everything relative with hierarchy. Your position is relative to the closest big feature.
So if you were orbiting say Earth, it was (0,0,0), and if you moved closer to the Moon, it became (0,0,0).

Turned out to have some other management benefits, like if a spaceship was orbiting Mars, if you couldnt see Mars, was no point trying to render any of its Children.

Was pretty hacky implementation, and I wasn't even moving planets in their Orbit. I just did a circle to indicate their path (distance from Parent).


Elite series was awesome, and I still don't think anything comes close, but Spore was getting there.
EVE online uses a local space instance system, you couldn't point yourself at a planet miles away and ever expect to get there.

 

callahan.44 how were able to tell the world to change it's 0,0,0 location, and does the player exist in the world its self. I made a solution to make the world move around the player while the player stays fixed at 0,0,0. But this means the player is separate from the world and everything in it. Which makes shooting kind of hard, because you are only facing 1 direction and your projectiles are going in the way that you are facing. So i'm just stuck.

Player
|
|___Camera
|
|___Ship Mesh


World
|
|__Everything that makes up your universe

 

This wasn't in Unity, but the same principles apply.

Parent player to the Earth, and as it moves within Moon area, unparent from Earth, and parent to the Moon.
If there was a Spacestation orbiting around the Moon, you would then parent the player to that, etc.

There is a little bit of positional maths, but no change in rotation of the player.

If you had a multiplayer game, I'm not sure the whole moving the solar system around the player would be optional.

 

@ForceX, I've been thinking on this, since I am now experiencing the same mesh jittering your were. How are you approaching it currently? My thought is to create an empty game object called space. Put everything that isn't attached to the ship in it. Then, you can just move and rotate the space object. Objects in space update their positions relative to the space object's center. All you should have to do now is update the space object relative to the ship. Transform.InverseTransformDirection() and Transform.InverseTransformPoint, I think, will become our best friends in doing this.

@callahan44, you can do multiplayer using this system. It is just a little more relativistic math, but it is not too difficult.

 

I have a working model I'll PM it to you so you can check it out and give me your thoughts.

 

These articles may be of interest

http://answers.unity3d.com/questions/137097/scale-objects-based-on-distance.html

http://wiki.unity3d.com/index.php?title=Floating_Origin

http://www.gamasutra.com/view/feature/2984/a_realtime_procedural_universe_.php

 

The issue I see with moving the universe and not the player is the performance overhead for re-calculating static physics. I'm fairly sure PhysX uses some kind of octree or other spatial partitioning system to speed up static collision checks (I mean, it has to use some kind of pre-calculated broad phase search system), if you move a static collider all that will need to be re-caculated. You won't see any hit from a handful of objects but with a few hundred planets, space stations and a handful of asteroid fields and I reckon you'll end up below 10fps in no time.

The links Beugnen pointed to look good though.

I'd also not want to try and implement multiplayer ridigbody interactions with a floating origin system, just thinking about it hurts.

 

If anyone is interested I have been trying to get Homeworld Modders involved with transfering Homeworld to Unity so that all ships can be used. All of the ship models are already complete. They are textured and ready to go. All that needs done to convert them into Unity add scripts to them based upon their interactions within Homeworld so the same style of game play can be achieved in Unity but where scenes or maps can be linked together to form a persistent Universe.

If interested check out the Homeworld Complex website where all of the modding tools are there along with all of the scripts that determine how ships fire, are built, attack and how resources are collected, ect.

Like I said all that needs done is too take the models and scripts from Homeworld and incorporate them into a Unity.

 

I made a game like this. Here are some of the problems I encountered:

1. Objects were too far away. When you have such an open, massive world, it is nearly impossible to find other objects near the size of your ship. They appear as specks on the screen. Solution: I made a script that would draw arrows above these objects (or pointing to the objects if they are off-screen). It worked fantastically, and is now available on the Asset Store: http://u3d.as/content/gdcore/radar-arrows

2. Physics were resource-intensive. Trying to simulate an entire solar system eats up your resources. I originally tried simulating an asteroid belt by giving rigidbodies a nudge and let a point-gravity script take over. Normally, you get get away with having a lot of rigidbodies because most of them sleep at any given time, but in this case, gravity wouldn't let any sleep. Not a good idea. Solution: Add pretend physics. I parented all the asteroids under a single belt object, and then rotated that each frame around the center planet. The same idea could be used for moons and other satellites.

3. Impossible to control. When objects are really far away, when you use a forward thrust, for a long while nothing on-screen really changes. It doesn't feel like you are going anywhere, so you keep holding down the thrust. Finally, you approach your destination, but then overshoot it travelling a 10,000 km/s. To make matters worse, we humans are used to having ground under our feet and this concept called "down." It is easy to get disoriented in null G, and I constantly found myself spinning out of control. Solution: To solve the problem of overshooting a target destination, I did two things: I made the amount of thrust decrease as speed increased, and I decreased the side-to-side velocity of the ship with the thrust (to keep it from drifting too far). To solve the problem of spinning out of control, I added a Stabilize button to my game. It decreases the ship's angular velocity. (Each frame it would multiply the angular velocity by 0.7).

4. Players can leave the universe. This was a serious problem I encountered with my game, especially when I tried having planets exert gravitational force on the player, which often threw the player to the edge of the universe like a comet when gets too close. The empty void doesn't make an engaging game. Solution: The first thing I tried was to make gravity work in reverse. Normally, gravity is stronger as you get closer. I made it stronger as you get further away. The idea was that the gravity would overpower the thrust and trap the player near the planet. The implementation was buggy and I eventually ditched the idea. Instead, I created a huge force-field around the entire system. Normally, this would make the game seem very closed, but I made it invisible from most of the system, but increased the opacity as you approach. When you reach it, it is practically solid. I made its collider a trigger that, when exited, would bounce the player's velocity back into the game.

 

I have not done this with unity but I have had problems like this with other engines.
And your solution to the never ending universe is viable for so long..

Because in a 3d space...
If you move to far on a floating point... the floating point at one point becomes..... unpredictable.
There a demo on the net somewhere with a spaceship moving a long a floating point as very fast speeds.
And it clearly shows the limits of 3d space. So, it becomes impossible to move forever in one direction without actually adjusting everything.

So, just keep a eye out for that.
If you math starts getting realy crazy then you prob need to reset everything to the original position and then account for some sort of offset in each direction of where it actually is x,y,z, so things like.. world pos.. are correct.. if your displaying it to the user.... even though the actually game engine as been reset they will never actually know.

 

First off I know this is basically a dead section in the forum. But anyone that has already posted, I am wondering if you ever fixed the float point problems? If you did what did you do to do this? Are they multiplayer compatible? Also a screen shot from my game because why not?

 

@Snownebula Very nice. Multiplayer? I see large numbers in meters. what kind of scale are you using?

 

Hi everyone,
Floating Origin http://wiki.unity3d.com/index.php?title=Floating_Origin
works quite good for me. i use big terrain for very fast ship.