Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 3 [4]
  ignore  |  Print  
  2D Physics System  (Read 25184 times)
0 Members and 1 Guest are viewing this topic.
Offline ryanm

Senior Duke


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.
Offline 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  Tongue - 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. 

Offline ryanm

Senior Duke


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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Daniel_F

Junior Duke


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  Smiley
Offline 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  Smiley

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...

Offline 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  Angry

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.

Offline Daniel_F

Junior Duke


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? Roll Eyes

Speed-wise they should be the same.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 816
Projects: 4
Exp: 16 years


Hand over your head.


« 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
Offline 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:

http://www.velocityreviews.com/forums/t134954-float-vs-double-speed-on-p4-machine.html, see Roedy Green's reply.

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.

Offline kevglass

JGO Kernel


Medals: 186
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


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

Ok, you're getting pretty close now Smiley 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 Smiley

Your dollar,

Kev

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline 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.

Offline 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  Smiley.  I'll give it a go eventually too
.
Keith

Offline Evil-Devil

Senior Duke


Medals: 2


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.
Offline 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 Smiley.

Keith

Offline Death33284

Junior Duke





« 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 Smiley.

Keith

Good to know this hasn't been abandoned.  Smiley

Looking forward to the newer versions
Pages: 1 2 3 [4]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (41 views)
2014-10-17 03:59:02

Norakomi (33 views)
2014-10-16 15:22:06

Norakomi (26 views)
2014-10-16 15:20:20

lcass (30 views)
2014-10-15 16:18:58

TehJavaDev (59 views)
2014-10-14 00:39:48

TehJavaDev (60 views)
2014-10-14 00:35:47

TehJavaDev (50 views)
2014-10-14 00:32:37

BurntPizza (66 views)
2014-10-11 23:24:42

BurntPizza (38 views)
2014-10-11 23:10:45

BurntPizza (80 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!