RELATED TOPICS
For his graduation work Dovydas Budrys explored the possibilities of making an tornado in the unreal engine that interacts with its surroundings.
Not having encountered a tornado himself as of yet, it is important to begin with the basic research. To even have a general idea of tornados and forces behind them, Dovydas started looking at more scientific explanations to really try and grasp the concept behind it.
After having done the theoretical research and taking in all the information, he moved on to the practical side of things, which, for someone who enjoys doing the art side of game development but with a spice of technical things, was a refreshing step. He quickly began brain storming for possible approaches on how to translate and simulate the physical effect of tornados inside the game engine in a convincing enough fashion.Dovydas started with the built in tools of UE4 to achieve this effect, which seemed rather straight forward, however in the end he discovered quite a few tricky issues.
At this point, he started blocking out a few things in UE4’s blueprint system to help support testing his research elements, one of the first things including a sort of a procedural test arena “sandbox” enclosed by walls and controlled by a set of parameters, that allowed him to change the size without needing to move anything by hand, as well as wall thickness, wall height and such. Additionally, he built an object spawning system that allowed him to throw physics-enabled objects of random scale values from current point of view by giving them a parameterized amount of impulse, in a form of a random amount between a set minimum and maximum value, towards the forward vector of the observer camera.
Dovydas also needed a way to move the simulation around, as a real tornado in real life would move around. Mainly to test different real life scenarios, for instance, what happens when a tornado runs into a pile of objects of different types and properties and so on. For this he looked into approaching a way to convert a screen space mouse position into a world position, that he could use to move the simulation around.
Next up was the simulation of objects getting pulled into the tornado itself. After some testing he decided that the Add Force Node was what would be the best option together with some math, like the centripetal force formula.
The idea behind it was that whenever a physics enabled object enters the sphere trigger, it gets acted upon by 3 types of forces. First one being the centripetal force itself, where the object is constantly being pulled into the core of the tornado. To counter act the straight movement another force is added, which is similar to the first one, but perpendicular. This alone creates a circling motion and a good base for a tornado, if the parameters are balanced well enough of course. What is more, while the object’s circling speed keeps rising, it increases its inertia, up to a point where the inertia gets higher than the pulling force of the tornado, allowing the object to escape and be thrown away in a random direction. Combined with the lifting force and the gradual effect on the edges on all 3 forces, a convincing and natural looking result is achieved. Taking into account the mass of each object and allowing them to escape due to inertia, exactly what I was looking for!
Furthermore, I wanted to add in destruction into the simulation, an ability to shatter objects in such a way, depending on what the object is made out of, whether it’s concrete, wood, etc. He used a Voronoi Fracture script for 3ds Max to break the objects.In stead of Nvidia’s PhysXLab, which is supposed to give good control of fracturing and work well with the Destructible Meshes option in Unreal Engine.
Dovydas should be proud how his project turned out, taking into account that it is real time, the result is convincing, both simulation and destruction wise.
However, one of the things that he wishes would have worked out was the Destructible Meshes (Nvidia’s PhysXLab) feature, mainly because of all of its available features, especially the partial destruction, ease of use, and flexibility in general, that would have delivered an even more accurate result. It is possible, but in cost of having inaccurate simulation itself, which was the opposite of his aim. On the bright side, having manual non engine specific workarounds to these issues also means that the project solution could be adapted in different game engine environments, for example Unity3D or CryEngine.
