Implementing a client-centric world offset for movement - how?
by Adam Beer · in Torque 3D Professional · 11/26/2014 (11:23 am) · 2 replies
I am looking at creating a project that requires hundreds of square kilometers spread out between multiple servers. Im looking into making each server 'region' be 50,000 units in each X and Y direction so a 100km x 100km zone. Id like to try and create a client-centric offset on all the world objects once each frame is rendered.
So basically each time the frame is rendered based on where the control object is in the game world, stick them at 0 0 0 and adjust the offsets of the terrain, shapes and everything else. Im guessing this would have to be done at the sceneobject level? What kind of performance hit would be taken with re-positioning everything every frame based on player position? I can see forest items being a challenge as well.
Ideally Id like to create a sceneobject method that gets called once each frame wants to render and performs the adjustments but it's probably not that simple?
So basically each time the frame is rendered based on where the control object is in the game world, stick them at 0 0 0 and adjust the offsets of the terrain, shapes and everything else. Im guessing this would have to be done at the sceneobject level? What kind of performance hit would be taken with re-positioning everything every frame based on player position? I can see forest items being a challenge as well.
Ideally Id like to create a sceneobject method that gets called once each frame wants to render and performs the adjustments but it's probably not that simple?
About the author
Adam is the owner of Ignition Games, an indie game and software development company.
#2
As this is multiplayer, the server objects have to use their absolute, non-client centric coords, so adjusting on the client may help with rendering artifacts, but won't help with physics/position/velocity errors due to decreased floating point precision, and these errors are likely to be more important.
If you are serious about needing such a large playing area, then you will probably need to implement a different coordinate system, maybe using fixed point / integer or possibly doubles. This would however require big code changes to large swathes of the engine.
11/27/2014 (9:16 am)
Be aware that the physics simulation will begin to misbehave when objects are far (> ~10km) from the origin, and will get worse from there onwards. As this is multiplayer, the server objects have to use their absolute, non-client centric coords, so adjusting on the client may help with rendering artifacts, but won't help with physics/position/velocity errors due to decreased floating point precision, and these errors are likely to be more important.
If you are serious about needing such a large playing area, then you will probably need to implement a different coordinate system, maybe using fixed point / integer or possibly doubles. This would however require big code changes to large swathes of the engine.
Andrew Mac
github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/En...
Which goes through every object in the scene, per-frame, to determine which objects are visible and which ones aren't. Then I'd subtract the world position of the control object (player, etc) from every object, including the player itself. So, now your player is at 0,0,0 and every surrounding object is offset by the same amount. If your player doesn't move and stays at 0,0,0 no adjustments would be done to the objects.
I haven't spend any time thinking about this or trying it, so it may not work out very well, but that's where I'd start.