What if in games to use a video card for physics, not for graphics
I want to tell the community about my experiment.
I always liked games in which there is physics. That is, some processes are not controlled by scripts, but evolve in time, following physical laws. From this stem the complexity and unpredictability of the gameplay.
There are many examples; physical elements finely permeate the variety of computer games. Take at least any platformer: a completely different feeling from the game, when there is inertia of the character, sliding, gravity, damage from falling from a great height and recoil from the weapon.
')
Or the same race: how nice it is to knock people at full speed, billboards and garbage so that they fly away in all directions, instead of stopping instantly, crashing into a deadly bred column.
Or another great example - Kerbal Space Program. There, physics is already a direct source of gameplay.
Or, for example, 2d artillery genre. Part of its charm is based on a destructive, dynamic land. But he would have been better off if the earth had not just crumbled linearly, but behaved realistically, scattering from the explosions in chunks.
I have long dreamed of making just such a physically realistic remake of Scorched Earth to the limit. But all my experiments with modeling of physical systems rested against inexorably slow processors. A thousand or two particles were the limit for a real-time simulation.
But my recent "discovery" has changed the situation. We live in a time of rapid development gaming iron. Video cards mainly developed, because game manufacturers with the greatest enthusiasm increased the graphic component of games, and iron producers maintained high fps. And it’s not surprising that Nvidia’s decision to add the ability for developers to write code for the graphics system, that is, perform calculations in the graphics core.
In my opinion, this decision was a quiet revolution. Of course, I knew that the video card is more powerful than the processor, but I did not know to what extent. On average, a gaming computer video card performance is 50-100 times higher than the performance of the CPU.
Of course, the task must be well parallelizable, this bonus is not relevant for any algorithm. But the simulation of thousands of particles perfectly parallelized.
Realizing this, I realized that at last I could create a completely physical game in which nothing but physics would be scripted. The game will be equivalent to a physical simulation.
I have been making games on Unity for a long time, and I was pleased to learn that the ComputeShader class was implemented in this engine, which allows using shaders in the HLSL language in the project. Simply write the shader, link it to the ComputeShader instance, and dispute in Update.
Understanding parallel computations on the GPU was not too easy. Tutorials are not enough, and those that exist are rather limited in the volume of explained subtleties. But there were not so many key difficulties, the HLSL reference information was quite rich on msdn, so somehow through trial and error I mastered the specifics and started making the game.
The task was simple: you need to simulate in real time several tens of thousands of interacting particles, and from them build a world that would live by its own laws.
Parallel computing is a cunning thing. It was necessary to reduce all calculations to simple blocks of the same size, so that there would be one stream for each particle. I decided to simplify the interaction of particles to the limit of mathematics. For example, to do without an integrator, simply measure the magnitude of the field (describing the interaction of particles) at the current point, and on its basis change the velocity of the particle. Simplicity guaranteed that all threads would run equally fast, and there would be no heavy threads that others would have to wait.
In addition, when interacting with particles, it was necessary to work with data in a protected mode so that parallel streams were aware of simultaneous writing and reading and were not confused. After all, if a particle can simultaneously interact with a dozen other particles, they can all simultaneously change its speed, which means that it is necessary to do this in a protected mode. Funds for this in HLSL were found. True, operators like InterlockedAdd () work only with int-values, so you had to sacrifice accuracy and store the speed in video memory as int-values.
Huge arrays of interacting particles - also a cunning thing. It was necessary to simplify the complexity of the deductions with
I achieved this by creating a two-dimensional grid of 256x256, and in each of its elements at every step I kept references to all the nearest particles, so that when calculating the interaction of particles, each particle interacts with only those particles that are within several 3x3 grid elements.
By the way, why, instead of the physics engine already implemented in Unity, I created my own? Because a universal physics engine, suitable for a wide range of tasks related to modeling a system of solids, is poorly suited for modeling a system of interacting material points. I preferred the original engine optimized for specificity. If you create a thousand objects with a rigidbody in the unit, you can make sure that fps drops quite a lot. In my case, we need tens of thousands of particles, and the engine written from scratch allows us to calculate them with good fps.
Discrete simulation of physical interaction - again, an insidious thing. The larger the step, the greater the error. The interaction between particles is realized through the Lennard-Jones force, that is, when particles approach each other, the repulsive force increases to the twelfth degree. This incredibly reinforces the error associated with a big step. Simply, matter explodes, violates the law of conservation of energy.
A contradiction arises: we need a fast real-time simulation. But the step should be very small. I resolved this contradiction by reducing the step by a factor of ten compared with the first experiments, and performing ten simulation cycles in each Update (). The price of this solution is performance. So I had to greatly reduce the number of particles. But still there are enough of them for the complex behavior of the entire system.
Well, a couple dozen more tricks were implemented by me to get a satisfactory behavior of matter. For example, I introduced an analogue of valence bonds between particles, which distribute the pulses and velocities of a particle between neighbors. Or, for example, gravity does not act over the entire volume of the earth, but affects only the upper layer of particles. But if large chunks of matter fly into the air, gravity will influence them fully. This is implemented by building a gravity mask at every step, and taking it into account during calculations.
And there are still many such subtleties, I don’t want to delve too much into this specifics. Four months in the hobby mode was spent on solving all the problems with parallel computing and physics, and at some point it was possible to move to the gameplay level.
What is the result? It turned out the game in the genre of "2D artillery", like Pocket Tanks, Scorched Earth or Worms.
Here is a long, ten minutes, video, which also shows the gameplay, but in more detail:
You may notice that the land and buildings look like jelly. This is corrected due to performance. You can reduce the step and increase the coefficient of the influence of fields on the velocity of particles. But for now, I try to keep the game at a level that is not too burdensome for most not too old video cards. Say, on my GTX 750m map, in which there are 384 cores, a game with 20 thousand particles works at a frequency of 25 fps, which makes it quite playable.
There are two conclusions here, objective and subjective:
1. The video card has enormous power, and now there are no insurmountable technical obstacles that prevent developers from using it for computing. This may open up for practical use previously inaccessible (due to computational heaviness) approaches to the gameplay.
2. Very unusual sensations arise from playing in a physically realistic sandbox. And in my opinion, there are buried a lot of unexpected ideas in the field of gameplay design. And I would like the developers to experiment more with the introduction of physics into the gameplay, because the light on the graph has not come together.
I always liked games in which there is physics. That is, some processes are not controlled by scripts, but evolve in time, following physical laws. From this stem the complexity and unpredictability of the gameplay.
There are many examples; physical elements finely permeate the variety of computer games. Take at least any platformer: a completely different feeling from the game, when there is inertia of the character, sliding, gravity, damage from falling from a great height and recoil from the weapon.
')
Or the same race: how nice it is to knock people at full speed, billboards and garbage so that they fly away in all directions, instead of stopping instantly, crashing into a deadly bred column.
Or another great example - Kerbal Space Program. There, physics is already a direct source of gameplay.
Or, for example, 2d artillery genre. Part of its charm is based on a destructive, dynamic land. But he would have been better off if the earth had not just crumbled linearly, but behaved realistically, scattering from the explosions in chunks.
I have long dreamed of making just such a physically realistic remake of Scorched Earth to the limit. But all my experiments with modeling of physical systems rested against inexorably slow processors. A thousand or two particles were the limit for a real-time simulation.
But my recent "discovery" has changed the situation. We live in a time of rapid development gaming iron. Video cards mainly developed, because game manufacturers with the greatest enthusiasm increased the graphic component of games, and iron producers maintained high fps. And it’s not surprising that Nvidia’s decision to add the ability for developers to write code for the graphics system, that is, perform calculations in the graphics core.
In my opinion, this decision was a quiet revolution. Of course, I knew that the video card is more powerful than the processor, but I did not know to what extent. On average, a gaming computer video card performance is 50-100 times higher than the performance of the CPU.
Of course, the task must be well parallelizable, this bonus is not relevant for any algorithm. But the simulation of thousands of particles perfectly parallelized.
Realizing this, I realized that at last I could create a completely physical game in which nothing but physics would be scripted. The game will be equivalent to a physical simulation.
I have been making games on Unity for a long time, and I was pleased to learn that the ComputeShader class was implemented in this engine, which allows using shaders in the HLSL language in the project. Simply write the shader, link it to the ComputeShader instance, and dispute in Update.
Understanding parallel computations on the GPU was not too easy. Tutorials are not enough, and those that exist are rather limited in the volume of explained subtleties. But there were not so many key difficulties, the HLSL reference information was quite rich on msdn, so somehow through trial and error I mastered the specifics and started making the game.
The task was simple: you need to simulate in real time several tens of thousands of interacting particles, and from them build a world that would live by its own laws.
Parallel computing is a cunning thing. It was necessary to reduce all calculations to simple blocks of the same size, so that there would be one stream for each particle. I decided to simplify the interaction of particles to the limit of mathematics. For example, to do without an integrator, simply measure the magnitude of the field (describing the interaction of particles) at the current point, and on its basis change the velocity of the particle. Simplicity guaranteed that all threads would run equally fast, and there would be no heavy threads that others would have to wait.
In addition, when interacting with particles, it was necessary to work with data in a protected mode so that parallel streams were aware of simultaneous writing and reading and were not confused. After all, if a particle can simultaneously interact with a dozen other particles, they can all simultaneously change its speed, which means that it is necessary to do this in a protected mode. Funds for this in HLSL were found. True, operators like InterlockedAdd () work only with int-values, so you had to sacrifice accuracy and store the speed in video memory as int-values.
Huge arrays of interacting particles - also a cunning thing. It was necessary to simplify the complexity of the deductions with
I achieved this by creating a two-dimensional grid of 256x256, and in each of its elements at every step I kept references to all the nearest particles, so that when calculating the interaction of particles, each particle interacts with only those particles that are within several 3x3 grid elements.
By the way, why, instead of the physics engine already implemented in Unity, I created my own? Because a universal physics engine, suitable for a wide range of tasks related to modeling a system of solids, is poorly suited for modeling a system of interacting material points. I preferred the original engine optimized for specificity. If you create a thousand objects with a rigidbody in the unit, you can make sure that fps drops quite a lot. In my case, we need tens of thousands of particles, and the engine written from scratch allows us to calculate them with good fps.
Discrete simulation of physical interaction - again, an insidious thing. The larger the step, the greater the error. The interaction between particles is realized through the Lennard-Jones force, that is, when particles approach each other, the repulsive force increases to the twelfth degree. This incredibly reinforces the error associated with a big step. Simply, matter explodes, violates the law of conservation of energy.
A contradiction arises: we need a fast real-time simulation. But the step should be very small. I resolved this contradiction by reducing the step by a factor of ten compared with the first experiments, and performing ten simulation cycles in each Update (). The price of this solution is performance. So I had to greatly reduce the number of particles. But still there are enough of them for the complex behavior of the entire system.
Well, a couple dozen more tricks were implemented by me to get a satisfactory behavior of matter. For example, I introduced an analogue of valence bonds between particles, which distribute the pulses and velocities of a particle between neighbors. Or, for example, gravity does not act over the entire volume of the earth, but affects only the upper layer of particles. But if large chunks of matter fly into the air, gravity will influence them fully. This is implemented by building a gravity mask at every step, and taking it into account during calculations.
And there are still many such subtleties, I don’t want to delve too much into this specifics. Four months in the hobby mode was spent on solving all the problems with parallel computing and physics, and at some point it was possible to move to the gameplay level.
What is the result? It turned out the game in the genre of "2D artillery", like Pocket Tanks, Scorched Earth or Worms.
Here is a long, ten minutes, video, which also shows the gameplay, but in more detail:
You may notice that the land and buildings look like jelly. This is corrected due to performance. You can reduce the step and increase the coefficient of the influence of fields on the velocity of particles. But for now, I try to keep the game at a level that is not too burdensome for most not too old video cards. Say, on my GTX 750m map, in which there are 384 cores, a game with 20 thousand particles works at a frequency of 25 fps, which makes it quite playable.
There are two conclusions here, objective and subjective:
1. The video card has enormous power, and now there are no insurmountable technical obstacles that prevent developers from using it for computing. This may open up for practical use previously inaccessible (due to computational heaviness) approaches to the gameplay.
2. Very unusual sensations arise from playing in a physically realistic sandbox. And in my opinion, there are buried a lot of unexpected ideas in the field of gameplay design. And I would like the developers to experiment more with the introduction of physics into the gameplay, because the light on the graph has not come together.
Source: https://habr.com/ru/post/320142/
All Articles