Monday, 31 August 2015

Experimenting with friction in Unity

Initial setup

Let's create a plane. Next create a cube and place it right on top. Add a box collider and rigid body to the cube.

Basic friction

Let's create a Push script adding a force to the cube at every fixed update:

GetComponent<Rigidbody>().AddForce(force,ForceMode.Force);

ForceMode.Force indicate a continuous force. The result of applying a horizontal force is interesting: under 10 units (Newtons, I hope) the box doesn't budge. At 10, it doesn't slide, instead, it topples. This strongly suggests that friction is present.

Next we create a so called Physic Material. Default friction value is 0.6 for static and dynamic (see definitions here). At around 0.3 the box is moving, and doesn't topple.

Moving platforms

Turn off the Push script and create a Move script applied to the plane. Since the plane is not a rigid body no point in applying forces. Instead we generate a linear translation inside Update() or FixedUpdate()

transform.position += velocity * Time.deltaTime;

The plane moves, but the box doesn't. So we have friction, but it's a one way affair. Yet the box and plane are still interacting: Once the plane has been removed from under it, the box falls (though, it doesn't topple).

Add a rigid body to the plane and check kinematic. Restart the simulation. Now the plane still slides under the box. Upon reaching the edge, however, the box topples.

Still no friction?

Uncheck kinematic and gravity. This time we get an error: Unity considers that the mesh collider is not convex so it won't allow physics on it. I wouldn't try making the plane convex so I replaced it by a box collider. Without gravity the plane won't fall on its own. However the box is now pushing it downwards. No good.

We don't want this plane to fall so, freeze Y position along with all rotation axis. Now the plane yet again slides under the box, which finally topples.

Still no friction?

Substitute the original Push script to the Move script. Now the plane is dragging the box away (this works with any Force mode).
Finally, re-apply the physic material and lower the friction. Somewhat surprisingly, it now takes significantly low friction values (~0.01) to the box to topple off the plane.

The uncanny experiment

In rigid body settings, freeze the plane's location and rotation (all axis). Run the simulation and observe: the box is moving, then topples off the plane: the plane now behaves like a rolling carpet.

Conclusion
  • Friction is a property of colliders, not rigid bodies.
  • Friction applies to moving rigid bodies using forces: when moving a solid over static terrain, we needn't add a rigid body to the terrain to simulate friction.
  • Friction doesn't apply to kinematic bodies: therefore, to define a moving platform with correct friction:
    • Must have a collider
    • Must have a rigid body
    • Kinematic is unchecked
    • Move the platform using forces.
    • Take advantage of rigid body constraints.

Wednesday, 26 August 2015

Did Mixamo solve the animation problem?

At the time of writing, all commercial services at Mixamo are down following their purchase by Adobe. In the meantime, their animation system is in demo mode. And it looks like Blender support improved. Let's have a look.

A first run with Mixamo

(21:40) I exported my model (obj format) from Blender. I decided to only use the .obj since I don't have textures.

(21:52) Auto-rigging config is manual but placing joints only takes a couple of minutes (really). Then according to a caption, it will take about 2 minutes for auto-rig to complete.

(22:04) Chose a few basic animations. Plays nice in preview, now I would like to export them. Go My Assets and select Collada as export format. Oh well. This proved to be somewhat fiddly as I needed to checkout animations. Although their shop is down this is still doable.

(22:12) Let's try to export these animations. Choosing collada, non uniform frame reduction

(22:37) I could get my model and animations back into blender but the export results looked weird.

(22:49) After fiddling for a bit, I somehow established a correct import configuration.

Tips
  • Correct DAE export for blender requires exporting with skin and no keyframe compression
  • On some animations (typically, walking, running, ...) check 'in place' to prevent the model from moving while animating.
(P)review

Mixamo is a complete animation solution. It seems to work pretty good, especially with humanoid characters.
Auto-rigging isn't a feature that I absolutely need, and I'm not sure how it would fare with complex meshes. Apparently, it works.

Pros:
  • Good performance in web client.
  • Blender import actually works.
  • Free stuff
Cons:
  • Their animation collection is big, not huge. Maybe enough to prototype stuff and create a AA game.
  • High number of keyframes may be affecting file size.
  • In Blender
    • Animations need to be imported separately
    • Rig and model import with each animation.
    • Animations get in with incorrect names.
    • Models get in wrongly scaled
    • Inept rigs
    • One key frame per frame?
Until then...

Adobe purchased Mixamo, pulling the plug on sale services without a go-live date. They also pulled the plug on Mixamo's UAS (Unity Asset Store integration) so it's overall a very bad time to invest time and effort into Mixamo; more so considering that, it's hard to believe that Adobe will encourage improving Blender integration. Casual devs will welcome the fact that some of their tools and services (10 rigs, 20 animations) for free while they transition into the unknown.

About aeronautic coordinates

Often confused with Euler angles, aeronautic coordinates are useful in games (even if you're not writing a flight simulator)

Used in 3D applications, Euler angles 'in general' often become an endless source of surprise, confusion and pain. In contrast, aeronautic coordinates use well defined conventions

Please assume a vehicle's nose (think of a plane) is pointing towards Z positive, and its right wing is lying along the X axis. Many game developers find this orientation intuitive.

Aeronautic coordinates, consist in pitch, yaw and roll, also known as atttidue, heading and bank.
In some litterature you will find the term 'attitude' used to refer aeronautic coordinates altogether.

Unity3D implementation => [source]

Useful definitions.

  • Pitch/Attitude - an angle indicating whether a vehicle is flying upwards or downwards. 
  • Yaw/Heading - an angle indicating a vehicle's general direction/course. In the real world, cardinal points (north, south, east, west) are often used to refer a vehicle's heading but this is unpractical when dealing with computers.
  • Roll/bank - an angle indicating whether a vehicle is tilted or not. For example, a plane is 'tilted' when their wings do not lie in the horizontal plane. 

Calculations

While there are many ways to extract aeronautic coordinates from a transform, and quite possibly several correct ways to do so, I will suggest an approach which I hope you will find safe and intuitive. 

I assume that you have access to the forward, right and up vectors associated with your transform.

Then you can use the following recipes:

Pitch:
   Return -asin( forward.y )

Yaw:
   Let F be the ground projection of the forward vector.
   Let R be the ground  projection of the right vector
   If u is small/degenerate:
      Let α be the angle between R and the right vector (1,0,0)
      Return R.z<0 ? α : -α
   Otherwise... 
      Let α be the angle between u and the forward vector (0,0,1)
      Return F.x>0 ? α :-α

Roll
   Return -asin(right.y)

Important: Your forward, right and up vectors must be normalized.
Occasionally APIs return components (slightly) without the [ -1, 1 ] inclusive range. clamp right.y, forward.y to make sure that this doesn't happen, otherwise asin would return incorrect values.

Additional note

With some implementations, the heading is undefined when a vehicle is pointing straight up. This satisfies the (flawed) intuition that a vehicle pointing upwards isn't going north, east, west or south. It is a flawed intuition because, even when a plane is flying straight up, you can infer its heading from the position of its wings. The suggested recipe and linked implementation leverage this idea to avoid errors.

Thursday, 6 August 2015

Smartphones still strong against tablets

Unity Technologies happen to maintain detailed statistics suggesting that smartphone users outdo tablets on their install user base. Here's a summary of the iPhone vs iPad breakdown:
  • iPhone: 62%
  • iPad: 37%