If you have a really large/infinite world, and you want to split it up in fixed size zones, say each 1 km^2, how can you use make the physics work at the edges?
I don’t mean on the client, which loads all zones near the player, but rather on the server, where different zones might be in different servers.
Can this be achieved by some level of “overlap”, where servers tell their neighbors about what is happening at the edge of their zones?
I’m expecting that with a bit of overlap, collision should work fine, but full physics would probably be problematic, since even if a server knows the position, velocity, … of objects “over the edge”, when a collision happens between two objects on different sides of the edge, both are affected, and even if the physics simulation runs at the same time on both servers, the results will probably not be exactly the same.
Is there a way around it, or is it better to create my own simplified physics, built specifically to handle the edge cases (not something I would be looking forward to…).
Basically what you indicate is what I intended to implement as an example at some point, yeah. Some special collision handling and syncing between the spaces on the borders with doubled objects and then passing the objects from one to the other completely. That would be the “straight forward” way for position-absolute game world systems, you should keep it within a size of 50 square kilometers if you plan to use absolute coords all the way. With some adaptation you could even make it “endless” but that requires some intricate syncing and adaption between the visuals and physics.
This should scale relatively well and also work multithreaded out of the box with the current BulletAppState and Controls etc.
So if you think it’s feasible, then my hopes are high.
I was thinking more along the way of having every “zone” deduct it’s own “location” from all positions, before building the scene and physics, so it is centered around the origin, and add it again when passing positions to another zone. Then the other zone deduct it’s own location from the received positions. That should allow for infinite coordinates.
I’m going to try using Actors for the multi-threading, as it scales really well on the server side. When all exchange of data between threads is represented by (potentially unreliable) asynchronous messages, the client/server, and server/server, boundaries become invisible (except for higher latency).
@monster said:
So if you think it's feasible, then my hopes are high. :)
I was thinking more along the way of having every “zone” deduct it’s own “location” from all positions, before building the scene and physics, so it is centered around the origin, and add it again when passing positions to another zone. Then the other zone deduct it’s own location from the received positions. That should allow for infinite coordinates.
I’m going to try using Actors for the multi-threading, as it scales really well on the server side. When all exchange of data between threads is represented by (potentially unreliable) asynchronous messages, the client/server, and server/server, boundaries become invisible (except for higher latency).
Yeah that should work but at some point you’ll inevitably come to the end of the 32bit range for OpenGL as well, issues might arise earlier/later dependent on the used visual effects etc, just like the actual application dictates it for physics (the 50square km estimate was “with no issues whatsoever”). So that requires different adaptations (like moving the world or resetting the cam at borders etc etc).
So, if I can partition the game world, and have several partitions loaded at the same time, say, by keeping the player in the center of a 3x3 square of zones, I should not hit the 32bit limitations. And if the player moves too far from the origin (it takes a while to walk 50km …), I can always “recenter” by recreating all zones with a new center.
But what about the server? If I want to use the “jME3 Headless Server”, doesn’t that also limit me to “contiguous” zones, or at least zones within the 50 km^2 area? Or is there a way of having multiple JME application instances in the same JVM, each with a different scene graph? I was hoping to use he server cluster like a “cloud infrastructure”; loading a new zone into the least loaded server, independent of it’s relationship to other zones in that same server. In fact, I was hoping to be able to have zones from multiple worlds/dimensions loaded inside the same server JVM.
Another reason to want to load multiple unrelated scene graphs at the same time, would be to do something like “Portal”. When you have a “portal”, you would create a trimmed-down scene graph for what is on the other side, render it off-screen, and then paint it on the surface of the portal. But this would require one (or more!) independent scene graph. Is that possible?
Your actual locations don’t have to match the locations on screen as you already stated. You can save them in any resolution you like / that makes sense, you are not forced to use Vector3fs and the RAM of your computer usable for Spatials, you can just use a DB and any coordinate system in the background. The spatials and physics are only needed where players see or physics happens.
