Physics in Leadwerks3D

[Josh]

When choosing a physics simulator, I had a few requirements:

 

-We did not want to pass on any costs or licensing strings to professional studios that license our source code. We've managed to develop the entire engine either by writing our own technology (like built-in hierarchical occlusion culling), or when appropriate, by using open-source libraries (like Recast pathfinding). We do not want professional studios to have to deal with other vendors' costs or additional restrictions.

 

-I anticipate additional platform support in the future, like Linux and Windows Phone 8. Relying on a closed-source binary would limit where we could take the new engine.

 

-In the past, Leadwerks Engine has received significant interest from flight sim companies who wanted the worlds to go beyond the restrictions of 32-bit floating points. One of the most promising Leadwerks Engine games in development is a helicopter flight sim. Support for massive worlds beyond anything we've seen before is part of my plan for future development.

 

Both Bullet and Newton 3 are free and open-source. PhysX and Havok and closed-source and would incur additional costs and restrictions I have to pass on to source code licensees. They would also limit which new platforms I could support.

 

I talked to the technical director of PhysX on the phone last year, and he told me that PhysX was designed to handle a maximum of about 40,000 physics objects in a scene, total. I've made scenes in Leadwerks Engine with over 4,000,000 vegetation instances.

 

Bullet has soft bodies, and Newton 3's soft bodies are still being developed. However, Newton has support for instanced static geometry, which is how we are able to have millions of trees and plants in a scene.

 

With these factors in consideration, it seems clear that Newton 3 is the best way for us to go. I am doing things a little differently this time:

-The new scaling features in Newton 3 are being built into the system, to handle scaled matrices.

-I'm not relying on the serialized physics shape format, which kept changing with SDK updates.

-The engine is ready to support new features like real destruction and soft bodies that are still in beta development in Newton 3.

-Physics are updated asynchronously, meaning they always run on one or more threads in the background. Even on mobile platforms.

 

Of course with the modular architecture in Leadwerks3D, the physics module can be swapped out with one written around PhysX or any other library.

 

Enabling physics on any entity is very easy:

Model* model = Model::Box();
model->SetScale(2,1,1);//physics will automatically scale with the entity
Shape* shape = Shape::Box();//create a physics shape
model->SetShape(shape);
delete shape;//We're done with this, delete it
model->SetMass(1);
model->SetScale(4,1,4);//we can still scale the entity, no problem

[Rick]

I'm confused in your example. Once we attached a shape to a model we can delete the shape and the model will still have the physics shape to it? My assumption would be once we delete a shape it's gone for good and the model in your example would no longer have the physics shape.

[Canardia]

I don't understand why you even consider PhysX, it lacks of 2 major features:

1) Cross-hardware GPU support

2) 64-bit Linux drivers

Bullet has them both, and with full source code.

[Josh]

I'm confused in your example. Once we attached a shape to a model we can delete the shape and the model will still have the physics shape to it? My assumption would be once we delete a shape it's gone for good and the model in your example would no longer have the physics shape.

When you add the shape to the model, an instance of the shape is created. You delete the original shape when you are done with it. When the model is deleted, it's instance of the shape will be deleted, and the ShapeBase object the two instances share will be deleted.

 

This makes memory management easier because you don't have to worry about accidentally deleting a shape, texture, or other asset and creating invalid pointer errors in objects that use them.

 

Here's an example that might be more intuitive:

Model* model = Model::Box();
Material* material = Material::Load("mymat.mat")
model->SetMaterial(material);
delete material;

The material asset won't be released from memory until the last instance is deleted. This could be done by deleting the model, in this example.

[Rick]

This sounds like it's in the building blocks of the engine but it doesn't seem very intuitive. Maybe it's just me, but this seems very odd design from the user perspective.

[shadmar]

I like physx, cloth, metallic deformation, softbodies and fluid particles.

 

Look what you can do with the cloth alone :

[Canardia]

Bullet has the same, and much more, and on all platforms. PhysX has lost the race, like DirectX has too.

[Road Kill Kenny]

Well this is relatively good new. Thanks for explaining this Josh.

[Josh]

You can also do stuff like this:

Model* model = Model::Box();
model->BuildShape(SHAPE_BOX);

Model* cone = Model::Cone();
cone->BuildShape(SHAPE_POLYMESH);

[Scott Richmond]

This sounds like it's in the building blocks of the engine but it doesn't seem very intuitive. Maybe it's just me, but this seems very odd design from the user perspective.

 

Agreed Rick. I suppose it gives more control over what's going on though. Looks like BuildShape() attempts to make a more clean interface for it though.

[Josh]

You can create shapes with arbitrary dimensions, or you can generate one from the AABB or polygonal geometry. It's really easy to set up scenes in code. You've just got to try it.

[Road Kill Kenny]

Seems fine to me

[Game Producer]

I'm with Rick here, I too feel somewhat odd about that function naming style.

 

if model->setMaterial(material) was model->addMaterial(material), it would make a slightly more sense. (keyword picked from Josh's explanation "When you add the shape to the model, an instance of the shape is created.")

 

...with that being said, I can live with this naming convention though 8)

 

...but to get somewhat back on track regarding Josh's choices: sounds perfectly fine. There's always N number of pros and M number of cons whatever you choose. All of them get the job done, pick one & stick with it.

 

Josh's plan sounds good.

[shadmar]

Bullet has the same, and much more, and on all platforms. PhysX has lost the race, like DirectX has too.

 

I don't understand, I thought PhysX and Havok were the most used physics engines used in games today.

[Roland]

My personal view is that I really don't care as long as it works.

Having none or very little experience in this area, I lean on trusting Josh.

Guess its like everything else, different implementations have their pros and cons.

[Pixel Perfect]

Of course with the modular architecture in Leadwerks3D, the physics module can be swapped out with one written around PhysX or any other library.

I think this says it all really. Any commercially released game engine or engine SDK is always going to go with just one physics engine, for what ever reasons, and will never satisfy everyone.

 

So long as provision is made in the design for easily bolting on other physics engines then this represents the best of both worlds.

[Canardia]

I don't understand, I thought PhysX and Havok were the most used physics engines used in games today.

That's why there are no good physics games made yet

[Josh]

I don't understand, I thought PhysX and Havok were the most used physics engines used in games today.

I'm pretty sure PhysX is used more than any other general-purpose library. For source code licenses, our target market is medium-sized studios. I don't want to pass extra licensing costs onto them or have any additional restrictions on what they can do with the source.

 

Unity has gone the route of licensing a lot of third-party middleware to try to turn a mediocre engine into something professional studios will license. That approach has failed. There is a total of one XBox 360 game that uses Unity, to date. When a studio licenses source code from us, we should be the only company they need to deal with, because we either build our own technology or use open-source libraries.

[Roland]

I'm pretty sure PhysX is used more than any other general-purpose library. For source code licenses, our target market is medium-sized studios. I don't want to pass extra licensing costs onto them or have any additional restrictions on what they can do with the source.

 

Unity has gone the route of licensing a lot of third-party middleware to try to turn a mediocre engine into something professional studios will license. That approach has failed. There is a total of one XBox 360 game that uses Unity, to date. When a studio licenses source code from us, we should be the only company they need to deal with, because we either build our own technology or use open-source libraries.

That's a really good thing Josh.

[Pixel Perfect]

Unity has gone the route of licensing a lot of third-party middleware to try to turn a mediocre engine into something professional studios will license. That approach has failed. There is a total of one XBox 360 game that uses Unity, to date.

EA signed an exclusive licence deal with Unity in 2010 to allow all their studios access to Unity's technology ... and that's a failure?

[Josh]

EA signed an exclusive licence deal with Unity in 2010 to allow all their studios access to Unity's technology ... and that's a failure?

They're using it for web and mobile stuff. The fact remains, three years are gone by, and only one XBox game. C4 Engine has better penetration into the console market.

[Pixel Perfect]

Well yes, but since when does the yardstick of success become simply XBox sales, they have one of the biggest market penetrations of any game engine in the mobile marketplace which recently you and others have been putting forward as the brave new frontier for indie game developers. I'm not sure what point you are tying to make here? Are you suggesting LE3D will now be competing in the console marketplaces, I didn't think there was any immediate plans to support that?

[Josh]

Well yes, but since when does the yardstick of success become simply XBox sales, they have one of the biggest market penetrations of any game engine in the mobile marketplace which recently you and others have been putting forward as the brave new frontier for indie game developers. I'm not sure what point you are tying to make here? Are you suggesting LE3D will now be competing in the console marketplaces, I didn't think there was any immediate plans to support that?

I'm saying that even with $17 million in free money they failed to convince AAA studios to use their engine. Their penetration in mobile is also a lot lower than their guerilla marketers want you to think. When we conducted our research we found a much lower percentage of Unity games on iOS than we expected.

[Pixel Perfect]

When we conducted our research we found a much lower percentage of Unity games on iOS than we expected.

Well that contrasts greatly with this recent statement from Unity themselves in Gamasutra:

 

"There are over 1000 Unity-based iOS games in the App Store for iPhone and iPad while I don't think any other game tool set -- including Flash -- has more than perhaps 100 or so games. That's because, with those small devices, you really want to be close to the metal and not have a lot of overhead. And Flash has a lot of overhead. There's no telling what share Molehill will get, but we feel we have a pretty big leg up for a while at least."

 

Now I'm not wanting to get into arguments one way or the other but to suggest that Unity is not a major player seems fanciful.

 

As to the AAA studio argument, most of these have always developed and continue to develop their own engines. As far as I am aware, Unreal is about the only engine that can realistically say they have made inroads into this marketplace in any numbers.

[Canardia]

Unity is made with C# so it's a failure by definition. No serious programmers use anything else than Fortran, C or C++. Especially not ANY language with garbage collection. I mean have you seen Intel C#? No, but there is Intel Fortran, C and C++. These guys just know what kicks the power out of CPUs. Fortunately they work also on Linux and all CPUs via GNU compilers, which C# never will do.