World Origin Rebasing (multiplayer)

Hi, im wondering if anyone here has got the “enable multiplayer world origin rebasing” option working?

I have tried to enable it for my project (16 2k tiles landscape) but its not working, i don’t think. My animations are still jittery when far away from the origin.

My questions, do i need to also enable the option in the world settings (i’ve tried both off and on here)
Is there something i have to do on the client?

Any help appreciated as i really cannot find any useful information about this…

Thanks :slight_smile:

I have kind of figured it out.
kinda of! hah.

I have;
“Enable Multiplayer world origin rebasing” turned on in project settings.
“Enable world origin rebasing” in the world settings in the level turned OFF

I have written a function that runs and checks the distance from origin, and does
UGameplayStatics::SetWorldOriginLocation(this, CurrentLocation);
When you are a certain distance away from the origin.

Dedicated server.
This, seems to work okay. Fixes the animation jittering.
Yet to test what it does with other clients connected.
I have a feeling there is more that needs to be done.

But yer, no docos :smiley: :slight_smile:

1 Like

Yep, that is pretty much all i have been able to find out so far.
i have read those and seen the PR threads thanks!

Im aware that PUBG, Ark, Squad, Island of Nyne, all have done something. And i’m sure Fortnight must have too (im guessing, hence the new option)

With my current setup i have the entire level loaded on the server (this is fine for the time being), and the clients are shifting the origin using the function i mentioned. (Checks distance from Origin, and rebases if above a certain size)

I think, in theory that’s all that needs to be done with the new option enabled.

I was hoping someone had some more info to share.

If no one does, and i figure it out, ill write a wiki article with everything needed to be done :sunglasses:

new note: Seems to be working so far (tested 2 clients, 1 server)
We will see i guess!

Thanks for your input.

I look forward to reading your Wiki article. Could you update here when it’s done?

I second that!

Sorry guys, have been flat out with other things.
Okay, well, 4.19 has just come out today, i don’t think anything in relation to this has changed, but im yet to look.
I’ll take a look at 4.19 soon.
If you want quick help feel free to PM me :slight_smile:

I would definitely be interested in this. I would love to be able to handle larger multiplayer maps in my project.

I don’t understand why you people act like it doesn’t work in game. It does work, you just need to handle network replication with more care and account for the different origins on each client.

True, a lot of my issues at first where needing the correct settings on the level (for dedicated, “client side level streaming” checked, “enable world origin rebasing” not checked),
Then like you say dealing with the client giving a zero based location for something, to the server, then back, then rebase that onto the client. And also dealing with that from a listen server, because chances are you will one day test like that and get confused :slight_smile:

I don’t think anyone is acting like it doesn’t work. Its just those options, and understanding the logic of what you are actually doing. :slight_smile:

If implemented correctly, just what will multiplayer origin rebasing accomplish?

I just got an answer in another thread that origin rebasing is only for single player. Or at least that it can only be used to make a larger “map size” in single player.

Is the application for multiplayer origin rebasing to enable larger, seamless multiplayer game areas? If not then what?

Floats have a limited amount of digits. Increasing the map size, will decrease the precision as the comma shifts to the right to accomplish greater numbers. Rebasing will help you to keep those floats small and precise enough. It can be used in multiplayer, just like jonimake posted above, you have to take care of the relative coordinates.

Okay, so I can indeed use it to make bigger gameplay areas in multiplayer without suffering precision issues, as long as I handle the rebased/relative coordinates properly?

I am interested, because I have gameplay at around WW2 fighter speeds, so about 100-200m/s (360-720km/h). While that is okay inside a cube of 4km, it would be really nice to be able to use a bigger cube of 10-20km or above. My maps will all be mostly empty space (they can easily be just a pretty skymap with no terrain) but it would open up gameplay a lot if I were able to have more tactically significant travel times (while retaining high speeds). Adding a minute or more would make a world of difference. I am not using physics and, not even much animation, it’s just positions and rotations.

Can multiplayer rebasing take maps beyond the 20km limit?

The worst case without rebasing would be a map, so big, that there are nore more digits available after the comma. That would be like replicating an integer for the position. You couldn’t move between two integers, very rough movement. So yes, rebasing allows you create bigger areas, because you snapping the origin to another grid cell after X units.

I’m not sure, but theoretically, nothing limits the mapsize, if you rebase in combination with level streaming properly. I don’t know how well the normal character component replication would handle such speeds, but if you plan to make a custom actor for the fighter, at this high speeds, you need proper extrapolation if you want responsive controls.

If I understand the issue correctly then running out of decimals is precisely what sets the 20km or (+/- 10km from origin) limit. With 32bits, you’re limited to 7 digits and the standard unit is 1cm, which gets you to 1,000,000cm or 10km if you are allowed 7 digits (is it actually 999,999.9cm, because you have to have one decimal?).

The game is already working pretty well (from a very rudimentary point of view) with the higher than normal speeds. Granted we have yet to make a dedicated server build and deploy it on a proper server with a fiber connection, so we are hoping that some of the “less than good” stuff we’re experiencing is due to running on listen server desktops with normal home connections. :stuck_out_tongue:

Yea, I wasn’t sure about the max size, so I explained it more in general terms. I also heard 20k should be fine. That space prototype sounds interesting. I think, the faster a ship is moving, the less a low presicion would be reckonizable. Don’t know what happens, if you to move a tiny bit at the edge of a 2000km map :stuck_out_tongue: But yea, it’s all about trying it out. You never know until you tried.

Hey mate, can you share the wiki link? that would be quite useful! I’m creating this game Redirecting... and I got this issue, I didn’t get how I should replicate the origin rebasing properly

The error is a scalar quantity. At short distances outside the Max map size (represented as a yellow box in World Comp.) the error values will be small.

As this distance increases, so does the error.
For example, at 40074.28 Km (real earth size) this error is about 2Km. Any coordinate value calculated at this distance can be 2Km off in your absolute world position.
Things like teleportation and ai can often resolve to the wrong location. The magnitude of this depends on the specific calculations involved.

To my knowledge, the “Z” parameter is not controllable.
(at least not without a lot of handling code)
However the engine is equipped to handle the x,y situation in several ways.

The method in the original post is designed to be used with a single master server.
The option in the world settings is primarily for use with single player games, or local multiplayer networks.

The “industry standard” approach uses neither, and instead implements independent servers for each landscape tile, and another dedicated server to handle the transition between servers. On the client side, world origin shifting is not used, instead this is handled by the level streaming properties, and location information is passed through the dedicated server (which translates which landscape-tile server the player is “in”) and assigned to the appropriate server on the list.
This generally requires several people with multiple skillsets and knowledge in the engine back-end as well as IT and networking technologies.
OR at least one legacy programmers (from back when all these microtasks used to be one job).

The decision of which of our 3 choices (or other choices depending on your requirements) is going to be based on the number of intended players, the size of your map, and the capacity of your dedicated server network.

In any case, there is a basic understanding that must be gained in terms of how each solution is to be implemented, based on your particular set-up.

When writing your code to handle coordinate translations, you often need to scale this to the actual size of your landscape tiles (total distance +/- X and Y) not to the limiting distance of the engine. The exception being a tiled landscape set to the actual limiting value, in which case the numbers are the same.