I'm curious if there's a good method to approach a world which is square, but where you wrap around if you hit the edge of the world, without fudging it. Will I have to root around in the source and implement some method where entities are tested against the world as if they were at (0, 0) and everything else is transformed to be relative to their position, or is there some kind of support for that already? If I do need to implement it myself, are there any snafus or gotchas I should be aware of?
EDIT: Great work on the library by the way, it's pretty amazing!
Wrap around a square world
Re: Wrap around a square world
The main problem is going to be edge behavior. When the character is straddling the threshold of the world, it is essentially in two places at once because the engine is restricted to euclidean space.
Ideally, the world would be large enough such that when the character arrives at the edge of the world, the other 'real' edge is too far away to be involved in the current simulation. That way, duplicates that are on the other side of the world can be ignored (removed from the space at some point) and the local simulation that straddles the boundary is the only one that needs to considered. For the sake of intuitiveness, rather than considering it to 'wrap around' in this model, it might be easier to consider it as an infinitely repeating world where only a local section of it is being simulated at any one time. The appearance of wrapping would arise from tricky management of the dynamic objects: when they go inactive, store their position relative to the square world; when they become active again, put them back in the proper location relative to the geometry and player.
There is one big issue with considering it to be an infinitely repeating world in implementation: after a few worlds worth of walking, numerical precision will become very poor. So, instead of actually allowing the player to continue walking in absolute coordinates forever, maintain a margin and when the player walks out, teleport everything back to more local coordinates. For example, you could have a 3x3 set of copies of your static world. If the player walks more than halfway out into any of these copies, the character and everything else has its Position set to be in the same location relative to the center world.
If the world is small such that everything needs to be simulating at the same time, things are a bit harder. A fully correct solution would look like implementing portals. Entities straddling the barrier would have two collision shapes, each detecting contacts on one side of the portal. To get this fully correct, you would need to modify solving behavior a little bit- contact constraints for a straddling entity would be accessing one entity, but using the two collision shape transforms for determining effective mass matrices. Implementing this would require significant familiarity with how the solver and constraints work.
Another option, one step less difficult/accurate, would be to duplicate the entity and bind the two versions of itself together with a constraint. There would need to be a NoRotationJoint between the two duplicates to ensure that they maintain a similar orientation. Managing translation is a little trickier; there's no built-in constraint which is designed to maintain a fixed world space offset between the centers of two entities. Creating a specialized constraint for that would be pretty easy as far as constraints go; you wouldn't have to worry about transforming anything into local space or keeping track of jacobians (the effective mass would be just a simple scalar based on the masses of the entities). At each solver iteration, it would compare the linear velocities and apply an equal and opposite impulse to make them equal, plus a little extra force to fix any positional error that accumulates over time.
While it wouldn't be too hard to make such a specialized linear constraint, you might be able to get 90% of the way there with a NoRotationJoint and just directly setting the duplicate entity's Position and LinearVelocity to match. It won't be quite as robust as a true solver implementation, but it might be enough.
Ideally, the world would be large enough such that when the character arrives at the edge of the world, the other 'real' edge is too far away to be involved in the current simulation. That way, duplicates that are on the other side of the world can be ignored (removed from the space at some point) and the local simulation that straddles the boundary is the only one that needs to considered. For the sake of intuitiveness, rather than considering it to 'wrap around' in this model, it might be easier to consider it as an infinitely repeating world where only a local section of it is being simulated at any one time. The appearance of wrapping would arise from tricky management of the dynamic objects: when they go inactive, store their position relative to the square world; when they become active again, put them back in the proper location relative to the geometry and player.
There is one big issue with considering it to be an infinitely repeating world in implementation: after a few worlds worth of walking, numerical precision will become very poor. So, instead of actually allowing the player to continue walking in absolute coordinates forever, maintain a margin and when the player walks out, teleport everything back to more local coordinates. For example, you could have a 3x3 set of copies of your static world. If the player walks more than halfway out into any of these copies, the character and everything else has its Position set to be in the same location relative to the center world.
If the world is small such that everything needs to be simulating at the same time, things are a bit harder. A fully correct solution would look like implementing portals. Entities straddling the barrier would have two collision shapes, each detecting contacts on one side of the portal. To get this fully correct, you would need to modify solving behavior a little bit- contact constraints for a straddling entity would be accessing one entity, but using the two collision shape transforms for determining effective mass matrices. Implementing this would require significant familiarity with how the solver and constraints work.
Another option, one step less difficult/accurate, would be to duplicate the entity and bind the two versions of itself together with a constraint. There would need to be a NoRotationJoint between the two duplicates to ensure that they maintain a similar orientation. Managing translation is a little trickier; there's no built-in constraint which is designed to maintain a fixed world space offset between the centers of two entities. Creating a specialized constraint for that would be pretty easy as far as constraints go; you wouldn't have to worry about transforming anything into local space or keeping track of jacobians (the effective mass would be just a simple scalar based on the masses of the entities). At each solver iteration, it would compare the linear velocities and apply an equal and opposite impulse to make them equal, plus a little extra force to fix any positional error that accumulates over time.
While it wouldn't be too hard to make such a specialized linear constraint, you might be able to get 90% of the way there with a NoRotationJoint and just directly setting the duplicate entity's Position and LinearVelocity to match. It won't be quite as robust as a true solver implementation, but it might be enough.
ThanksEDIT: Great work on the library by the way, it's pretty amazing!
Re: Wrap around a square world
Thanks for the in depth response!
I guess I should've given a little more background information though. The world is so massive already that floating point precision became an issue before with rendering (seams in between chunks of the world, z-fighting, etc) and I solved that by having entities use doubles instead of floats for the extra precision, and translating everything relative to the player around the zero point when rendering. This works for rendering since there's only the one point of reference to take into account. The game logic needs to support multiplayer though, so I don't think that'd work. At least not as cleanly as it would for a completely single player game. So as far as I see it I've got the following options, correct me if I'm wrong on any of these or if I missed any...
An easy solution would be to keep a copy of the entire Scene per player. That'd be awfully memory hungry though, I imagine, so not really a good solution. Another solution could be the constraints you're mentioning, and keeping duplicates of anything near the world borders. I suppose that looks like the most likely candidate.
At first I thought I could edit the system itself to create pairs by passing their relative positions along as well, but upon looking through the code that seems... a somewhat less than realistic option. I mean, it looks like I could but I don't know what kind of effect that would have with threading and other optimizations I might be overlooking. EDIT: Upon rereading, I think this is what you meant when you mentioned the portal solution. I'm going to have to look into whether or not I can get that figured out, since I dislike half measures.
I guess I should've given a little more background information though. The world is so massive already that floating point precision became an issue before with rendering (seams in between chunks of the world, z-fighting, etc) and I solved that by having entities use doubles instead of floats for the extra precision, and translating everything relative to the player around the zero point when rendering. This works for rendering since there's only the one point of reference to take into account. The game logic needs to support multiplayer though, so I don't think that'd work. At least not as cleanly as it would for a completely single player game. So as far as I see it I've got the following options, correct me if I'm wrong on any of these or if I missed any...
An easy solution would be to keep a copy of the entire Scene per player. That'd be awfully memory hungry though, I imagine, so not really a good solution. Another solution could be the constraints you're mentioning, and keeping duplicates of anything near the world borders. I suppose that looks like the most likely candidate.
At first I thought I could edit the system itself to create pairs by passing their relative positions along as well, but upon looking through the code that seems... a somewhat less than realistic option. I mean, it looks like I could but I don't know what kind of effect that would have with threading and other optimizations I might be overlooking. EDIT: Upon rereading, I think this is what you meant when you mentioned the portal solution. I'm going to have to look into whether or not I can get that figured out, since I dislike half measures.
Re: Wrap around a square world
In a multiplayer situation where the assumption is that the entire simulation needs to be online, then one of the portal implementations (deep modifications to contact management, constraints, or otherwise) would indeed be the likely solution.
Some forms of multiplayer would still be compatible with a non-duplicating scheme, but managing the simulation pieces would introduce some complexity of its own. For example, the world could be decomposed into interaction islands (groups of objects and the players which are interacting with them) which do not span from one edge of the world to the other. A set of objects and players on either side of a boundary would be in the same contiguous space with no need for duplication.
Some forms of multiplayer would still be compatible with a non-duplicating scheme, but managing the simulation pieces would introduce some complexity of its own. For example, the world could be decomposed into interaction islands (groups of objects and the players which are interacting with them) which do not span from one edge of the world to the other. A set of objects and players on either side of a boundary would be in the same contiguous space with no need for duplication.