## Bibliography

I'm Eduardo Alvarado, 2nd-year Ph.D. student at École Polytechnique in Paris (France). I work at the Geometric and Visual Computing (GeoViC) group, under the supervision of Prof. Damien Rohmer and Prof. Marie-Paule Cani. I am part of the Marie Skłodowska-Curie Innovative Training Network CLIPE, funded by the European Union Horizon 2020 framework.

Prior to my Ph.D., I got my M.Sc. in Embedded Systems and AI at Albert-Ludwigs-Universität Freiburg in 2019, while I was working at the AIS group, ZF Friedrichshafen, and writing my thesis on Deep Multimodal Learning for Autonomous Driving at Robert Bosch GmbH, advised by Prof. Dr. Joschka Boedecker and Prof. Dr. Abnihav Valada. I completed my B.Sc. in Electronics and Automation Engineering at Universidad Carlos III de Madrid in 2014, advised by Prof. Angel Garcia Crespo.

My research is centered on plausible, interactive and multi-scale 3D animation (physically-based, kinematic) for humans and animals in dynamic and deformable environments, with focus on authoring tools for the entertainment industry (games, VR).

## Projects

• Master Thesis in Deep Multimodal Learning

2019, Robert Bosch GmbH

• ROS Data Manipulation for Autonomous Vehicles

2018, ZF Friedrichshafen

• Bachelor Thesis in Augmented Reality for Geolocalization

## Skills

### Computer Science

Python, C#, C, C++ and Java over +7 years of experience...and always ready to keep learning!

### Games R&D

Passionate about game-dev/tech, 3D Modeling and VR/AR: Unity, UE, Blender, Substance

### SW Development

Production-ready SW (Visual, CMake), version control, quality-assurance and debugging

### Machine Learning

Modern AI techniques for Deep Learning and Reinforcement Learning (Tensorflow, PyTorch)

### Robotics

Autonomous Intelligent Systems, Mapping & Localization (SLAM), AI for Computer Vision

### Technical Art

Research on expressive AI, interactive methods and creative-oriented approaches

### 1/+2 Players

Ability to collaborate constructively in large teams as well as to work independently

### Management

Strategy planning, problem-solving and analytical skills in research environments

## Forces in Unity: The Basics

In this post, we explain how forces in Unity works. How laws of physics work in the real world are pretty clear. However, a physical simulator (like PhysX, the one Unity uses, or many other that you are used to see in games) can make different assumptions, which do not necessarily match how it happen in the real world.

### Introduction

A rigid-body is a solid element whose dynamics are estimated with respect to certain center of mass (a point) that represents the body. To move rigid-bodies in Unity (or many other game-engines using a physical simulator to move objects around), you can do it in different ways:

1. By defining the position of the object directly.
2. By defining the velocity vector (first derivate of the position).
3. By defining the acceleration vector (second derivative of the position).

However, the first two methods to move a rigid-body in a simulator have some (big) problems. You should never move objects directly by defining their position, as it might cause instability issues in your simulator. Defining the velocity might be correct, but this could also cause certain issues when the object interact with other forces. [todo]

Defining the acceleration of the object seems the proper way to go, and considering that rigid-bodies have a mass, the most physics-friendly method to interact with them is by applying a force.

Although forces directly control a body’s acceleration, the velocity and the position are only controlled indirectly. This is a problem when you need immediate response. However, applying a force helps you to keep every motion coherent with respect to any constraint in the scene (such as joints).

Real world is continuous. As such, high-school teaches us that:

p_1 = a * dt * dt / 2 + v * dt + p_0

However, in a game-engine, which aims to run a game frame-by-frame, this might change. Applying forces continuously could lead  to ever increasing velocities and eventually, a failure in the physics solver. To avoid this, PhysX accumulates the acting forces on a body before each simulation frame and then are set to zero before the next frame.

In PhysX, accelerated motion is estimated using the following formula:

p_1 = (a * dt  + v) * dt + p_0
				
console.log( 'Code is Poetry' );

console.log( 'Code is Poetry' );
console.log( 'Code is Poetry' );
console.log( 'Code is Poetry' );
console.log( 'Code is Poetry' );



Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.

### Conclusion

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.