Custom World Coordinate system? Changing Space.World?

Hi, Im making an mmo and would like the server to allow a very vast world while the clients will still use the single precision float.

Is it possible to create your own custom world cordinates? and if so how do you change from what I assume is Space.World. How do you change it into your own custom system, maybe using Decimal or a double?

Thanks.

 

Well the client would only see sections of the world at a time...

those sections would have a local origin (0,0,0), and all objects would be put in that locality

the 'vast' world map would only exist in data, not as an actual fully rendered world. There it would be stored in the 'world' coordinate.

Conversion from local to world would just require knowing the location of the local origin in the world space. And all internal points world location is just that + it's local position.

 

Well, This is for an MMO world to create a big seamless world. So I will need to change the precision of the world coordinates. I dont see why I cant create my own system for world coordinates and have everything relate to that instead..

I understand the trick to make it so its 0,0,0 every now and then but its impossible on an MMO when there is no main character, You need the world to be accurate all the time. We cant change these base enumerations inside of unityengine.dll?

 

yes it is possible

when you do the over world calculations you translate the local coords to the global coords. And the translation is just the local coord + the position of that local region in the global space.

It's going to require a full layered interpretation of your world. Where your system deals with it on two levels... locally for client side physics and scripting and the sort... and globally for the general interaction of the game rules and global logic.

 

I created a map gameObject and this "generates" a Terrain[,,] (my world is land based of course).

My problem is I want to be able to say something like ...
map.Add(terrain, [1,0,1])

doing that places the second patch (assuming this is the second patch im adding and the first is at [0,0,0]) basically right on top of the first terrain patch.

Unless ....
In "map coords" (e.g. coords within my map gameObject) I assume something like "a terrain patch is 512 x 512" (because all my patches are the same size) so when placing terrains the actual position is ... [x * 512,y * 512,z * 512].

However ... X patches later the numbers could get insane, you're ok for say the first 20 or 30 patches in a particular direction but by the time you get to the starting position of patch 50 you're at 512 * 50 = 25600 ... oh that's not so bad, i guess I could live with that until i start tiling maps .... if my world was "seamless" like my space fairing friend here and i now want to append 50 maps together and "dynamically load them as they come in to view" (as is the normal tactic) ... 50 of those later and map 51 starts at ... 1,280,000

Ok not too bad ...
Now lets look at planets in a typical system, in order to make them look big our friend here is probably scaling a very small sphere up by about 1,000

Taking my approach from above all those numbers get 1,000 times bigger so patch 2 of the galaxy that lives at map[1,0,1] lives at [1000,0,1000] in "world space" then we go 50 light years out to 50,000 then stick another map or 50 on to 50,000,000

In computer terms these numbers aren't crazy insane but "50 sectors" or "maps" in a galaxy sized game is ridiculously small with most games going in to the thousands for this type of thing, and before long with maps that size you run out of bits to put in numbers.

I was toying with some sort of "octree based translation system", the idea being that the data the octree could contain would be very small compared to the actual world and you can use a basic coordinate system to depict nodes to load.

for example:

If i was on a map at [1000,0,1000] i would load in that map and the surrounding maps in to octree nodes, when I move to map [1000,0,1001] i can unload the nodes way behind behind me and pull in some fresh ones in the direction i'm heading. (you can set buffer zone to avoid constant swapping).

since a map can also be quite big you can "sub tree the map" I already use terrain chunking so I kind of have a solution built in.
The idea being that instead of loading an entire map because they are sooooo big you just load the "chunks" in to local area.

You coordinate system then becomes something like ...
Galaxy[1,2,3], Sector[4,5,6], System[7,8,9]

With each [1,2,3] coord being an octree ...
Galaxy node
Sector node
System node

galaxy nodes should in theory be very rarely swapped out, and when they are all they do is pull up a base set of Sector nodes, each of those using it's local coord system will only render nodes within your local area of space meaning they rarely (but not as rarely as galaxy nodes) have to be updated / load new data.

Each Sector node (of which your player would be in 1) would render a system node that in turn only renders data for what's in view.

This approach could in theory scale as much as you wanted, you nest trees of data as deeply as you need to in order to define your coordinate system in as much depth as required.

All the play would see in this scenario is something like ...
Milky Way > Outer Rim > Sol > Earth [4,4]

... aka "local coordinates" but each node in the breadcrumb could also present its coordinates for example should the user open the system map you can show the parent tree coordinate.
Should they want a view of the galaxy they open up the galaxy map and you render a bunch sectors as coordinates / names.

This "tricks" the system in to using sets of smaller numbers in place of bigger ones.
Map builders have done this for years ... a local ordinance survey map coord is not just a huge number [123456,123456] its based on parent child relationships
1 largest area sector (country wide map)
2 smaller (regional map)
3 smaller (county wide map)
4 smaller (locality / area wide map - at this point you're talking page based coordinates)
5 smaller (cell reference on the page)
6 smaller (part of cell to reference)

repeat in other direction for actual point.
Or in 3D for your spacey coords.