#### Archived

This topic is now archived and is closed to further replies.

# My Demo like Bouncer's Demo, Gish, N, Soldat

This topic is 5148 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

// 8/17/04 in case you don't know, here's the latest version. // 8/17/04 // Edited July 26, 2004 <br /> 511 kb, self-extracting Only options 3 and 4 work in the main menu. Rest assured, there will be many more things that will be implemented in the coming week. In one week, it will be an actual game with better graphics, gameplay, life, bullet time, web slinging, web balls that freeze, matrix slow motion, etc... Requires hardware acceleration, otherwise game will be laggy and choppy. Should not be a problem except for my friend who has a lousy 200 mhz windows 98 and gets 5 fps :) // End of edit -- July 26, 2004 I don't know about Gish but I'm pretty sure it uses verlet integration also. In fact, just by making the constraints with very low rigidity, I was able to imitate Gish's movements -- even its jumping dynamic. Everything is pretty stable now, except for dynamic line collisions. Despite this, it still works pretty well; particle collisions are complete, meaning that a particle with a velocity of say 200,000 would still be detected correctly. The only thing bugging me is when a line is moving too fast. I have two versions: "Loose" version has the mentioned dynamic line problem, but has a feel much more suitable for games; "Heavy" version detects dynamic lines well (I haven't experienced any missed collisions with this version), however the line's movement is hindered when it collides with a particle (you'll have to see for yourself to understand what I mean). NetDeath_6-4-04_Loose_Heavy_bin.zip ~243 kb I'd like to use the Loose version and fix the collision detection (I simply test the current position, without thinking about its velocity). If Gish can do this, I'm sure there's a way (unless it uses Bouncer's way of connecting particles); I tried deriving a swept line procedure, but ended up with bad results. On the other hand, Heavy version subdivides along the line's velocity and when it finds a collision, simply sets the positions to the current subdivision. Both versions use basic impulse; the equations were taken from euclideanspace. <SPAN CLASS=editedby>[edited by - kyc on June 5, 2004 3:14:23 AM]</SPAN> [Edited by - kyc on August 17, 2004 1:33:43 PM]

##### Share on other sites
And I wanted to learn Direct3D... looks like all the fun is in physics

Cool demo. Very realistic with both modes, at least to me.

##### Share on other sites
wow, you wouldnt be willing to reveil where you got your line collision functions woudl you?... i thought i was doing great till i realized that lines dont just translate, they rotate :-/ if you came up with them yourself... major props and wish me luck
-Dan

##### Share on other sites
I''ve been trying to get this right for some time as well.

when you do swept segment vs swept segment, there is only one type of collision to consider. Point segment. it''s always gonna be a point versus a segment, which makes it easier.

OK, I''ve got a point P0 travelling, and an edge made with vertices P1, P2, also moving.

they will impact at time t. so

P0'' = P0 + V0.t
P1'' = P1 + V1.t
P2'' = P2 + V2.t

and at that precise moment in time, the point P will be on the segment [P1'', P2'']

let''s call N = Perp([P1'', P2'']), a vector perpendicular to the segment

therefore (P0'' - P1'') . N = 0

here are the details of the calculations, which define a second order equation to solve.

	//----------------------------------------------------------------------------------------------------	// point [P]    : P = P0 + V0 . t	// edge  [A, B] : A = P1 + V1 . t	//                B = P2 + V2 . t	//	// N = Perp(B - A);	//	// at time of impact, (P - A) . N = 0	//	// P - A = Vector((p0x - p1x) + (v0x - v1x) . t, (p0y - p1y) + (v0y - v1y) . t); 	// N     = Vector((p1y - p2y) + (v1y - v2y) . t, (p2x - p1x) + (v2x - v1x) . t); 	//	// a  = [(p0x - p1x) + (v0x - v1x) . t] . [(p1y - p2y) + (v1y - v2y) . t];	// b  = [(p0y - p1y) + (v0y - v1y) . t] . [(p2x - p1x) + (v2x - v1x) . t];	//-----------------------------------------------	// a0 = (p0x - p1x);	// a1 = (v0x - v1x);	// a2 = (p1y - p2y);	// a3 = (v1y - v2y);	// a  = [a0 + a1.t] . [a2 + a3.t]	// a  = (a0.a2) + t.(a0.a3 + a1.a2) + t²(a1.a3)	//-----------------------------------------------	// b0 = (p0y - p1y);	// b1 = (v0y - v1y);	// b2 = (p2x - p1x);	// b3 = (v2x - v1x);	// b  = [b0 + b1.t] . [b2 + b3.t]	// b  = (b0.b2) + t.(b0.b3 + b1.b2) + t²(b1.b3)	//-----------------------------------------------	// A.t² + B.t + C = 0	//-------------------	// A = (a1.a3) + (b1.b3)	// B = (a0.a3  + a1.a2).(b0.b3 + b1.b2)	// C = (a0.a2) + (b0.b2);	//----------------------------------------------------------------------------------------------------

##### Share on other sites
kyc,

Its nice to see what you''ve been up to. For a while I was following the development of your program. I''m very impressed.

I am also working a 2D platform game using dynamic line/ellipse collisions. Some of the work I''m doing is on my site.

As for your problem, I would love to help you but apparently we''re handling collisions very differently. It seems that you''re using particles and constraints while I am using implicit lines and ellipses. If you ever need help in other areas, feel free to e-mail me.

---
email | website

##### Share on other sites
Dan: I''ll assume you know how to determine if a particle with a velocity collides with a static line segment. Once you know they collide, position the particle so that it just touches the line, then apply an impact to the endpoints and the particle.

line.p1.destination -= Impact;
line.p2.destination -= Impact;
particle.destination += Impact;

You can manipulate it further by weighing them relative to their masses.

If you want me to elaborate on anything, just let me know and I''ll try to put up a quick tutorial with diagrams. Good luck

Oliii: I was hoping to hear from you, and I did realize it was simplified into a moving particle vs moving segment test. I came up with the same equations, but could have made an error when expanding. I''ll definately try out your code, thanks a lot.

##### Share on other sites
nice demo. good to see a lot of people working on the same stuff

##### Share on other sites
yeah, i have no clue as to how i should position the circle so that it just touches the line (segment), ive been trying to work on some sort of projection solution, like transforming one point of the segment to 0, 0 and then projectiong the radius of the circle onto the segment (when i said radius, i meant a radius length vector in the x+ direction) it doesnt work i dont think, and i have no idea how i came up with it... but meh lol
-Dan

##### Share on other sites
oliii, is the . dot product? (since that IS pseudocode right?)
(well in any case it sure as heck isnt c++ lol)
-Dan

##### Share on other sites
sometimes it''s a dot, sometimes it''s a scalr mul capital named variables are vectors, lower case are floats. except the last 3 A, B, C In my codes usually, I have ''*'' as both scalar/dot products.

it''s just the equations, or comments leading to my code. I''d suggest you double check them beforehand. I had a quick test and it seems fine, *but*... it was quick.

1. 1
2. 2
Rutin
20
3. 3
4. 4
frob
15
5. 5

• 10
• 9
• 13
• 9
• 33
• ### Forum Statistics

• Total Topics
632592
• Total Posts
3007289

×