Simulation and Collision on manually attached objects
by Rich Wilson · in Torque X 2D · 02/20/2007 (10:58 am) · 5 replies
So here's what I want to do:
I have 2 objects controlled by physics, player input, whatever. I want to have a line drawn between these 2 objects dynamically and calculate collision for things that hit that line and whatever it sweeps through between frames.
I was told that manually positioning something every frame kind of loses the benefits of the built in collision, so how would I go about doing this?
I have 2 objects controlled by physics, player input, whatever. I want to have a line drawn between these 2 objects dynamically and calculate collision for things that hit that line and whatever it sweeps through between frames.
I was told that manually positioning something every frame kind of loses the benefits of the built in collision, so how would I go about doing this?
About the author
#2
The main thing I'm trying to figure out is the collision. I've already written the point to line collision detection algorithm, to see if any objects hit the line. These will be more complex objects when I actually start implementing.
When everything gets put into motion, however, the line becomes a trapezoid with the current and former positions of the endpoints becoming the 4 corners. I was hoping there was a prettier way to do this. Now that I think about it though, I saw something about a t2dpolygon object. I might could create one of these every frame with the aforementioned points and calculate collsion from there. My only reservation is that some things that are moving too fast might slip past since I'm using discrete per frame calculations instead of a more continuos model.
02/20/2007 (1:49 pm)
I'm not that worried about the drawing part. I managed to make a little chain of small sprites in XNA and director when I was prototyping this idea. The main thing I'm trying to figure out is the collision. I've already written the point to line collision detection algorithm, to see if any objects hit the line. These will be more complex objects when I actually start implementing.
When everything gets put into motion, however, the line becomes a trapezoid with the current and former positions of the endpoints becoming the 4 corners. I was hoping there was a prettier way to do this. Now that I think about it though, I saw something about a t2dpolygon object. I might could create one of these every frame with the aforementioned points and calculate collsion from there. My only reservation is that some things that are moving too fast might slip past since I'm using discrete per frame calculations instead of a more continuos model.
#3
For example we'll consider a fast moving ball and a thin wall. In the first frame the ball is six units above the wall. In the next frame the ball is six units below the wall. A naive solution would be to draw a straight line between the current and previous position and assume collision if it intersects the wall. What if the ball didn't move in a straight line? What if the ball moved in a circular pattern around the wall? You'll have to spend time saving and interpolating the data each frame with data from the previous n frames. That sounds too hard lets just make an assumption based on the velocity of last frame and this frame. What if the movement of ball was shaped like a W between those two frames? It could have crossed the wall many times even though its velocity might indicate it never came near it.
These are just a few of the issues of industrial strength collision detection but it should give you an idea of the complexity involved in coming up with a fully general solution. Most of the time games treat collision detection as a matter of "good enough" and "believable in all reasonable cases." The exact meaning of either one of those things depends on your specific game.
02/20/2007 (3:28 pm)
Collision on fast moving objects or low collision check frequency is always a hard problem. It is a problem with no generally applicable solution. It is something that I believe has to be solved on a per game basis.For example we'll consider a fast moving ball and a thin wall. In the first frame the ball is six units above the wall. In the next frame the ball is six units below the wall. A naive solution would be to draw a straight line between the current and previous position and assume collision if it intersects the wall. What if the ball didn't move in a straight line? What if the ball moved in a circular pattern around the wall? You'll have to spend time saving and interpolating the data each frame with data from the previous n frames. That sounds too hard lets just make an assumption based on the velocity of last frame and this frame. What if the movement of ball was shaped like a W between those two frames? It could have crossed the wall many times even though its velocity might indicate it never came near it.
These are just a few of the issues of industrial strength collision detection but it should give you an idea of the complexity involved in coming up with a fully general solution. Most of the time games treat collision detection as a matter of "good enough" and "believable in all reasonable cases." The exact meaning of either one of those things depends on your specific game.
#4
I might just do the per frame calculations and see how much falls through the proverbial cracks. This isn't a thesis project or anything, after all.
02/20/2007 (3:34 pm)
And I guess my trapzoid/line extrapolation of line/point over time is insufficient since it doesn't account for speed and where each entity was in relation to the other over the span the 2 passed over. It makes my head hurt.I might just do the per frame calculations and see how much falls through the proverbial cracks. This isn't a thesis project or anything, after all.
#5
02/20/2007 (5:04 pm)
I think that's a marvelous idea. No sense trying to come up with the "optimal" collision solution when you don't know if the stock solution will be insufficient! 
Torque 3D Owner Jonathon Stevens
Your component would simply reshoot itself every tick from one to the other. You would have a line shooting component and a line catching component.
Obviosly, you'd have to take it from there and fine tune it as to not hit the wrong receive, but that would be a simple property and so on.
Do I sound crazy or what?