Physics bug or programmer flaw? :-)

#1 @Terry: Here's how you do it...

datablock fxCollisionMaterialDatablock2D(BallMaterial)
{
	friction = 0.1;
	restitution = 0.6;
	relaxation = 0.5;
	density = 0.01;
	forceScale = 1;
	damping = 0.2;
};

// Create some balls.
function createBalls( %qty )
{
	// Create Ten Balls.
	for ( %n = 0; %n < %qty; %n++ )
	{
		// Create a Sprite.
		%ball = new fxStaticSprite2D() { scenegraph = t2dSceneGraph; };
		%ball.setSize("6 6");
		%ball.setImageMap(ggLogoImageMap);
		// Front Layer.
		%ball.setLayer( 0 );
		// Group #1.
		%ball.setGroup( 1 );
		// Ball Material.
		%ball.setCollisionMaterial(BallMaterial);
		// We want to active collision checking.
		%ball.setCollisionActive(true, true);
		// We want full physics response.
		%ball.setCollisionPhysics(true, true);
		// Quite a fine circle.
		%ball.setCollisionPolyPrimitive(24);
		// Objects collide with group#1 / layer#0.
		%ball.setCollisionMasks( BIT(1), BIT(0) );
		
		// Use Rigid-body response from world-limit.
		%ball.setWorldLimit( rigid, "-49 -37 49 37" );
		
		// Random Position/Velocity.
		%ball.setPosition((-40+getRandom()*80) SPC (-20+getRandom()*30));
		%ball.setLinearVelocityPolar( getRandom()*360, 10+getRandom()*20);
	}
	
	// Start the gravity after a few seconds, just so we see it start!
	schedule( 3000, 0, "startGravity" );
}

// Start the scene-wide gravity.
function startGravity()
{
	// Constant Force.
	t2dSceneGraph.setConstantForce("0 10000", true);
}

... then just add something like ...

createBalls( 20 );

You don't have to use all this stuff but I like making mini tutorials. :)

In your original collision-material datablock, you had restitution at zero. This is like throwing a wet tea-bag at a wall, not really like a bouncy ball. That needed increasing. Next you set relaxation to 0. This controls the bias between collisions for objects. 0.5 = %50 distribution which is what you'll use nearly all the time. Density was 1 which is along the lines of a neutron star so this is pretty dense! Reduced that. The force-scale was 50 which multipled all your forces by x50 so the constant force you applied was (32000x50) which is huge but so was your density so your mass/interia slightly counteracted it!

This does show well the classic problems you get if your not careful. You're balancing huge forces with huge masses and a slight misbalance and the object whizzes off. The great thing about the swept polygon stuff is that you find it doesn't whizz off into infinity which is a classic problem of other types of collision detection.

I changed the world-limit mode to "rigid" instead of "bounce" which gives you the rigid-body response. Bounce doesn't use the collision-material. As it says in the ref doc, it just gives you the class perfect bounce. Certain things from the material did still affect the object such as density etc.

I added the ability for the balls to interact with each other. I did this by assigning the balls to group#1 and layer#0. I then activated the sending/receiving of collisions and also the physics responses for sending/receiving should a collision happen in one of these directions. I finally setup what the objects can collide with using the setCollisionMask call.

Anyway, we'll be providing more info on how to drive the physics so you won't have to guess like this. When you understand all the fields, you sort of get a feel for it. Some of those fields are there for special purposes and some are very delicate such as density. You can in-fact use real-world tables for those and we'll be providing some info on that as well.

In the meantime, enjoy. :)

- Melv.

#2 Aye Melv that little intro helped me out as well... 2 quick questions --

1.) Why do 5 or 6 of the balls randomly disappear (always together and against the edge of the screen) after some amount of time?

2.) When I hit F10 to toggle back and forth from editor to game, the balls all "fidget" a bit upon returning to the game -- not that it's particularly important, but is this inherent in the physics timing?

- Tim

#3 @Melv,
Many thanks!

I made so many little tweaks trying to get it "just right" that I ended up with a wet tea bag neutron star :-)

Here's what I ended up with for final datablock params for a kickball. I'm still tweaking the friction, but it's light year's ahead of what I had. Must be the pull from the neutron star :-)

datablock fxCollisionMaterialDatablock2D(rubberBall)
{
friction = 0.3;
restitution = 0.85;
relaxation = 0.5;
density = 0.01;
forceScale = 1;
damping = 0.05;
};


Next goal is to hook a mouse up to it and work on my jump shot :-)

-Terry

#4 Nice Terry. :) And as Melv says, watch for docos in the future that should help you get a better freel for how to set-up all these params.

Tim..

1) I don't know exactly why that'd be happening.. there's no inherit reason why an object would be removed, unless you're using the KILL world limit on some of them. There must be some scheduled or collision callback delete function somewhere? Can you describe in more detail what happens exactly?

2) Yeah, that can occassionally happen. It's an artifact of the physics code, atm. One we'll address!

#5 Ok I've set up the scene with precisely the code listed above -- 'cept I created 30 instead of 20. This is what it looked like after they had come to near-rest:

and some odd minute or so later:

The object count still remains at 30, but they are no longer rendering or colliding (the leftover ones do roll out to fill in the empty space.

Again, this is just the code above put into an empty torque example... I'm not going to make pachinko, so I won't need piles of balls like this, just curious about the stability issue for general reference purposes.

-Tim

#6 Sorry for the hugeness of those images... I forgot this is the web. : (

#7 @Tim: Hmmm, we did lots of stability work. It's funny you should say pachinko because we have got a little pachinko demo we were playing with. :) We had a stacking boxes demo that has been running perfectly without showing this problem. The difference being that it was held within the screen by a brick-wall surround rather than the world-limit. I think this may be a simple problem with the world-limit so I've added this to the list to check.

Thanks for the info Tim.

- Melv.

#8 Melv.... I believe I've seen this in the stacked boxes demo... (I kinda thought it was part of the demo)

I'll see if I can replicate it and get some screenshots.

#9 Wacky... I wonder if some scheduled delte command crept in from one of our dev demos.. hmm. Yeah thanks guys, we'll be taking a look at this.

#10 I have a project similar to this that I had been working on last night. On the odd occasion, I had some balls slip in behind another, as if the collision detection failed. It hasn't happened often, but seems to happen more near world limits and with a larger number of objects. The strange thing was that it happened when the objects were at (or coming to) rest.

Is it possible that the balls in Tim's example that went missing are actually behind other objects? An easy test would be to add another force after the balls go missing to stir them all up again.

#11 Well the number of objects listed in the render bins accurately went down to 18... so unless T2D has some fancy occlusion culling, I'd say that they aren't hiding behind other objects.

#12 Tim,

It'll simply be that the objects have gone off-screen. I have got this bug to confirm and solve after the next two on my list. I always keep a track of the original threads and post the solution as appropriate like the solution to this one.

I'll keep you updated. :)

- Melv.

#13 Sorry Tim,

I didn't notice the count on the render bin. Just ignore me :)

Chris

#14 Hey no worries anyone -- This is so very non-critical at the moment in my opinion. I'd rather see the team working on tools to facilitate the beginning phases of 2D game dev (animation editor, collision poly editor, etc.) and work on fixing things like this later. ;) ... that could just be me. At any rate -- keep up the good work!

-Tim