Hello everyone, as this is my first post! A quick search didn’t reveal anything, so here it goes. Please tell me if this is already discussed elsewhere.
I’m making a realistic space simulator. This involves of course huge distances. I have all my planets set up as well as some moons, and a simple means of moving the camera around. Newton’s law makes them orbit as they should. The problem is, once I start to get far from the sun (0, 0, 0), movement gets stuttery, specially the camera. I’m talking ~8.16e+08 units from the centre or more.
It is as if objects, while moving, every few units got snapped to a nearby (rounded?) coordinate. It looks exactly the same as a bug the game Minecraft has whenever the player travels too far from the origin coordinate: http://www.youtube.com/watch?v=5bGm2-YpzXE It is specially noticeable in the first minute of that video. (For reference, this is how movement is supposed to be in Minecraft: http://www.youtube.com/watch?v=nSFeFdgZ9SE)
I guess the problem is I’m not supposed to use coordinates that huge. Is there a way or a setting to fix this easily? Or should I devise some method to keep position calculations within more manageable magnitudes? If you have any tips regarding that I would greatly appreciate it as well.
PS: I’m not sure about this, but I’d rather not scale the solar system down (that would reduce absolute distances of course) because later on there will be smaller objects, like artificial satellites and spacecraft. Or should I do just that?
The core to any phsycis engine is that the physics “world” is not a rendered world, but a world that contains all collidable object definitions. The further from world origin objects are, the more the imprecision of floats become between actual objects and physics based objects thus adjustments happen. Stitching together scenes so that they are fluid but have unique world origins is the trick to the solution.
Yeah, sure, just don’t forget about both performance and memory penalty.
Especially when you can easily avoid these kind of issues (I’m talking about distance from origin)
OK, I’ve made it so the universe moves around the player while the camera stays at 0,0,0 at all times. It now renders fine.
Does this mean physics happening far from the player will still behave weirdly? Or it just affects the rendering and not the actual simulation? I’m concerned about moons starting to crash into planets.
Asset streaming is just available on the Pro version. Is there a way to seamlessly “stitch” scenes together in Indie?
The larger a float, the less precise it is. This is mostly noticeable at really large distances but it always exists.
Making the transform a double doesn’t solve the issue, because OpenGL still accepts floats, so they have to be downsampled before rendering, eliminating the benefit from a visual perspective (less so with CPU based physics, though it’s still a much larger processing/memory footprint).
Nothing on a computer is infinite. You can’t go infinitely far, you can’t draw infinitely much, etc… You can get really big, but everything has a cap, and with floats it’s just a degradation towards the cap. Physics may or may not react weirdly, and it can be a good idea to use a second camera and render under a different scale (just look at the tiny size of skyboxes in Half-Life/TF2 maps).
Actually, I use a position vector consisting of doubles and my suns and planets all behave just fine. Those special vectors are only used when dealing with positions of sectors of space and movement of systems within a sector, because my sectors are 10,000,000 units across. It’s pretty simple to do. Get the delta movement of your ship, which is a Vector3 (I’m thinking your ship isn’t moving at speeds in excess of 1,000,000 units per frame), add that movement to your star system’s double vector position, convert the double vector position into Vector3 and set to your systems’ positions.
I’m assuming you are using rigidbodies and the physics engine for a reason, but I have found it is much easier to accomplish what I have (in terms of scale) just doing the simple math to calculate orbits and positions based on those orbits. And, you aren’t worrying about using physics when the player isn’t even in the system, right? Rendering and physics issues should only be a problem if your star systems are of huge scale, and then you can just use math when the bodies are so far away and switch over to physics when they are closer. But, seriously, orbital math/physics is relaticvely simple, so you might consider just abandoning reliance on the physics engine.
I’m not using rigidbodies nor the built-in physics engine. I just use Netwon’s universal law of gravitation and let it take care of the orbits using an initial speed along the x axis and pulling them towards the Sun along the z axis. I’ve tested those orbits at a speed of 1 earth year per second and they seem to be stable. I don’t know about far away planets like Pluto though. If the Vector3 I use for speed gets rounded there may be errors. To control ships’ acceleration and torque I just use vector math as well. Everything seems to run fine now.
Depends on your scale, then. If I remember, Pluto is something like 4 billion km from the sun, so, obviously, if you are using a 1:1 scale ( ), doubles would be necessary. You should be able to scale down the distances easily enough to use flaots, though. However, then you run into the issue of planets not being to scale in relation to distances.
For those sorts of distances, it’s far easier to fake it similar to games like Eve.
Use a Vector4 to track your object’s position. Use the 4th value as an index to which grid of space your ship is in and magically offset everything relevant to the origin when you approach/cross boundaries. That way, when he approaches Pluto or mars you’re working with more sensible distances and scales.
A really fast scout ship in eve might move at 11km/s, which would still take forever to reach pluto from the sun. Use a star wars like ‘hyperspace’ trick to switch between distant grids.
The size and shape of Eve’s grids are flexible, they can change on the fly. That though is just to accommodate multiple players when fighting, so two ships fighting close to a grid boundary don’t pop in and out of existence. He didn’t mention multiplayer so it becomes far simpler.
In terms of the local scale that Eve uses, each grid by default is a 250km sphere. You can probably make some assumption from that.
The thing to consider, is that a solar system is mostly empty space. What’s the point of simulating empty space? Just be a good gamedev and fake it.
Singleplayer indeed. Right now I’m using a scale of 1:1000. I had in mind using a jump device (mounted on the ship) that would catapult the player at tremendous speeds (previous optional calculation of a route for orbit insertion), live, really fast, though not instant-travel, for a dramatic effect. Bodies are smaller in relation to distances, but it still retains the huge-emptiness feeling. I really want that empty space to get lost in, if the player wants to.
Since the universe moves around the player and everything happens at 0,0,0, I think I will just drop Newton’s for planets and moons and use a Rotate around the orbit center, keeping bodies’ distances constant and preventing the orbits from distorting even when calculations far from the player get rough (I don’t need them to be real-world accurate anyway). I will still use Newton’s to calculate the player’s ship orbit.
I started this inspired by the Orbiter simulator, but as I add things I keep wanting to make it more a game and less a simulator. Despite this, I’d like to create that feeling that Orbiter achieves of being really small in the middle of nowhere. Most games kill that.
Can you elaborate on that please? It sounds interesting, but I don’t quite understand it. Is that method possible with continuous uninterrupted travel from one grid to the other? I thought in Eve the game just unloaded an area and loaded a new one when you jumped from one “room” to the other.
), doubles would be necessary. You should be able to scale down the distances easily enough to use flaots, though. However, then you run into the issue of planets not being to scale in relation to distances.