2D Physics System

WIP games, tools & toy projects Archived Projects
#41

I’ve created a google code project for this physics stuff now I’ve sorted a few more bits and pieces out. The project is at:

http://code.google.com/p/phys2d/

SVN browse is here:

http://phys2d.googlecode.com/svn/trunk/phys2d/

The dated fixed builds are still available from:

http://www.cokeandcode.com/phys2d/source/

The webstart has just been updated with some new features:

  • Hardness factors for elastic collisions [EDIT: This doesn’t seem to be working well, extra energy creeping into the pool simulation]
  • Refactored code - now supports pluggable joints, broad collision strategies
  • QuadSpace collision strategy for more optimal body2body collisions detection
  • New collision shape: Line - not 100% on this one yet but seems reasonably. Useful only for static elements.

Finally a new demo screenshot:

http://www.cokeandcode.com/phys2d/screenshots/phys4.png

Webstart is still at: http://www.cokeandcode.com/phys2d/phys2d.jnlp

Just hope the project doesn’t keel now,

Kev

#42

Nice work, that’s really helpful.

Now that lines are supported, could these be the building blocks of 2D polygons?

PS: Cool billiards triangle!

#43

will it ever be able to handle fluids?

#44

Fluids are just lots of tiny spheres.

So it already supports fluids, but probably not fast on current hardware enough to be useful.

Somebody should write a GPU accelerated implementation :wink:

#45

Awesome :o ! I just hope with you kevglass that it will continue…

EDIT : Just 2 small questions : is the collision library separated from the core ? And : can I use your lib in a strategy game with 2D-movement ? actually I use my own detection thingy but it’s naive On2 cost so I saw you implemented quadTree so it’s interesting :slight_smile:

#46

This is a really exciting project, I’ll gladly jump on the bandwagon!

To get smoothness & to cope with sub-60 FPS performance I’ve changed the AbstractDemo’s game loop - it may help to analyse performance, it seems that the stack performs the worst.

Added the following in AbstractDemo:

long nanoTimeLastUpdated = 0;
long cumulativeNanosBetweenUpdates = 0;
float avMillisBetweenUpdates;
int counter = 0;
long tripNanos = 125000000; // 1/8 second, this is how often avMillisBetweenUpdates is updated.

public void start() {
	initGUI();
	initDemo();
	nanoTimeLastUpdated = System.nanoTime();
	while (running) {
		long currentTime = System.nanoTime();
		long timeSinceLastUpdate = (currentTime - nanoTimeLastUpdated); 
		nanoTimeLastUpdated = currentTime;
		cumulativeNanosBetweenUpdates += timeSinceLastUpdate;
		float timeMultiplier = 4;
		world.step((float)timeSinceLastUpdate*timeMultiplier/1000000000f);//frameAverage / 1000.0f);
		// render
		Graphics2D g = (Graphics2D) strategy.getDrawGraphics();
		g.setColor(Color.white);
		g.fillRect(0,0,500,500);
		draw(g);
		renderGUI(g);
		g.setColor(Color.black);
		g.drawString("ms/frame: "+(avMillisBetweenUpdates),10,50);
		g.drawString("FPS: "+(1000f/avMillisBetweenUpdates),10,70);
		//g.drawString("Yield: "+yield,10,90);
		g.dispose();
		strategy.show();
		if (needsReset) {
			world.clear();
			initDemo();
			needsReset = false;
		}
		counter++;
		if (cumulativeNanosBetweenUpdates >= tripNanos){
			avMillisBetweenUpdates = (float)((cumulativeNanosBetweenUpdates)/(counter*1000000f));
			cumulativeNanosBetweenUpdates = 0;
			counter = 0;
		}
		Thread.yield();
		//update();
	}
}
#47

Thanks for the feedbacks.

@CommandKeith - thanks for the code - I’ll use it locally but for personal reasons (GCJ) I need the project to stick to 1.4 right now (this might change if it just gets too plain annoying :))

@Magic - currently you could use the collision system with getting response or doing the physics computations by subclassing World. However, if this is a possible usecase I’ll refactor the world so it can do this without effort.

I’m not intending to add a Fluid layer but if it just sphere then yes it’s fine. However, not something I’ve ever thought of so if it’s useful

To Do in no particular order:

  • Fix hardness/elastic collisions
  • Refactor collision so it can easily be used seperately
  • Test line collisions further and expand to line/line
  • Add polys (either by using multiple lines - or some other neat system)
  • Fixed Joints - joints which don’t allow rotation so we can bind bodies together in one lump
  • Body collision control - define bodies that don’t collide against each other (useful for a bunch of situations)
  • Body collision feedback and control - registering a listener against the world to be notified of collisions and determine whether response should be computed.
  • Performance/Memory
  • Static Body detection
    (These issues are recorded here: http://code.google.com/p/phys2d/issues/list)

If anyone has things to add to the list or wants to get involved with the source (I’m not sure how this works with the google code system yet) then let me know here.

Kev

#48

I’d be glad to help with the source, but I’m still getting my head around it. If you could explain how the box-box collison works or put a couple more comments in I can try to use the ideas for polygons.

#49

Thats a really good question - I don’t really understand box/box collisions - I ported it straight from C. While porting I picked up some of it - but code line for code line I don’t get.

Essentially it projects one box onto the other box’s face axis. It determines if these projected points are on the same side of the face as the centre of the other box. It then clips the points to the segments that actually build up the face. Then some mojo (read: this is the bit I don’t get) cuts if the projected points arn’t on the faces to detect whether its a corner hit. If the points are on the same side as the centre they’re determined as collision points.

At least that’s how it seems to me.

Kev

#50

Thanks for adding lines to the collision bodies, this could potentially be great for a little project I wanted to do but thought I couldn’t.

#51

Ant build of the source with no ant targets specified asks for a keystore password.

#52

Run the compile task - I’m afraid I’ve been unable to update google code since yesterday - subversion commits not responding :frowning:

Kev

#53

This reminds me of http://www.sodaplay.com/constructor/
It seems like this physics engine should be capable of that, and more! 8)

#54

There’s a hell of lot more going on in SodaPlay than it looks like. This physics engine might be able to be used as a base for something similar - but right now the basics need to get solidified.

In case anyone’s interested - I’m currently working on restitution support and integrating the new version of Box2D which seperates out bias and physical velocities.

Kev

#55

There is? Looks like just springs with gravity, friction and stiffness settigns, and a sinus curve “motor” that you can bind to different springs.

I mean, it’s cool and all, but there’s really not that much going on, is there?

#56

I could be wrong - but it looks like theres some IK going on in there too - thats where I am with this physics engine. Probably should have said

“There’s a hell of a lot more going on in SodaPlay than is available in this physics engine”

Kev

#57

No, there isn’t IK, otherwise it would be way too easy to make those ‘robots’ run around: just give a few keyframes and it jumps away.

SodaPlay is really simple, it’s Verlet-Integration AFAIK, you can’t really get it much simpler.

#58

Shows how much I know :wink: Now if I could only prevent engery being adding to the system in my simple 2D system I’d be happy :slight_smile:

Kev

#59

prevent what? Is my English failing me :-[ (or is yours ? ;D)

#60

engery = energy.

Sorry.

Kev ‘Not My Day’ Glass