Load-level in Space

Questions & Answers
1

OK, I’m near insanity here, I’ll try to explain my FPS space-game problems.

I’m trying to create a virtually infinite space environment (limited only by how many scenes I create). I am of course, encountering floating-point inaccuracies. This is what I’ve come to realize:

  • Floating-point inaccuracy cannot be resolved by ‘moving the universe, not the player’ - this does not work in multiplayer contexts
  • Floating-point inaccuracy cannot be resolved by using the FloatingOrigin script found on UnifyCommunity wiki - 2D movement is fine, but once you throw vertical movement into the mix, floating-point numbers become inaccurate
  • Floating-point inaccuracy cannot be resolved by scaling objects up or down; I know this has worked for some people, but not for me

So I came to the conclusion that, perhaps, I need to just make smaller scenes and somehow link them together in a 3-dimensional grid of scenes (think rubix cube, just in virtually infinite size). This is fine, but I am totally lost as to how to implement this.

  • SetNeighbors would be nice, but I believe it only works with actual terrain - empty ‘space’ I dont believe will work
  • SetNeighbors also only works with 2 dimensional planes (e.g: left/right/forward/back, not including up/down)
  • Application.LoadLevel would theoretically work, but I do not understand how to keep the player facing the proper direction (orientation-wise) based on which direction from which they’re entering a given scene. Also, keeping the skybox (same one used throughout all scenes)

I’ve gone over every thread I could find, I honestly have tried many solutions - I’m looking for something to save me from this seemingly impossible scenario.

Thanks

2

No matter what you do, you only get 6 or 7 digits of precision, regardless of scale. This is simply not sufficient to model space as a continuous area.

Yes, you will have to make smaller scenes. You can load them using LoadLevelAdditive and translate them to give an impression of continuity, but you will also need to translate everything to keep it near the floating point origin, and you will need to discard scene content that is too far away.

You may also need a second camera to draw more distant objects, since you probably can’t have planets and people in the same floating point range.

3

I dont see how the multiplayer thing can be an issue. If you build your view as a viewport. Then you just have to use an offset value?

Your idea with the cubes (rubix) is great for this approach too. In 2D tilemapbased games to keep this simple, I usually make a buffer around the viewport. Same would apply for your idea I think. Or so I would do at least.

Once you get near a new zone, you have to start loading/spawning the next in that direction so you have enough.

When you cross a boundary, I think you can “easily” translate the whole “cube” in the oppersite direction.

For the rubix example:

Lets say you call center for (0,0,0). Around you, you have 26 other cubes. If you go right (1,0,0) you should now place this as your new center of your local viewport. Any player inside the other 26 cubes should be taken care of (shown).

Your universal position depends on where you place your universal 0,0,0 - but your own position is a local 0,0,0 with a cube-offset value to the real universe.

Now when you move to the right and the new offset is 1,0,0 then you can destroy/put away those in -1,y,z and add those in +2,y,z

Ofcause you can expand this cube system for a rubix of 5x5x5 or whatever matrix is best for your engine/idea. But I feel rather certain that this would do the trick and enable you to center your game around the precise 0,0,0 coords.

For every player you just need to know two coords: local (within a cube) and offset (which cube).

Does this make any sense?