Jump to content
  • Advertisement
hyyou

C++ "parent.add(child);" : best sematic for Compound Physics body

This topic is 386 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am trying to encapsulate a Physics Engine (to support fracturing).

I want to know whether my below semantic is bad smell.

[Approach 1] My current design is :-

  • Programmer can create 2 types of Physics body  : Parent, and Child
  • Parent is a body that can't have any shape or mass, but can contain some Parents or Children.
  • Child is a body that can't contain any other physic body, it always has shape and mass.

For the implementation :-

image.png.00ac54151646247dd3c9754e97f02128.png

  • Both Parent and Child are inherite d from a class PhysicBody.
  • PhysicBody has some fields.  One of them is mass, as an example.
  • Mass of a Parent is the total mass of every children.
  • Mass of a Child is the mass of itself.

Suppose that I want to simulate a jar that can explode into several pieces. I will :-

  • Create a Parent named x
  • Create many Child that denote fractures e.g. y1 y2 y3.
  • x.add(y1);   x.add(y2);   x.add(y3);
  • The steps are very similar to BulletPhysics's.

So far, it works well in all demos.    Coding is easy and fun.  

Today, I want to implement a tank like this :-

image.png.80748d14049ce4b3a61cf4d61fa650cc.png (a crappy tank shown in top-view)

Here is how it can be created :-

  • x is a Child : x = createCube();
  • y is a Child : y = createSphere(); 
  • z is a Child : z = createCylinder();
  • p is a Parent : p.add(x);   p.add(y);   p.add(z);

It works, but I think it is counter-intuitive :-

  • The tank is p which is an relatively (too) abstract physic body.

[Approach 2] Thus, I plan to make it like :-

  • x = createCube()
  • y = createSphere();  x.add(y);
  • z = createCylinder(); z.add(y);

The new sematic demand me to re-design Physics class, e.g. to be :-

image.png.3949b206e4fabd8422693cc0e002a906.png

Old parent and child will become the same type - all of them can now has shape, mass and contain children!

image.png.dc784bc081a2eaa68405395e22dfc315.png

I think it would work well, but I am still too scared.

Question

  • Is it make sense to allow non-empty physic body to contain some other physic bodies?
  • Are Approach 1 and Approach 2 bad designs? 
  • Can Approach 2 be considered an improvement?
  • Did you spot something (potentially) wrong?  How to improve it?
  • Am I a problem myself?

 

Edited by hyyou

Share this post


Link to post
Share on other sites
Advertisement

There are several ways to implement destruction. Among the simplest approaches is to have two models. On for the broken and another for unbroken state. Then in the game you simply swap the models due to some event (e.g collision). The model usually holds the rendering and physical data. This means there is no hierarchy needed but simply two arrays of the involved rigid bodies and joints. 

In your tank example things are even easier. You would just have one model and simply disable/break joints if you want to break a piece off. This works usually nice for simple things like swinging signs., but it becomes problematic if too many joints are used.

Finally, there is indeed hierarchical destruction. You might want this for rigid pieces like glass or or vases and procedural breaking based on the hit point. In that case you would need to create a shape hierarchy and add/remove bodies during collision events. Alternatively you can also procedural cut the shapes at run-time.

To get some physical fidelity into you game I would start with a simple model swap. Think how an artist would create these assets and how you would read/write that data into your game. These kind of assets will not be created by a programmer in code in any reasonable project.

 

HTH,

-Dirk 

Edited by Dirk Gregorius

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!