Combine 2 Physics objects

Many options:

1. Model the stick - player relation by external force and torque (means doing it in game code not physics engine)

2. Try to model it with a single joint (which would require a motorized joint that drives both angular and linear properties)

3. Use multiple joints and model anatomy of both arms or just one arm (requires only angular motors, easier to set up limits)

Most physics engines only have limited or no support for motorized joints. They often give some basic choices for limits, e.g. ball and socket, hinge, 6-dof etc, with or without motor options, and you model your setup given what's possible.

Newton is an interesting exception as it allows the user to implement any joint quite easily, so you could look there for inspiration.

But that's all very complicated. Depending on realism you aim for it should be much easier to use any kind of tricks instead of simulation. At the end you would change the velocity of a hit puck anyways, because something like that is hard to control with simulation running at just 60 Hz.

@JoeJ,

I have to do it in the physics engine

I need the player to rotate & bounce if the stick hits the walls or the stick pushes the puck through the walls

You'd to tell more about the game so we have a bit if imagination.

Is it top down view with arcade like gameplay, or angled view?

Characters 2D sprites or animated 3D models?

2D physics or 3D physics?

Does your physics engine already have some sort of constraints, e.g. contacts to calculate resting contact forces for box stacks?

A sports game modeled by full physics has not been made yet - the hardest hing i can imagine. Even this: https://www.youtube.com/watch?v=CpLNyrt53kU is not just physics (judging with my eyes), and i don't know if they ever finished it.

So what kind of realism between that and an old top down NES game do you aim for?

I have some experience with things like simulating walking ragdoll, but i know nothing about how sports games work and i've never played one

So i hope other will answer too, but they likely need to know more about your goal as well.

@JoeJ

Its a 3d game, angled view, polyhedra as bounding volumes, impulse collision response, collision manifolds, 3d physics but I lock rotations about the Y axis, the movement is realistic but the graphics is not

Ok, sounds you're on a practical (and doable) road

So the easiest way to get going would be just to attach something like a box to the player, which you control in some simple procedural way in the players reference frame.

Because both stick and puck have tiny mass in comparison to the player, you probably don't need a joint to model the forces. For stick-wall collisions you could just add a small impulse to the player and resolve the stick collision with some simple geometrical projection.

If you want to implement joints in your physics engine for general use, you need to look at how constraint solvers work (usually by multiple iterations resolving each joint in isolation and accumulating, or rarely by resolving all joints of a system at once with some graph traversal).

For the latter you do not only need to work on the constraint solver, you also need to work on the control problem afterwards to steer the motors. That's also quite some task and harder than procedural animation. The former approach should be easier.

5 hours ago, Cacks said:

What technique should I use to combine these 2 objects in my physics engine?

You will want to take a look at compound collisions. This image is from the Unity manual:

By using two or more collision boxes you can create a rough collision shape for any odd object. It's fast and practical.

One thing to remember is that compound collisions work best with gravity on. Because each collision box will calculate on it's own local matrix and without gravity to balance it in a model, the 3D object will rotate in the wrong direction.

46 minutes ago, Scouting Ninja said:

One thing to remember is that compound collisions work best with gravity on. Because each collision box will calculate on it's own local matrix and without gravity to balance it in a model, the 3D object will rotate in the wrong direction.

What do do you mean this? I'm confused. Sounds like a bug in Unity?

For me a compound is just a single rigid body that recalculates mass and inertia from multiple input bodies. The purpose is to combine multiple convex shapes to support concave shapes for collisions. So yes, that's the preferable option if the transform from player is static, but no option if the stick should move independently. (should not have anything to do with gravity or rotations)

Edit: I assume what you see could eventually be the result of a badly aligned inertia frame. Usually physics engines support only to express the inertia of an ellipsoid (not even a simple box can be expressed accurately). If the frame is chosen badly, the ellipsoid will not fit the game object and it seems as if it would behave strange. Eventually Unity uses the parent frame (or worse any child) and does not try to find the best orientation.

3 hours ago, JoeJ said:

For me a compound is just a single rigid body that recalculates mass and inertia from multiple input bodies.

Yes, that is exactly how Unity and most engines uses it. As an example a compound collision works like this:

Of Course it doesn't really matter what direction the axis look like the important part of compound collisions is that each collision box is treated as a object "stuck" to an object.

3 hours ago, JoeJ said:

What do do you mean this? I'm confused. Sounds like a bug in Unity?

The confusion comes from developers assuming that a compound collision will act as one solid body. However this isn't true, so they mistakenly think that if the ball hits the new shape it will act as one solid body:

It looks simple now because clearly the compound collision is correct, however this is a simple straightforward collision.

let's say it was a character with a arm, and to prevent the character from falling the developer constraint the collisions to rotate only around the upwords axis. Then this happens:

What the developer wasn't expecting is that when the arm is hit, it sends the character tumbling, instead of spinning. This is a very common mistake in a lot of games, because developers forget that a compound collision is made of individual parts and not a single object.

Another common mistake is to use a global up direction to lock the constraint, but that would act weird when the character is on a incline.

So often the total force is used like a gyroscope, gravity is checked for downwards force that already considers mass. This way a character can spin and fall over spinning correctly.

A global down vector multiplied by total mass should also work for this, since that is what gravity is most of the time. However in space like games with multiple gravity points, or a Super Mario Galaxy like game, gravity as a variable would be better.

So you say, if we take the arm picture and both bodies are a compound, and we use an up vector constraint on the compound, then both bodies are allowed to rotate around their blue axis? That's really bad, because for the physics engine a compound IS one sold body until you open it for modification. (not 100% sure, but i don't think PhysX is en exception here.)

I assume what's happening here is that Unity applies the rotation just on the visual objects and there is an offset matrix between physics and graphics to allow this. Or more likely, Unity just changes the individual bodies ignoring simulation, which also either leaves the physics engine with outdated data or a need for expensive recalculation of mass properties. In any case, to me this really looks like a bug or at least an unintended feature.

It would be interesting to look if there are two kinds of up vector constraints, one for Unity objcets, and another on top of a PhysX joint which works as expected.

Is this the same with UE?

6 hours ago, JoeJ said:

Usually physics engines support only to express the inertia of an ellipsoid (not even a simple box can be expressed accurately)

Inertia allways expressed as ellipsoide. It come from analitical mechanics, not from engine limitations. Each body regardless of it shape have a 3 general inertion axes so it have 3 inertion momentums respectively to each of general axes. So if you make a tensor from its momentums, it exacty match a tensor of ellipsoide quadric. It why inertion tensor also known as ellipsoide of inertion.

1 hour ago, Fulcrum.013 said:

Each body regardless of it shape have a 3 general inertion axes so it have 3 inertion momentums respectively to each of general axes.

But it's only an approximation of the real thing which can be pretty bad.

There is an alternative matrix representation instead just 3 values. But i never used it and i don't know which shape it can describe and how that's better. (Just a skewed ellipsoid, or some asymmetric shape ?)

It would not be the first time i start to argue about this with physics people, so i wonder if you agree...

For a quick test, you could make a box out of point masses placed on a regular grid (e.g. a block of minecraft voxels). Then you pick a direction between two opposite diagonal corners through the center and calculate inertia by summing up (mass(i) * projectedSquareDistToCom(i)). The result differs from the one you get form the analytical ellipsoid.

If you visualize all directions, the shape you get could be expressed better with spherical harmonics, but i doubt this holds for more complex shapes and i'm happy with ellipsoids.

4 hours ago, JoeJ said:

It would be interesting to look if there are two kinds of up vector constraints, one for Unity objcets, and another on top of a PhysX joint which works as expected.

I just want to clear up the confusion here, before Unity developers accuse me of selling the engine short. Compound collisions and Joint collisions isn't the same thing, although joints also allow for Compound collisions.

Compound collisions is a simpler and faster collision system. As long as there is gravity or a similar force involved it works perfectly. This is realistic as in the real world all physics bodies exercise a pull on each other, so there should always be some force, no matter how small, affecting a object.

I don't think the images shows it clearly, so I made a Gif:

As can be seen here, the constraints should have kept the game playing on a 2D axis, but the compound collision sends it rotating in a relative axis, moving it in 3D space. The effect is much less noticeable with gravity, it is easy to fix.

Using joints will fix this, but really not necessary for such a small thing.

4 hours ago, JoeJ said:

Is this the same with UE?

If you use the fast compound collisions yes. I think it is part of the formula, like a rotation vector based on gravity that isn't allowed to be zero, that is what I think.

Unreal actually has over 24 collision modes, however these can be placed into 3 classes.

1.) Single body collisions. You make these using the Unreal collision editor or by importing them. Think of this as a advanced convex hull system. You can use more than one collision shape here to make a custom collision shape, as long as the shapes don't overlap. Also K-DOP shapes.

2.) Joint collisions. This can be compound or not, the developer decides. Also supports 6DOF mode. These are easy to be setup inside the blueprint system of Unreal, by just adding in a joint component.

3.) Compound collisions. These are exactly like the Unity compound collisions but they are not so easy to use. They only work on Pawn Blueprint classes and have to be made using the Unreal Physics assets. These are used for character and gun collisions.

All these systems have more modes and preferences, it is easy to see why people think Unreal is a heavy to use engine. In Unity you just parent two collision objects to get compound collisions, or use a joint component.

42 minutes ago, JoeJ said:

But i never used it and i don't know which shape it can describe and how that's better.

It shape always ellipse. If you calculate inertion moment reapectively to all possible axes its values will draw a ellipsoide.

42 minutes ago, JoeJ said:

There is an alternative matrix representation instead just 3 values. But i never used it and i don't know which shape it can describe and how that's better. (Just a skewed ellipsoid, or some asymmetric shape ?)

It is not alternative, it is same. Matrix define a rotated ellipsoide and consists of factors from rotated ellipsoide equation. It used to make calculations using basis not aligned to general inertion basis. For basis aligned with general inertion basis ellipsoide is not rotated so any factors but its 3 values placed on general diagonal is zero. It is why general inertion axes and general inertion momentums called general.

3 hours ago, Scouting Ninja said:

Compound collisions and Joint collisions isn't the same thing

The term 'Joint collision' should not even exist. (From all you say i see it must be very confusing to handle physics engine as an Unity user, so what i say is not meant as correction, but in hope to limit some confusion...)

If you connect two bodies with a joint, they still remain two bodies, both of them are simulated, but a joint limits their relative degrees of freedom and can also include motors. If the joint limits all DOFs it is a 'fixed' joint, and the two bodies behave as if they would be only one solid body (compound). But the difference is:

* You can just enable or disable the joint to let the bodies disjoint or not (never a need to recalculate fused mass properties).

* You have to expect robustness issues like oszillation (jitter), much worse if the number of bodies becomes larger than just two.

* Inertia is not approximated by a single ellipsoid (so you could simulate complex shape more accurate if desired).

So in practice fixed joints are good for temporary connections, like a character driving a vehicle for a while an then continues to walk. But you always consider to use a compound instead for performance and stability reasons.

Compound really is to use multiple convex hull collision shapes to form a single body. Only one body is simulated by the physics engine. A collision against one of its sub-shapes can never cause the shapes to displace relative to each other. But you still have the option to remove / add / displace bodies yourself outside of the physics update. (Probably game engines do not expose all physics engine features.)

Usecase is to model a shape like a torus. You would need to join a large number of convex cylinder bodies to approximate such a shape. Using compound it is just one body solves and integration is as fast as for a simple box. (But collision detection is still more expensive because all subshapes need to be checked.)

The issues you get from up vectors / gravity still seems to be some kind of flaw to me. Probably caused by not making clear if those constraints are Unity constraints meat for procedural / kinematic animation, or physics joints meant for simulation. Those things should be seperated by both GUI and terminology, it seems this is done done totally right from what you say.

I really should take a closer look myself at those engines some day... i'm still left in confusion, although you've spent lots of efford. Maybe there is one more thing about inertia to tell - if you do not know that, it's a win:

Nonuniform inertia affects simulation robustness, meaning a long thin object is much more likely to cause jitter and such. So it is often worth to manually change inertia to be more uniform. E.g. for a ragdoll, the joints have much more impact on turning resistance than inertia anyways, so you can make each body to have uniform inertia and the effect is not noticeable, but jitter may be reduced dramatically. I guess this often happens automatically (Havok export tools had a checkbox to let the user decide), but it's worth to check it out. (Personally i often use inertia from a solid sphere that has the same volulme than the real body and replace the inertia numbers with that).

... hoping anything of this is useful

4 hours ago, Fulcrum.013 said:

It shape always ellipse.

I take this as an agreement that 3 number inertia is an approximation for anything that is not an ellipsoid. (Why do you physics guys always dodge this question? )

4 hours ago, Fulcrum.013 said:

It is not alternative, it is same.

No, i do not mean to use the matrix to have rotated representation of 3 number inertia, i mean something than can do more than an ellipsoid. I think Newton has support, but i also remember it form reading papers from the Baraff / Mirtich times, and i connect it with the term 'asymmetric inertia' (but that may be wrong).

1 hour ago, JoeJ said:

i do not mean to use the matrix to have rotated representation of 3 number inertia

Matrices is just a other form of representation of quadric equation https://nb.khanacademy.org/math/multivariable-calculus/applications-of-multivariable-derivatives/quadratic-approximations/v/expressing-a-quadratic-form-with-a-matrix

1 hour ago, JoeJ said:

also remember it form reading papers from the Baraff / Mirtich times

Mirtich like any other math and physic guys use a matrix representation for any equations where it possible, becouse it much shorter then polinomus.

2 hours ago, JoeJ said:

and i connect it with the term 'asymmetric inertia' (but that may be wrong).

Some kind of asymetri may come from rotations respectively to other point than center of masses, for example for joint rotation. So to find a inertion moment for shifted center used a rule of aхis shift that together with rotation of ellipsoide represented by extended 4x4 matrix, that is form of representation of full quadric equation that have all factors nonzero.

2 hours ago, JoeJ said:

Inertia is not approximated by a single ellipsoid (so you could simulate complex shape more accurate if desired).

https://en.wikipedia.org/wiki/Moment_of_inertia

3 hours ago, Fulcrum.013 said:

Some kind of asymetri may come from rotations respectively to other point than center of masses, for example for joint rotation. So to find a inertion moment for shifted center used a rule of aхis shift that together with rotation of ellipsoide represented by extended 4x4 matrix, that is form of representation of full quadric equation that have all factors nonzero.

9 hours ago, Fulcrum.013 said:

It is not alternative, it is same. Matrix define a rotated ellipsoide and consists of factors from rotated ellipsoide equation. It used to make calculations using basis not aligned to general inertion basis. For basis aligned with general inertion basis ellipsoide is not rotated so any factors but its 3 values placed on general diagonal is zero. It is why general inertion axes and general inertion momentums called general.

Yeah, i think that's it. I was reading up on Newton forum, and the developer mentions asymmetric inertia in combination with full inertia matrix support when he made a simulation of a Rattleback (toy thing that only wants to rotate counter clockwise). This has an elliptical shape, but the inertia is rotated a bit off (achieved by additional weights or holes in real world to affect density). So full inertia matrix means the option to rotate the inertia from the principal axis, which is useful for primitives like capsule / box / ellipsoid etc. (for a polyhedron you could just rotate the geometry instead.)

I finally get it. The rest i've remembered just wrong, thanks!

Edit: Haha - I was puzzling about some matrix math in Newtons code while looking it up, and the Khan video explains it. I should watch more of this...

1 hour ago, JoeJ said:

So full inertia matrix means the option to rotate the inertia from the principal axis,

Inertia ellipsoide position and orientation depends from body's mass distribution only. So ellipsoide have his centre in centre of mass that in general case not match a model space origin and general inertion axes rotated. Homogenous spheres, boxes, capsules, cylinders, boxes, ellipsoides have a center of mass at its geometrical center, and like a cone have main inertion axes alligned to sides/rotation axe. But for other kind of shapes like as for compound or heterogenous matherial shapes inertion basis not match model space basis.

Like centre of mass match a symmetri planes for symetrical bodies, general inertion axes always lies in the planes of symmetri. It whay most of animals and moving machines allways symmetrical - to keep at least one of general inertion axes into same plane with forward movement direction.

Also capsules, cylinders, ellipsoides, cones, parabaloids an other quadrics can be represented by same matrix, but with other set of factors, and as result rotated and shifted, like as any equation. To transform any equation it require to substitute vectors of new basis to variables of equation and then open the brackets and calculate factors. It is what actually transformation matrices do for linear equations. For quadric equations it work little bit complexive and require 2 matrix multiplication. Just higher power equation usualy not represented by matrix becouse used much rare than linear and quadric equations.

2 hours ago, Fulcrum.013 said:

To transform any equation it require to substitute vectors of new basis to variables of equation and then open the brackets and calculate factors. It is what actually transformation matrices do for linear equations. For quadric equations it work little bit complexive and require 2 matrix multiplication. Just higher power equation usualy not represented by matrix becouse used much rare than linear and quadric equations.

Interesting (and new to me, but it already helps).

What would be the simplest general problem you can think of where this is useful so i can practice that?

I want to look at how quadric error metrics for mesh simplification works anyways, but if you know something simpler please let me know...