Newton vs Bullet demo

[Canardia]

It's quite easy to integrate Bullet into LE, and it works without modifying the source too.

I will publish Bullet.lib soon, of which the basic version is free, but maybe a commercial version will have more features. Depends how many people are interested in it.

 

Bullet has also concave bodies, which I missed in Newton always. The vehicles work also fine, as well the character controller. It has also cloth simulation.

 

#include "engine.h"
#include "Bullet.h"

int main()
{
if(!Initialize())return 1;

Bullet bt;
vector<TModel> newtonmodel;

bt.CreateGround();

SetAppTitle("LE 2.4: Newton vs Bullet");
Graphics(800,600);
CreateFramework();

TMesh groundmesh=CreateCube();
MoveEntity(groundmesh,Vec3(0,-3.5,0));
ScaleMesh(groundmesh,Vec3(1000,1,1000));
EntityColor(groundmesh,Vec4(0.5,1,0.5,1));
PaintEntity(groundmesh,LoadMaterial("abstract::terrain_forest_grass.mat"));

TBody newtonground=CreateBodyBox(1000,1,1000);
MoveEntity(newtonground,Vec3(0,-3.5,0));
EntityType(newtonground,1);
Collisions(1,1,1);

TCamera cam=GetLayerCamera(GetFrameworkLayer(0));
MoveEntity(cam,Vec3(1,0,-20));

// create environment
TLight sun = CreateDirectionalLight();
TurnEntity(sun,Vec3(25,82,75));

AmbientLight(Vec3(0.025,0.025,0.050));

SetFarDOF(1);
SetFarDOFRange(20,80);
SetShadowmapSize(sun,3072);
SetShadowSoftness(sun,0.1);
SetSSAO(1);
AFilter(MaxAFilter());
TFilter(1);
SetBloom(1);

int newtonboxes=0;
int bulletboxes=0;

// run main loop
while(!KeyHit())
{
	if(KeyHit(KEY_1))
	{
		// create newton boxes
		TBody newtonbody=CreateBodyBox();
		TMesh newtonmesh=LoadMesh("abstract::bamboocrate.gmf",newtonbody);
		for(int y=0;y<20;y++)
			for(int z=0;z<5;z++)
				for(int x=0;x<5;x++)
				{
					TModel model=CopyEntity(newtonbody);
					PositionEntity(model,Vec3(x,-2.5+y,z));
					SetBodyMass(model,1);
					EntityType(model,1);
					newtonboxes++;
					newtonmodel.push_back(model);
				}
		FreeEntity(newtonbody);
	}
	if(KeyHit(KEY_2))
	{
		// create bullet boxes
		TMesh bulletmesh=LoadMesh("abstract::bamboocrate.gmf");
		for(int y=0;y<20;y++)
			for(int z=0;z<5;z++)
				for(int x=0;x<5;x++)
				{
					bt.AddBox(x,-2.5+y,z,CopyEntity(bulletmesh));
					bulletboxes++;
				}
		FreeEntity(bulletmesh);
	}
	if(KeyHit(KEY_SPACE))
	{
		bt.Erase();
		bulletboxes=0;
		vector<TModel>::iterator newtonmodel_iter;
		for(newtonmodel_iter=newtonmodel.begin();newtonmodel_iter!=newtonmodel.end();newtonmodel_iter++)
		{
			FreeEntity((*newtonmodel_iter));
		}
		newtonmodel.clear();
		newtonboxes=0;
	}
	bt.Update();
	UpdateFramework();
	RenderFramework();
	DrawText(1,20,"1: newton   2: bullet   space: clear");
	DrawText(1,35,"newtonboxes=%d",newtonboxes);
	DrawText(1,50,"bulletboxes=%d",bulletboxes);
	Flip(0);
}

return Terminate();
}

 

 

[Wchris]

I will publish Bullet.lib soon, of which the basic version is free, but maybe a commercial version will have more features.

i thought bullet was opensource and free like newton ? there is a commercial version ?

 

Hey ! i get 4 FPS with newton and 85 FPS with bullet i can't believe it, is this true ???

 

If this resuilt is true... then.. why do we wait for 4 apples to fall down from the tree on newton's head, when we can have a wheelbarrow filled with 85 apples with bullet ? Or maybe newton should be named bullet, because this thing is shoooting itself in the foot ? LOL

 

The only advantage of newton is that more bodies come to rest, and also they come to rest faster.

Bullet is not as good with this, but maybe it is due to a cache system that keeps alive the objects who have a hight probability of being collided ? But LE engine could perhaps force the objects far away from the camera and outside camera vision to stop updating physics and help bullet .

[AggrorJorn]

wow those results don't lie at all now do they! How is it possible that one physics engine can be so much better? Newton can't be that bad now can it?

 

@2wchris: I think lumooja means a paid bullet.lib library with extra functions that he is going to make. Bullet itself is free.

[Canardia]

Newton might be the only deterministic physics engine though, which is very important when making networked physics.

I'm trying to get Bullet also deterministic by removing all rnd() calls.

 

The coming to rest time can be configured in Bullet, and it has also less friction by default so things slide longer.

 

Bullet.lib is the LE integration of Bullet. While Bullet itself is free, there is a lot of LE related code in Bullet.lib which is not part of Bullet.

As it's using ZLib, I can modify also the bullet source code without needing to publish it. But I would probably publish my Bullet changes, to make Bullet a better product, while the source code of Bullet.lib for LE is strictly my business secret

[Pancakes]

the hips don't lie and neither do these results - speed also doesn't lie

 

where are the softbodies

[Marcus]

WOW! I get around 1 fps with Newton and around 90 with Bullet. The difference is night and day. I really hope Josh gives several different options for LE3.

[Josh]

It's a case of accuracy versus performance. The Bullet boxes slide forward at the base and the entire stack collapses. The Newton stack collapses from the top, and a stable base is left over. Most physics libraries can't handle stable stacking of very many objects.

 

If your game is "dodge 500 falling boxes" then I can see how the first would be better, but I tend to favor stable interactions of simple things like doors and jointed machines.

 

We'll probably switch to PhysX or Bullet, but you will see errors in simple behavior, and you will have to deal with stability issues you take for granted right now.

 

[Canardia]

I think the reason why the Bullet box stack blows up from the bottom is that it starts with a compression wave from the above boxes.

I've noticed that Bullet bodies sometimes penetrate other bodies, and then jump back where they are allowed to be.

This might be some setting in Bullet too.

 

But the biggest problem with Bullet and PhysX is still the determinism, however it has been fixed in Bullet in several places, while in PhysX there is no intention to be deterministic at all.

 

Like I said earlier, Bullet will be a great physics engine if they keep fixing it, but at the moment Newton is the only usable physics engine for networked physics.

[Mumbles]

Newton multithreading enabled?

 

Also, with 2000 boxes, newton dips to about 1 fps for 10 seconds, which yes, would be unplayable in a game, but once most of the boxes separate the frame rate increases to about 20. Once they're all sleeping due to not moving. the frame rate is as high as 95.

 

Bullet on the other hand, only goes down to about 10 fps for 2-3 seconds. Much better better for a gamer. Once most of the boxes have separated the frame rate increases to 25. But even when the boxes have fully stopped, the frame rate is still at 25.

 

And really, how likely are we to have 2000 active physics bodies all colliding with each other in such a small area? That's one of the biggest speed killers for newton

 

I'm also guessing that the newton built into LE uses just one thread? I wonder how much faster it would be if more than one thread was enabled. Tomorrow, I might have a go at rewriting your code to work with a standalone newton to test that idea (If its OK that is).

[Canardia]

Sure it is OK, I would be also interested how fast Newton would be with a pure C++ interface. Also remember to disable RTTI in VS, since it's always enabled by default since VS2008. It's only needed for a couple of special virtual class functions, which are basically used for debugging only.

 

But even when the boxes have fully stopped, the frame rate is still at 25.

Actually I don't think they have fully stopped then yet, because it can take a long time before Bullet fully stops.

That's partially because I didn't adjust the friction of the boxes, so they keep sliding very slowly if they are a bit slant on top of other boxes.

When all boxes have stopped, the FPS goes back to what Newton has too when all are stopped.

[Pancakes]

I think most people care about cloth and water and stuff like that for physics. and as far as the 500 falling boxes is concerned, you can replace the boxes with feathers, softbody goo drops, or chocolately nuttyslack bars. Imagine it raining nuttyslacks!

 

Doors are cool and all, and believe me on other forums such as Blade3d and blender I've seen my share of forum posts of people complaining about how their car doors won't rotate properly due to interactive forces. Oh well, I guess it's a got pros and cons for all of them.

[AggrorJorn]

I think it depends a little on what you want to achieve with your game. Maybe Bullet is less accurate but when there is so much physics activity on screen, people (or gamers in general) will not notice or simply just don't care that objects are intersecting.

 

Take for instance the game Red faction Geurilla. Entire buildings are collapsing while most of the debris just goes straight through each other. Bullet would be ideal for that. If you would have a game like Amnesia, Newton is probably better because the physics need to be accurate and there are only few physical entities active at the same time.

 

The thing that bothers me the most with newton is that you can not rescale the physics file realtime in the editor. Besides that I can not complain about newton.

[Wchris]

Take for instance the game Red faction Geurilla. Entire buildings are collapsing while most of the debris just goes straight through each other. Bullet would be ideal for that. If you would have a game like Amnesia, Newton is probably better because the physics need to be accurate and there are only few physical entities active at the same time.

yes i think it depends on the game your are writting, in some case bullet is better, in other cases newton is better, so it would be usefull if we could choose between the two with LE3 even if only newton is officially supported.

 

A C++ abstraction layer for physics engine already exists here on Sourceforge http://www.adrianboeing.com/pal/index.html#intro

but i don't know if Josh knows about it.

[Josh]

Newton can probably get about 3 times speed improvement on a quad core. BlitzMax won't work with Newton multithreading, due to the use of callbacks.

 

I've done networked physics wth good results, all calculated on the server. It is not necessary for the clients to all process physics separately, for shared physics objects.

 

The problems I see with Newton are the lack of scaled matrices, soft bodies, and cloth.

 

I've seen that PAL lib, but you'll notice there's no support for vehicles or anything advanced. I don't think it's possible to design a general physics API without ignoring advanced features of each system.

 

My preference is probably PhysX, simply because NVidia has put a lot of marketing effort into the name, and that makes the algorithms the best by default.

[Canardia]

Networked physics means that each client runs the physic simulation exactly the same way, and the server only sends short symbols or force vectors to the clients. If the server does all physics, then you can do it with any physics engine, as you have to submit the whole entitymatrix of each entity to the clients.

[Josh]

What about packets that may be lost or not arrive in order?

[Canardia]

Packets need to be numbered sequentially, and if the client doesn't get the next packet, he needs to ask again for it.

The UDP engine using SDL_net handles lost packets and makes sure the packets are in right order, so that happens automatically.

[VeTaL]

http://www.adrianboeing.com/pal/index.html#intro

Wow, very interesting project.

[Mumbles]

Packets need to be numbered sequentially, and if the client doesn't get the next packet, he needs to ask again for it.

The UDP engine using SDL_net handles lost packets and makes sure the packets are in right order, so that happens automatically.

 

I still don't understand the whole fad with reliable, ordered UDP. If you're prepared to sacrifice speed for packet sequencing and guaranteed delivery, then why not just go the whole hog and go for TCP? I mean, TCP also tells you when the remote peer sods off.

 

Also, does this UDP solution tell you if one of the bytes in the message has been stuffed up? For example, the sends a message mean\sing "apply a force to the third entity. the force is {0,0,10}" and the packets goes through an old copper wire and gets affected by some interference, so the client reads it as "apply a force to the third entity. the force is {0,0,14}"

 

All these UDP libraries seem to mention reliability and ordering, but they don't seem to make such a big fuss about error detection.

[Canardia]

There's still way too much overhead in the TCP protocol, that a few additional checks with UDP are still much faster.

You can also include a checksum in each UDP packet, but I think it might be already done automatically also.

[Anton Boroda]

Any success with BulletSharp + Leadwerks?

[Canardia]

There is hardly any support for C# and .NET if you compare it with C++ and the millions of standard libraries for C++ you can get for all platforms from the internet for free. No language will ever beat that.

[Anton Boroda]

There is hardly any support for C# and .NET if you compare it with C++ and the millions of standard libraries for C++ you can get for all platforms from the internet for free. No language will ever beat that.

But still i'm very used to C# and don't want to even look at C/C++. There is a bullet for C# (bulletsharp), and it imports to leadwerks project fine but i think there is need of source code access to make it work (or maybe i'm just wrong, i'll look a bit more at it later this week).

[Scott Richmond]

It's a case of accuracy versus performance. The Bullet boxes slide forward at the base and the entire stack collapses. The Newton stack collapses from the top, and a stable base is left over. Most physics libraries can't handle stable stacking of very many objects.

 

If your game is "dodge 500 falling boxes" then I can see how the first would be better, but I tend to favor stable interactions of simple things like doors and jointed machines.

 

We'll probably switch to PhysX or Bullet, but you will see errors in simple behavior, and you will have to deal with stability issues you take for granted right now.

 

Not interested in Havok?

[Canardia]

You have to pay over $50000 for each game your make with Havok, if your game costs more than $10.

 

The page doesn't say it directly, but since you can download only Windows version of Havok, and only the commercial license gives you the Linux and Mac versions, you need to buy the commercial version of Havok anyway:

 

http://www.havok.com/index.php?page=pro

 

The same applies for PhysX also: if you make a game which runs also on Linux and Mac, you have to pay over $50000 for each game.