🔒 Locked

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

Started by kyc Jun 5, 2004 at 2:10 AM 18 replies 6.5k views

Original Post

Jun 5, 2004 at 2:10 AM

// 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]

Zipster

Jun 5, 2004 at 2:59 AM

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.

Ademan555

Jun 5, 2004 at 3:17 AM

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

oliii

Jun 5, 2004 at 5:53 AM

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);

	//----------------------------------------------------------------------------------------------------

vnillabrent

Jun 5, 2004 at 11:15 AM

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

kyc

Jun 5, 2004 at 11:19 AM

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.

Airo

Jun 6, 2004 at 8:33 AM

nice demo. good to see a lot of people working on the same stuff

Ademan555

Jun 6, 2004 at 1:08 PM

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

Ademan555

Jun 8, 2004 at 3:53 PM

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

oliii

Jun 8, 2004 at 4:26 PM

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.

kyc

Jun 8, 2004 at 4:49 PM

Speaking of which, I found this error in your pseudocode.

// b = [b0 + b1.t] . [b2 + b3.t]

it should be:
b = [b0 + b1*t] /* add, instead of multiply */ + [b2 + b3*t]

I''ve tried the code, but still had no luck. However, I''ve recently read a little more on quadratics in collision detection so I will give it another try. If that doesn''t work, I''ll resort to Bouncer''s method of connecting particles to approximate shapes.

kyc

Jun 21, 2004 at 6:26 PM

I've finally got the thing working to a level I'm happy with. Penetration happens only in extremely fast movement; otherwise, it is exactly as I wanted to accomplish when I started this whole thing about a year ago. All collision detection and response is incredibly simple yet provides a very believable simulation.

The "solution" to the dynamic line collisions is so damn simple; I cannot believe I was thinking about quadratics! All I had to do was expand the line into a capsule with a radius equal to the larger of the endpoints' velocities. I've rewritten the entire engine and now it is more flexible and refined.

If anyone would like to see what I have now, I'd be happy to upload the new demo. Otherwise, I'll add a GUI, textures, and make it really visually and aesthetically impressive with a simple game demo, rather than the crude graphics I have now. It'd make for a nice surprise :)

kyc

Jun 23, 2004 at 12:16 AM

Well since I've let my friend try it, I mind as well let you guys:)

kycVerlet.zip (130 kb zipped)

oliii

Jun 23, 2004 at 3:02 AM

very kind of you sir.

Yes, it's working very well. :)

There are a couple of of times a triangle edge intersected the large sphere. Haven't seen it happen with smaller spheres.

nice! ;)

Eelco

Jun 23, 2004 at 11:36 AM

ive seen the small sphere get caught in the triangle though.

overall nice work.

kyc

Jul 14, 2004 at 6:39 PM

I'm still working on this :) So far I've added textures, and particles are subject to mass. I've also made some fixes to collision detection and response so the system is more stable. XML support is added, so maps can now be edited. I'm trying to get particle-particle friction working better, but it's currently tolerable and does not subtract from the fun factor. I'd just like the system to be more flexible in case I'd ever want friction to be an important gameplay factor.

Now I just want to work out a few kinks and then I'll get to the widgets. I'm also thinking about making a detailed tutorial about how I'm detecting collisions and resolving them. I'd just like a show of hands to know if the tutorial would be helpful and is worth writing. Now that there are tutorials from olivier, jamie, and metanet, I don't know if people would still be interested in my take of 2d "physics." Just so you know, my methods are unconventional as I just go by what's easy and make almost random tweaks until I get the desired effects. I don't know if it's mathematically correct but it's simple, inexpensive, and looks good, so consider it an idiot's guide to fake physics =)

kyc

Jul 19, 2004 at 2:45 AM

I'm almost done with a little game I'm entering in a competition.
It's 2D ragdoll fighting with some very simple yet surprisingly cool ai. The game has "bullet time," and features Spiderman with webslinging action :P and possibly 2 other characters to choose from. The ai opponents will be based on seemingly animalistic behavior, such as vulture or wolf. For the time being I plan to support 2 players on the same same computer and about 10 ai opponents. I promise to have it in a stable playable state in 2 weeks, but demos will be available asap as I don't have much further to go.

If I get the chance, I'll upload a screenshot later tonight.

oliii

Jul 19, 2004 at 2:54 AM

spiderman, right on time!

Is that anything like that
Ragdoll kung fu demo?

kyc

Jul 26, 2004 at 2:45 AM

That ragdoll kungfu looks interesting, and I'm rather tempted to try making my own version of it.

My game, however, is more like ragdoll megaman :) It's all about slamming yourself skillfully on your opponent and building up your character's strength. The adventure mode will be much like hic quest on the TI-Basic. You will money by fighting 10 different ai opponents, who can be fought over and over again until you get comfortable with the controls or to earn more money. With the money, you can increase your intelligence (increases head mass), or pump up your legs (increase leg mass) :) You can also purchase a skateboard (the smaller board player1 has in the demo) and a skateboy 9000 (the bigger board player2 has in the demo).
You start out without a skateboard, btw, I only put it in the demo to demonstrate the coolness of it:) You can edit out the constraint in players.xml to get an idea of how it'd play when you first start out. Play around with players.xml by changing masses or adding more particles/constraints. Be careful when you do that, because I have not been strict on checking for errors but you shouldn't have a problem if you're careful.
Be sure to backup files before trying to edit them.
There are probably more loose ends I haven't mentioned, but I'll keep shut for now since the release is near!
I'll try not to dissapoint :P

kyc

Aug 17, 2004 at 1:35 PM

bump, cuz i see some people battling the same problems so maybe this'll help them.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.