Physics Library

[Paul Thomas]

I think lumooja secretly wants physx and he is trying to use reverse psychology.

lol

 

Havok is great, Bullet is great, PhysX is great. Just have to decide what's best for LE unless you take the time to allow customers to use either one of the libraries of their choice. Never a bad idea just would take a lot more work. Worth it? Don't know. I can't name off too many engines, if at all, that support all three dominating physics libraries and it would be for a reason.

 

Good luck in the decision and implementation, Josh.

[knocks]

Brent I don’t know how correct I am, only going from my experience and im no programmer at all. Out of the box neither physics are setup and you need to add either one to your project. I have only ever built the engine using physX but I believe the method is the same for Bullet.

Open up <Your Project>\buildFiles\config\project.conf and add

includeModule( 'bullet' );

or

includeModule( 'physx' );

then run generateProjects.bat, this adds the proper files and include directories etc

Set the environment variables etc for your chosen sdk and rebuild.

 

As for the problems its something to do with threading Tom from sickhead games made several post about it, this was about a year ago so not sure what the situation now is.

 

I agree with paul, i don't care what is used, i just went with physX as i have experience with it as an artiest.

[Josh]

If it were feasible I would rather have our own custom physics solution. All these libraries are awful one way or another.

[Brent Taylor]

Brent I don’t know how correct I am, only going from my experience and im no programmer at all. Out of the box neither physics are setup and you need to add either one to your project. I have only ever built the engine using physX but I believe the method is the same for Bullet.

Open up <Your Project>\buildFiles\config\project.conf and add

includeModule( 'bullet' );

or

includeModule( 'physx' );

then run generateProjects.bat, this adds the proper files and include directories etc

Set the environment variables etc for your chosen sdk and rebuild.

 

As for the problems its something to do with threading Tom from sickhead games made several post about it, this was about a year ago so not sure what the situation now is.

 

I agree with paul, i don't care what is used, i just went with physX as i have experience with it as an artiest.

 

Looks like you're mostly correct. I haven't attempted to compile with Bullet yet. I still can't find any post from Tom about bullet, but I'm sure thats partly due to the changeover on the garage games website. If no physics module is specified, it defaults to PhysX apparently (which is what has been happening in my projects). Glad to know Bullet has already been integrated. That reduces the amount of work I need to get this working on iOS.

[knocks]

I think by default its only basic custom physics that are used, if you hit the tilde key it will show no physics module is loaded. There is a physics menu when the module is loaded.

[Josh]

Both will have unforeseen technical challenges. Both will have little caveats and problems I cannot possibly predict. However, I know for sure if I go with PhysX it will have a certain amount of brand recognition that Bullet does not have, which means more sales. In a situation where it is impossible to predict all the consequences of either, that's as good a reason as any to go with one. I am going to work with PhysX 3.0 until a problem is encountered that makes it impossible to proceed.

[Canardia]

Why not implement both at the same time?

I was really hoping to make games for Android with LE3, but with PhysX it's not possible.

Or can a source developer make his own Bullet driver for LE3?

[Josh]

Why not implement both at the same time?

I was really hoping to make games for Android with LE3, but with PhysX it's not possible.

Or can a source developer make his own Bullet driver for LE3?

I have access to PhysX for Android. It is possible to make a Bullet physics driver without access to the source. Mind you, this is code I have not yet written.

[Canardia]

Wierd, they said Havok will come for Android, but not PhysX, as it would need a Tegra GPU which only Samsung Galaxy S2 has:

http://www.gamephys.com/2011/03/17/havok-physics-coming-to-the-android-platform-for-gaming/

[Marleys Ghost]

Wierd, they said Havok will come for Android, but not PhysX, as it would need a Tegra GPU which only Samsung Galaxy S2 has:

http://www.gamephys.com/2011/03/17/havok-physics-coming-to-the-android-platform-for-gaming/

 

They say? you mean a post on someones blog, which actaully says "it is also great to see Havok Physics itself coming to the Android platform and not PhysX from NVIDIA which they would probably require a Tegra processor to run it."

 

SO a non official source and you change the context.

 

 

But..

 

Mike Skolones: PhysX has been and continues to play an important role for NVIDIA, as well as for the thousands of game developers who use PhysX for physics simulation across a broad range of platforms, including PC, Xbox360, PLAYSTATION 3, Nintendo Wii , iOS (including iPhone, iPod, and iPad), OSX, Linux, and Android (including NVIDIA Tegra™ devices)

 

http://physxinfo.com/news/5591/nvidia-physx-continues-to-play-an-important-role-for-us/

[Josh]

I don't expect much from mobile physics at all. I just expect the basics to run.

[Canardia]

Angry Birds depends a lot on mobile physics, and it's a huge success.

[Naughty Alien]

Bullet all way..free, open source and present on all consoles / PC, and very lightweight..

[ZioRed]

I have no experience at all about physics engines but, since I hardly rely on an open source software for my commercial products, I voted PhysX both because it's developed and mantained by a well-known company like NVIDIA and because it's used in many games and engines.... if the most known engines trust it then I think there is a really good reason to trust it too.

 

PS: yes I don't like open source at all for professional use and it has absolutely no clue that it's free, I want to pay and have support if I have to sell my product, I cannot rely on a 1000000000000 different developers but on a single company. Of course for private home use, open source is a good thing, but ONLY for that use and not for professional.

 

PS2: @Mika your "statistics" about linux users who want to pay is very funny and ridiculous as 99% of your stats about linux and open source in general, I'm ever glad to read fakes from utopian penguins

[Ending Credits]

I'm really suprised about the lack of support for newton.

[Laurens]

Voted for Bullet because of the same reasons Brent and Lumooja have already pointed out on the condition that the engine will still support the large scenes we can currently have, vegetation-wise.

 

EDIT: Voted before reading the other 3 pages of this thread. I am only OK with PhysX as long as it does not lead to any additional licensing fees, which is not completely clear to me right now. Under what terms is PhysX used in Leadwerks?

[Josh]

PhysX would not involve any licensing fees for PC, Mac, or mobile.

 

The lack of licensing fees for Bullet on the console is the best argument for it.

 

I have a feeling people trump bullet up just because it's open source, and they want it to be the best. When you see a lot of argument made with no evidence, that's a good indication. When people say, "X isn't supported, but you can add it yourself!" I cringe because they are basically saying there is no physics library and you have to write one yourself. That's what it would take to actually implement. I do not like open-source software for that reason.

 

There's good cause for a proprietary Leadwerks physics system, but unfortunately that is beyond my ability to provide, on top of everything else.

 

If Newton had soft bodies, I would stick with it. In three years, the library still has basically the same functionality it had when I started. The developer is focusing on some pre-made destruction features like PhysX has that complicate the art pipeline, and provide a very dubious benefit. I'm not very interested in any feature that makes the art pipeline more complicated, because I know it won't get used. Even an imperfect implementation of soft bodies would be great, but he just doesn't care about it. Not to mention he's incredibly rude, even though I've given him his best promotional videos.

[Rick]

When people say, "X isn't supported, but you can add it yourself!" I cringe

 

There is irony in that statement somewhere

[Laurens]

Great!

 

Fees aside, would a product created using Leadwerks require you to include any PhysX banners/credit/mention of some sort?

[Josh]

There is irony in that statement somewhere

It's never realistic to add low-level functionality into a system you didn't write. Sometimes people here try it, and I've learned to just stay out of it and let them learn.

 

Great!

 

Fees aside, would a product created using Leadwerks require you to include any PhysX banners/credit/mention of some sort?

I don't believe so, but I would think most people would want to promote this. Isn't having a nice logo the point of PhysX?

[Canardia]

The manual creating of fractures in PhysX is just as if there was no fracturing at all. Modellers can make the pre-broken parts much easier in their favorite modelling program. Bullet does all that automatically.

 

Non-Open Source software which lacks features is much worse than open source software which lacks features, and there are thousands of developers who could add it. You can even pay someone who has skills to do it for you, but you can't do that with non-open source software.

 

Bullet was used in the movie 2012, and with such movies there are much bigger amounts of money in the game than with some computer games. They could for sure have used PhysX if it was faster and better, or had automatic fracturing, but it didn't have. Bullet has. There is not even a PhysX plug-in for Blender, but for Bullet there is. PhysX is basically used by people who get paid to use it, but nobody would use it if they had the choice.

[Josh]

The manual creating of fractures in PhysX is just as if there was no fracturing at all. Modellers can make the pre-broken parts much easier in their favorite modelling program. Bullet does all that automatically.

They create the broken pieces for you, which is sort of impressive on an arbitrary mesh, but it's still not a dynamic breakage. Real breakage is probably impossible in real-time with today's hardware.

 

They could for sure have used PhysX if it was faster and better, or had automatic fracturing, but it didn't have. Bullet has.

Show me this amazing fracturing. There is a demo in the SDK folder, but the project file is missing, and I'm not going to mess around trying to compile it. I believe they may have some rudimentary tests working, but I don't believe it is a supported working feature. In any case, I am not that interested in these fake destruction techniques, with any library, because people aren't going to want to deal with the added trouble of making the assets.

 

From my perspective, implementing Bullet is just as challenging as implementing PhysX, and the two will each have their own problems and complications I can't predict. However, I know with PhysX any problems it has will get overlooked, and with Bullet I will get blamed for anything that doesn't work well. I got criticized so much for using Newton, even when I proved the rigid body simulator was much more stable than Havok or PhysX.

 

PhysX has a nice logo, therefore the equations it uses are correct. In the absence of any other compelling technical advantage, that's a good decision criteria. It would take six months working with each library before I could choose the right one based on technical qualities.

[Canardia]

I tried yesterday the Newton demo, and it had nicely breaking pieces too.

[Josh]

They have some real dynamic breakage using booleans, much like how 3D World Studio works. I'm sure I could implement this with our CSG routines, with any physics library. I much prefer a real dynamic solution over pre-made fracturing. Even if the results look worse, the fact it is truly dynamic makes it much better, IMO. This works out well with our CSG editing, because you could set each brush to be "breakable" and have real breakable features. Of course, this would not handle shearing forces, so you would not have objects collapsing from the stress of removing a support, unfortunately. The best you could hope for would be that the whole structure falls over in one solid piece, with further breaks occurring at impact points.

 

Realistically, it would probably just amount to shooting concrete off of an indestructable rebar frame, like what all the PhysX destruction does.

[Game Producer]

PhysX would not involve any licensing fees for PC, Mac, or mobile.

 

The lack of licensing fees for Bullet on the console is the best argument for it.

 

I have a feeling people trump bullet up just because it's open source, and they want it to be the best. When you see a lot of argument made with no evidence, that's a good indication. When people say, "X isn't supported, but you can add it yourself!" I cringe because they are basically saying there is no physics library and you have to write one yourself. That's what it would take to actually implement. I do not like open-source software for that reason.

 

There's good cause for a proprietary Leadwerks physics system, but unfortunately that is beyond my ability to provide, on top of everything else.

 

If Newton had soft bodies, I would stick with it. In three years, the library still has basically the same functionality it had when I started. The developer is focusing on some pre-made destruction features like PhysX has that complicate the art pipeline, and provide a very dubious benefit. I'm not very interested in any feature that makes the art pipeline more complicated, because I know it won't get used. Even an imperfect implementation of soft bodies would be great, but he just doesn't care about it. Not to mention he's incredibly rude, even though I've given him his best promotional videos.

 

Sounds good to me.