The GameWorld is much larger than the usable part of the BabylonJS world. In fact its as large as the creator of a railway needs it to be. For example the GameWorld could be several 100km(thats 100,000 units for the world as our units are meters in the world) wide on each side.
But the complete GameWorld cannot be loaded into the BabylonJS world at one time - there will be precision issues with physics after a few kilometers.
We need maximum precision where the game's current action is, meaning where the currently focused train is. This train is the one being driven(henceforth referred to as only the train). Also maximum precision is available near the BabylonJS origin. So the game's action has to be somehow kept near the BabylonJS origin.
To enable this we separate the GameWorld from the BabylonJS world. An object exists in the GameWorld which is what the author of a railway creates. But for rendering, we need to render the object in BabylonJS co-ordinates which can be different from the GameWorld co-ordinates of the object.
To make this separation possible and manageable we have the concept of a SimBox which is a cuboidal area within the GameWorld. It's axes is aligned with the GameWorld. This SimBox represents the region in the GameWorld where the train currently is. Since the train is moving, the SimBox moves too within the GameWorld. The size of the SimBox is fixed and doesn't change during the sim. All game action thats within the SimBox is rendered, all the rest of the GameWorld and action outside it is ignored. Also, the SimBox ensures that all the action within it is rendered near the BabylonJS origin for maximum precision.
Therefore we need to calculate co-ordinates for each object within the SimBox that we need to render. These co-ordinates need to be BabylonJS co-ordinates of course and as close to the BabylonJS origin as possible.
Lets call the GameWorld co-ordinates henceforth as GW co-ordinates for short
Let the Babylon co-ordinates be called as BJS co-ordinates.
The SimBox is placed in a fixed place in the BabylonJS world at BJS(0,0,0). Therefore the current action in the GameWorld(within the SimBox) will be always centered around the BabylonJS origin and thus have maximum possible precision.
The SimBox center matches with BJS(0,0,0). This center will be the center of the cuboid of the SimBox. In the GameWorld, the SimBox center can start and be anywhere based on the train's current position. Therefore the GW and BJS co-ordinates of the simbox need not match.
For example the train could be at GW(102, 0, 0), within a simbox thats of size (10,10,10).
Let the simbox be at GW(95,0, 0).
Since the simbox is always at BJS(0,0,0), in BJS co-ordinates it extends from (-5,-5,-5) to (5,5,5). Therefore the train is at BJS(2, 0, 0).
Thus if the SimBox is not at GW(0,0,0) then the train will be at different GW co-ordinates than its BJS co-ordinates.
For Version 0.1, the GameWorld and BabylonJS world will match. We will allow larger game worlds from 0.2 onwards.
The GameWorld is much larger than the usable part of the BabylonJS world. In fact its as large as the creator of a railway needs it to be. For example the GameWorld could be several 100km(thats 100,000 units for the world as our units are meters in the world) wide on each side.
But the complete GameWorld cannot be loaded into the BabylonJS world at one time - there will be precision issues with physics after a few kilometers.
We need maximum precision where the game's current action is, meaning where the currently focused train is. This train is the one being driven(henceforth referred to as only the train). Also maximum precision is available near the BabylonJS origin. So the game's action has to be somehow kept near the BabylonJS origin.
To enable this we separate the GameWorld from the BabylonJS world. An object exists in the GameWorld which is what the author of a railway creates. But for rendering, we need to render the object in BabylonJS co-ordinates which can be different from the GameWorld co-ordinates of the object.
To make this separation possible and manageable we have the concept of a SimBox which is a cuboidal area within the GameWorld. It's axes is aligned with the GameWorld. This SimBox represents the region in the GameWorld where the train currently is. Since the train is moving, the SimBox moves too within the GameWorld. The size of the SimBox is fixed and doesn't change during the sim. All game action thats within the SimBox is rendered, all the rest of the GameWorld and action outside it is ignored. Also, the SimBox ensures that all the action within it is rendered near the BabylonJS origin for maximum precision.
Therefore we need to calculate co-ordinates for each object within the SimBox that we need to render. These co-ordinates need to be BabylonJS co-ordinates of course and as close to the BabylonJS origin as possible.
Lets call the GameWorld co-ordinates henceforth as GW co-ordinates for short Let the Babylon co-ordinates be called as BJS co-ordinates.
The SimBox is placed in a fixed place in the BabylonJS world at BJS(0,0,0). Therefore the current action in the GameWorld(within the SimBox) will be always centered around the BabylonJS origin and thus have maximum possible precision.
The SimBox center matches with BJS(0,0,0). This center will be the center of the cuboid of the SimBox. In the GameWorld, the SimBox center can start and be anywhere based on the train's current position. Therefore the GW and BJS co-ordinates of the simbox need not match.
For example the train could be at GW(102, 0, 0), within a simbox thats of size (10,10,10). Let the simbox be at GW(95,0, 0). Since the simbox is always at BJS(0,0,0), in BJS co-ordinates it extends from (-5,-5,-5) to (5,5,5). Therefore the train is at BJS(2, 0, 0).
Thus if the SimBox is not at GW(0,0,0) then the train will be at different GW co-ordinates than its BJS co-ordinates.
For Version 0.1, the GameWorld and BabylonJS world will match. We will allow larger game worlds from 0.2 onwards.