Java-Gaming.org Hi !
 Featured games (91) games approved by the League of Dukes Games in Showcase (757) Games in Android Showcase (229) games submitted by our members Games in WIP (844) games currently in development
 News: Read the Java Gaming Resources, or peek at the official Java tutorials
Pages: 1 2 3 [4]
 ignore  |  Print
 2D Physics System  (Read 52329 times) 0 Members and 1 Guest are viewing this topic.
ryanm

Senior Devvie

Projects: 1
Exp: 15 years

Used to be bleb

 « Reply #90 - Posted 2006-09-04 09:02:45 »

It probably won't solve all your problems, but I would recommend changing your collision detection routines from looking for points inside polygons ( O(n*n) unless you're doing something really clever ) to looking for intersections between line segments ( can be done in O(n log n ) ).
As well as being more scalable, it will catch collisions that looking for point inclusion won't, particularly with fast-moving or thin bodies.

Once you've identified an intersection, you need to determine which is the incident face, and which is the penetrating vertex. This can be a bit tricky, but you can generally get away with just choosing the solution that results in the smallest corrective impulse.
CommanderKeith
 « Reply #91 - Posted 2006-09-04 10:07:47 »

Good idea.  Originally I did use intersections but the trouble was that there were 2 contact points to apply forces to for every overlap rather than just one inner point.  Getting the force angles & sizes right for 2 force-points was too tricky.  Also the code I made for that method was about 3 times longer than what I have here - this (& the fact it didn't work properly anyway) made me wonder whether it would actually be more efficient.

I actually hadn't thought about thin bodies at all  - the inner point method with a slow frame rate or fast object will completely miss collisions.  But this could be solved by updating the physics multiple times between redraws.  Since the actual physics calculations are pretty fast (its only drawing that can take ages) that problem should be fixable for anybody who runs into it.

Thanks for the pointers,
Keith

EDIT: come to think of it, fast-moving bodies/slow frame rate/ thin bodies problem will still be present in the intersection method because of the smallest-impulse way of computing the angle of the force, will it not?  Both probably need to be solved by doing small time updates.

ryanm

Senior Devvie

Projects: 1
Exp: 15 years

Used to be bleb

 « Reply #92 - Posted 2006-09-04 10:57:04 »

EDIT: come to think of it, fast-moving bodies/slow frame rate/ thin bodies problem will still be present in the intersection method because of the smallest-impulse way of computing the angle of the force, will it not?  Both probably need to be solved by doing small time updates.

Not necessarily, it all depends on how you determine which is the incident face and which is the offending vertex.
Choosing the smallest impulse solution should probably be the last resort after you've exhausted looking at the two body's relative velocities and so on.
Daniel_F

Junior Devvie

Projects: 2

Java games rock!

 « Reply #93 - Posted 2006-09-04 13:14:46 »

Very cool physics engine, I like especially the stacking demo part.

Did somebody consider doing a bridgebuilder type demo-game with it? Seems the main part (physics) is already ready
CommanderKeith
 « Reply #94 - Posted 2006-09-11 09:41:55 »

Did somebody consider doing a bridgebuilder type demo-game with it? Seems the main part (physics) is already ready

Kev's code is certainly ready to do stuff like that, give it a try!

I can't wait to use this in a game either, trouble is that i need polygons and i've got to iron out the bugs...

CommanderKeith
 « Reply #95 - Posted 2006-09-13 07:51:41 »

This is my progress on polygons, its working much better now that there's no overlapping.  To solve that I just had to use a negative 'separation' value... grrrrrrr

This has mitigated some of the troubles, but as you'll find in demo 9 with the stacking triangles, there are still massive problems.

WebStart: www.freewebs.com/commanderkeith/PolygonPhysics.jnlp

Source: www.freewebs.com/commanderkeith/PolygonPhysicsSource.zip (note that this is a work in progress, I haven't worked in Kev's original Boxes etc yet)

Keith

PS: Here are some performance stats to compare the original code with the polygon code.  To get these stats I just looped world.step(0.02f) 3000 times using the stacking box demo for both:
Polygon boxes:
seconds elapsed: 12.169297
nanos per world.step(0.02f): 4056432.2

Box boxes:
seconds elapsed: 9.543804
nanos per world.step(0.02f): 3181268.0

So the polygon collision code takes about 28% longer.  This can be improved once I profile it.

Daniel_F

Junior Devvie

Projects: 2

Java games rock!

 « Reply #96 - Posted 2006-09-18 11:24:02 »

I looked a bit more into it and I wonder why is everything float and not double?

Speed-wise they should be the same.
Riven

« JGO Overlord »

Medals: 1340
Projects: 4
Exp: 16 years

 « Reply #97 - Posted 2006-09-18 14:33:55 »

With these kind of dimensions you don't need more than 7 significant digits.

And you save half the RAM. (but that's peanuts)

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
CommanderKeith
 « Reply #98 - Posted 2006-09-19 03:19:39 »

I used floats because I thought they were faster than doubles, but apparently they aren't:

It could be changed to doubles, but it would be a bit of work removing all of the float casts.  Not much point anyway, as Riven said there's not much of an advantage to have that little bit of extra precision.

Thanks for taking a look at the code.  By the way, I've changed the polygon collsion code so its working much better.  I'll post it and a new demo in a couple of hours.  I figured out what was making the triangles demo go haywire - I was scaling the triangle's y-coordinates by -1 to flip them over, but that meant that the points weren't listed in anti-clockwise order which is what the collision code assumes.  Anyway, now the triangles bounce off properly and you don't see the big ones sucking the smaller ones in.

kevglass

« JGO Spiffy Duke »

Medals: 319
Projects: 25
Exp: 22 years

Coder, Trainee Pixel Artist, Game Reviewer

 « Reply #99 - Posted 2006-09-19 03:46:07 »

Ok, you're getting pretty close now So, how do you want to go about integrating these changes. If you've changed alot of stuff unrelated to the collision code then we've got two choices:

1) I integrate stuff, probably modifing your mods on the way to fit in with the existing code

2) You integrate stuff (I add you to the authors on google code) and you can modify it however is easiest for you.

With 1) it may take me a while (given upcoming commitments). With 2) you'll end up taking the brunt of the flak as people find problems and need them resolved. Either way it might well make sense to add your the project on google code if you're so inclined

Kev

CommanderKeith
 « Reply #100 - Posted 2006-09-19 05:28:36 »

There's still problems with my code such as with fast-moving thin bodies & also with intersecting vertices where neither vertice is inside the other shape, which you'll see in the next demo.  I think I can only solve it by using intersections (as bleb prescribed), but I'll apply the forces at each bodies' vertices, not at the intersections themselves (this shouldn't require too much extra work).

Until I solve this I think its best to keep your working code away from my buggy version.  If you want to add my project on to google code and have the two going in parallel that's fine.

Thanks for offering to integrate them.  Hopefully I will be able to do most of it - at least the parts that only I understand.  I'll post the new demo & code soon.

Keith

PS: I haven't changed too much except for what I said before: making the bounds a max radius from a centroid point.
The only other important change was using Point2D.Float class rather than Vector2f  - but that's not too much work to change.

I don't really like Point2D.Float anyway since you can't serialize it or extend it.  Though I'd like to add some more methods to Vector2f  if you don't mind - like setX, setY, getPoint2DFloat() and let it implement Serializable.

CommanderKeith
 « Reply #101 - Posted 2006-09-19 09:52:19 »

Web Start: http://www.freewebs.com/commanderkeith/PolygonPhysics.jnlp

Demos 11, 6 & 9 show the problems I mentioned - I think both can be mitigated by using line intersection.

I think this could be used by someone to make a cool Worms type of game  .  I'll give it a go eventually too
.
Keith

Evil-Devil

Senior Devvie

Medals: 3

Fir Tree Master

 « Reply #102 - Posted 2006-09-20 10:07:50 »

@Float vs Double: Don't forget that opengl uses internally only floats. So the speed gain might be lost due the downcast from double to float.
CommanderKeith
 « Reply #103 - Posted 2006-10-08 09:25:42 »

Hi,

I just want to let people know that I won't have time to work on this project until November.

I haven't lost interest at all - I've just got a deadline on the 30th of October that I'm running late for.  I will get the polygons working seemlessly in November .

Keith

Death33284

Junior Devvie

 « Reply #104 - Posted 2006-10-10 21:06:53 »

Hi,

I just want to let people know that I won't have time to work on this project until November.

I haven't lost interest at all - I've just got a deadline on the 30th of October that I'm running late for.  I will get the polygons working seemlessly in November .

Keith

Good to know this hasn't been abandoned.

Looking forward to the newer versions
Pages: 1 2 3 [4]
 ignore  |  Print

 EgonOlsen (42 views) 2018-06-10 19:43:48 EgonOlsen (22 views) 2018-06-10 19:43:44 EgonOlsen (43 views) 2018-06-10 19:43:20 DesertCoockie (197 views) 2018-05-13 18:23:11 nelsongames (124 views) 2018-04-24 18:15:36 nelsongames (123 views) 2018-04-24 18:14:32 ivj94 (864 views) 2018-03-24 14:47:39 ivj94 (125 views) 2018-03-24 14:46:31 ivj94 (768 views) 2018-03-24 14:43:53 Solater (140 views) 2018-03-17 05:04:08
 Java Gaming Resourcesby philfrei2017-12-05 19:38:37Java Gaming Resourcesby philfrei2017-12-05 19:37:39Java Gaming Resourcesby philfrei2017-12-05 19:36:10Java Gaming Resourcesby philfrei2017-12-05 19:33:10List of Learning Resourcesby elect2017-03-13 14:05:44List of Learning Resourcesby elect2017-03-13 14:04:45SF/X Librariesby philfrei2017-03-02 08:45:19SF/X Librariesby philfrei2017-03-02 08:44:05
 java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org