Tell me more ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.
up vote 8 down vote favorite
1

I want objects to move between two physics simulations through a "window" and collide with those from both simulations in case they intersect the window plane.

The coordinate systems of the simulations don't have the same origin and may have a different orientation. Wrapping a simulation to itself isn't necessary, but would be a plus.

How do I connect the systems efficiently without cloning the individual objects?

Edit:

The calculations should be as accurate as possible, so objects don't get stuck if they cross the window at the same time from opposite sides.

share|improve this question
The first question would be, is the physical simulation to be accurate across the window? Because the orientation changes make a proper sweep pretty impossible. It's kinda like scale changing portals - a world of possible pain. Second question : Different orientation, as in arbitrary, or at least at 90 degree angles, just an axis swap? – Kaj Aug 10 '10 at 20:32
Now, this sounds like a problem they had to address in Portal. If I remember correctly they mention these problems and how they solved them in some in-game commentaries. You can probably find these online somewhere. – Nailer Aug 10 '10 at 20:40
@Kaj I think it would be best to split the calculation path for arbitrary and right-angled transitions. This way, the right-angled ones could have a higher precision and speed while other angles would as well be possible. – Tamschi Aug 10 '10 at 22:00
@Nailer If I remember correctly, they created a new physics environment while the portal was opening and then cloned every physics-object that got near into this additional simulation. They said they somehow constrained the objects, but it's most likely that they are just transforming the forces and positions each physics-step.<br>I'm quite sure that they create a third clone at the destination because of the way player movement is simulated in Source. – Tamschi Aug 10 '10 at 22:14

3 Answers

up vote 2 down vote

There's this cool project called Pseudoform, formerly known as 'Portalized', which handles physics simulations using portals in a groovie fashion:

Pseudoform

Check it out!

Especially the videos - it's staggeringly cool.

It's open source, so you get to see how they do it.

I bet that's what you want. :)

share|improve this answer
2  
I just read through the code: The way they do it is almost like Valve's solution, but without the additional physics environment. Portals in the Portalized engine create a duplicate of an object once it touches the portal surface, then delete it once it has left the portal for a certain time. This answer is still somewhat helpful: The joint used to constrain the duplicates shows how the object is transformed in the portal. – Tamschi Aug 10 '10 at 23:46
up vote 0 down vote

Okay - I do not know if this would work.
Based on the above info I would put triggers on the 'windows' so that I could detect when an object is going out of a world. Grab current velocity vector at time of collision. Calculate timestep left based on where it hit the trigger and where it ended up this frame (outside the world, your world would need a virtual border to allow for this). At this point you know the speed and the timestep left, so you can reposition it on the border of the world it's about to enter, and reproject the velocity. This would however require two physics updates in one frame, and there would be the bordercase of one object going from a to b while another goes from b to a at the same position - there would be no collision detected at all.
Kinda sketchy, but maybe it makes sense somehow?

share|improve this answer
This seems to be the fastest way possible, but there's a problem if two objects cross the window from the same side: If the first object gets stuck mid-way across the border, the second one wouldn't collide until it reached the border, too, and appear inside the first one at the destination. – Tamschi Aug 10 '10 at 22:30
Edited slightly while you typed that, and that was indeed the issue I added :o\ – Kaj Aug 10 '10 at 22:42
I gotta learn to read. My addition was another border case. Will ponder. – Kaj Aug 10 '10 at 22:51
No, the border is outside the world. So object one would be shot into world 2 (from world 2's border - not at the window position) with it's own velocity, as would object b. They'd collide in world 2 on the border properly....I think :o? However my own border case still holds. – Kaj Aug 10 '10 at 22:53
Seems like I misread the part about the virtual border. Anyway, there is another problem if an object gets stuck. The part on the back-side of the destination window will still get rendered at the original position, but objects that don't touch the border won't collide with it. One way to solve these problems would be to unify the simulations, but I'm not sure how this can be done efficiently. – Tamschi Aug 11 '10 at 0:40
show 1 more comment
up vote 0 down vote accepted

I read up some infos on physics simulations and found a possible solution. It works by splitting each physics-step into three phases:

1. Pre-Step:

Each physics-step, a window creates four transformations, two for each side of the connection:

  • an input transformation that transforms an object's position, velocity (and possibly size and weight) into the destination coordinate-system and
  • an output transformation that transforms forces back into the object's original system.

(Static windows only need to do this once.)

Additionally, objects in each coordinate-system are split into three groups:

Physics Grouping

  1. Objects in front of the window (green).
    An object is also counted towards this group if it is intersecting the window plane or likely to cross it from behind the window (not shown).

  2. Objects intersecting the window or likely to intersect it in this physics-step (orange).

  3. Objects behind the window (blue). If an objects flies towards the back-side of the window, it is still marked as member of group three.

Grouping can be simplified if the window is at the simulation's border.

2. Main-Step:

Physics are calculated mostly as usual, with a few exceptions:

  • Objects from the second group never collide with those from the third and vice-versa.

  • The window's input transformation is used on the objects from the second group and the results are evaluated against the front- and intersecting objects from the destination system. The resulting force is transformed using the output transformation and applied to the original object.

(If an object is hit during the calculation, it must be regrouped!)

3. Post-Step:

If an object from the second group has crossed the window, it is moved into the destination system using the input transformation.

Additional Thoughts:

If the transformations are preserved after calculating the physics, they can be used to speed up rendering and for easier AI calculations. The grouping could be used to remove clip-planes from the rendering process.

The downside of this solution is that the windows have to be added directly into the physics-engine.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.