Simulation physique de centaines de milliers de particules sur Unity + DOTS

À un moment donné, en me promenant dans les étendues du World Wide Web sur l'un des sites, j'ai trouvé un élément JS interactif - une image composée de particules se séparant à l'approche du curseur de la souris. Il y avait un désir de programmer une simulation d'un tel comportement sur Unity et de vérifier quelles performances peuvent être retirées du moteur. Je partage avec vous les solutions techniques et mes observations reçues lors du processus de mise en œuvre.



Le résultat est le suivant:


Pour y parvenir, vous devez résoudre les problèmes suivants:

• décrire la physique des particules;
• assurer la vitesse optimale de calcul de position sur chaque trame;
• choisissez un moyen de dessiner rapidement un grand nombre de particules sur l'écran.

La physique

Pour décrire le comportement souhaité des particules, nous devons formuler seulement trois principes: le désir de réduire la distance jusqu'au point de départ, le désir de «s'envoler» du curseur de la souris et l'amortissement du mouvement. Nous n'avons pas besoin d'interactions physiques et de formules exactes, nous avons seulement besoin de principes généraux, se déplaçant selon lesquels la particule se comportera de manière délibérée. Par souci de simplicité, la masse est exclue de toutes les formules - nous convenons de la considérer comme unique.

Réduire la distance jusqu'à la position de départ

Pour que la particule s'efforce de revenir à sa position d'origine, la loi de Hooke nous conviendra : la force dirigée vers la position initiale sera linéairement proportionnelle à la distance qui la sépare. La particule s'est envolée deux fois plus loin de la position initiale - deux fois plus forte, elle «tire» en arrière, tout est simple.

La distance du curseur

Pour être intéressant, les particules doivent en quelque sorte interagir avec le curseur, se permettre de «pousser» depuis la position de départ. J'ai pris la gravité avec le signe opposé comme base de cette interaction : les particules seront repoussées par une force inversement proportionnelle au carré de la distance entre la position du curseur de la souris et la position actuelle de la particule et dirigées le long du vecteur du curseur à la particule.$$$F = -C/r^2$ , où$$$C$ est une certaine constante qui régule l'interaction.

Atténuation

Si nous nous limitons aux deux formules précédentes, la particule après avoir réglé l'amplitude initiale oscillera pour toujours, car il n'y a nulle part où perdre de l'énergie dans le cadre d'un tel modèle. Nous simulerons l'atténuation comme la force de la résistance visqueuse du milieu, qui, selon la loi de Stokes , est linéairement proportionnelle à la vitesse des particules et dirigée dans la direction opposée au mouvement. Nous sommes satisfaits des restrictions imposées à l'applicabilité de cette formule, car dans ce cas, nous ne nous intéressons pas à la précision absolue de l'interaction physique, mais uniquement au principe.

Résultat

En conséquence, nous obtenons la formule de la force agissant sur la particule à un moment arbitraire dans le temps:

$$

$$\vec{F}_s=C_a*(\vec{x}-\vec{x}_0)-\frac{C_r}{||\vec{x}-\vec{x}_r||^2}*\frac{\vec{x}-\vec{x}_r}{||\vec{x}-\vec{x}_r||}-C_d*\vec{v},$$

Où $$$x, v$- position actuelle et vitesse des particules,$$$x_0$ est la position initiale,$$$x_r$ - position du curseur,$$$C_a, C_r, C_d$ sont respectivement les coefficients d'attraction, de répulsion et d'atténuation.

Comportement de programmation

Étant donné que dans notre modèle, les particules sont indépendantes les unes des autres et que leur comportement est déterminé uniquement par leurs caractéristiques et leurs constantes communes, le calcul de l'état mis à jour est idéalement adapté à la parallélisation. Compte tenu de mon intérêt de longue date pour Unity DOTS , j'ai décidé d'appliquer cette technologie pour résoudre le problème formulé.

DOTS est un développement relativement récent du moteur Unity, une pile technologique axée sur l'écriture de code multithread haute performance. Sur Habré, il y a une traduction d'un article introductif dans DOTS. Grâce à l'utilisation de l' ECS , du modèle architectural de Jobs System et du compilateur Burst, DOTS permet d'écrire du code multithread rapide, tout en réduisant la probabilité d'un tir dans le pied.

L'essence de l'écriture d'un programme dans l' ECS est de séparer le code en composants ( composants ) qui décrivent l'état, systèmes ( systèmes ) qui décrivent le comportement et l'interaction des composants, et entités - objets qui contiennent un ensemble de composants.

Composants

Nous aurons besoin des composants suivants:

//    ( )
public struct AttractorPosData : IComponentData
{
   public float2 Value;
}

//  
public struct VelocityData : IComponentData
{
   public float2 Value;
} 

//  
public struct AccelerationData : IComponentData
{
   public float2 Value;
}

//   
public struct ParticleData : IComponentData 
{
    public Color color;
    public Matrix4x4 matrix;
}

Avec les composants, tout est assez simple, allez aux systèmes:

//   
[UpdateBefore(typeof(MoveSystem))]
public class VelocityUpdateSystem : SystemBase
{
    protected override void OnUpdate()
    {
        var time = Time.DeltaTime;
        Entities.ForEach((ref VelocityData velocity, 
                in AccelerationData acceleration) =>
            {
                velocity.Value += time * acceleration.Value;
            })
            .ScheduleParallel();
    }
}

//   
public class MoveSystem : SystemBase
{
    protected override void OnUpdate()
    {
        var time = Time.DeltaTime;
        Entities.ForEach((ref Translation t, in VelocityData velocity) =>
            {
                t.Value.xy += time * velocity.Value;
            })
            .ScheduleParallel();
    }
}

Vous pouvez contrôler la séquence des systèmes à l'aide d'attributs

[UpdateBeforeAttribute]
[UpdateAfterAttribute]

Le plus grand système qui décrit le comportement sera le système de mise à jour de l'accélération, agissant conformément à la formule dérivée :

[UpdateBefore(typeof(VelocityUpdateSystem))]
public class AccelerationSystem : SystemBase
{
    protected override void OnUpdate()
    {
        float2 repulsorPos = Globals.Repulsor.Position;

        //   
        var attractionPower = Globals.SettingsHolder.SettingsModel.Attraction;
        //  
        var repulsionPower = Globals.SettingsHolder.SettingsModel.Repulsion;
        //  
        var dampingPower = Globals.SettingsHolder.SettingsModel.Damping;
        Entities.ForEach((
                ref AccelerationData acceleration, 
                in AttractorPosData attractorPos, 
                in Translation t,
                in VelocityData velocity) =>
            {
                //  
                var attraction = (attractorPos.Value - t.Value.xy) * attractionPower;

                var distSqr = math.distancesq(repulsorPos, t.Value.xy);
                //  
                var repulsion = -math.normalizesafe(repulsorPos - t.Value.xy) 
                    / distSqr * repulsionPower;

                //  
                var damping = -velocity.Value * dampingPower;

                acceleration.Value = attraction + repulsion + damping;
            })
            .ScheduleParallel();
    }
}

Rendre

Malgré le nombre potentiellement énorme de particules à afficher, vous pouvez utiliser pour tous le même maillage carré de deux polygones, ainsi que le même matériau, ce qui permettrait de les rendre tous en un seul appel, sinon pour un seul " mais ": toutes les particules, en général, ont des couleurs différentes, sinon l'image résultante sera très ennuyeuse.

Le shader Unity standard «Sprites / Default» peut utiliser l' instance de GPU pour optimiser le rendu des objets avec des sprites et des couleurs inégales, en les combinant en un seul appel de dessin, mais dans ce cas, un lien vers la texture et la couleur de chaque objet spécifique doit être défini à partir d'un script, auquel de ECS, nous n'avons pas accès.

La solution peut être la méthode Graphics.DrawMeshInstanced, qui vous permet de dessiner plusieurs fois un maillage en un seul appel avec des paramètres de matériau différents, en utilisant la même instance de GPU. Cela ressemble à ceci:

[UpdateAfter(typeof(TrsMatrixCalculationSystem))]
public class SpriteSheetRenderer : SystemBase
{
    // DrawMeshInstanced     1023    
    private const int BatchCount = 1023;
    //   
    private readonly List<Matrix4x4> _matrixList = new List<Matrix4x4>(BatchCount);
    //  
    private readonly List<Vector4> _colorList = new List<Vector4>(BatchCount);

    protected override void OnUpdate()
    {
        var materialPropertyBlock = new MaterialPropertyBlock();
        var quadMesh = Globals.Quad;
        var material = Globals.ParticleMaterial;

        //        
        //   
        var shaderPropertyId = Shader.PropertyToID("_Color");

        var entityQuery = GetEntityQuery(typeof(ParticleData));
        //   ,   ParticleData
        var animationData = 
                   entityQuery.ToComponentDataArray<ParticleData>(Allocator.TempJob);
        var layer = LayerMask.NameToLayer("Particles");

        for (int meshCount = 0; 
              meshCount < animationData.Length; 
              meshCount += BatchCount)
        {
            var batchSize = math.min(BatchCount, animationData.Length - meshCount);
            _matrixList.Clear();
            _colorList.Clear();

            for (var i = meshCount; i < meshCount + batchSize; i++)
            {
                _matrixList.Add(animationData[i].matrix);
                _colorList.Add(animationData[i].color);
            }

            materialPropertyBlock.SetVectorArray(shaderPropertyId, _colorList);
            Graphics.DrawMeshInstanced(
                quadMesh,
                0,
                material,
                _matrixList,
                materialPropertyBlock,
                ShadowCastingMode.Off, false, layer);
        }

        animationData.Dispose();
    }
}

Pour rendre un groupe d'objets à l'aide de cette méthode, vous devez collecter un tableau de matrices de transition et les propriétés des matériaux qui sont censées varier. Le système de rendu, comme vous pouvez le voir, est exécuté après le TrsMatrixCalculationSystem - un système auxiliaire qui calcule la matrice de transition pour chacune des particules, ce qui semble très simple:

[UpdateAfter(typeof(MoveSystem))]
public class TrsMatrixCalculationSystem : SystemBase
{
    protected override void OnUpdate()
    {
        //   scale   
        var scale = Globals.SettingsHolder.SettingsModel.ParticlesScale;
        Entities.ForEach((ref ParticleData data, in Translation translation) =>
            {
                data.matrix = Matrix4x4.TRS(translation.Value, Quaternion.identity,
                    new Vector3(scale, scale, scale));
            })
            .ScheduleParallel();
    }
}

Performance

Il est temps de parler de la raison pour laquelle (en plus, bien sûr, de la satisfaction esthétique). Dans Unity, pour le moment, il est possible de choisir entre deux scripts de backend (implémentations CLR ): le bon vieux Mono et une solution plus moderne des développeurs Unity - IL2CPP .

Comparez les performances de génération de ces deux implémentations d'exécution:
Spécifications du PC:
QHD 2560x1440
Intel Core i5-9600K
16 Go de RAM
MSI GeForce RTX 2080 SUPER VENTUS XS OC 8,0 Go


160 000 particules

Il est à noter que, dans cette expérience de vide sphérique, IL2CPP surpasse Mono environ deux fois.

Selon le profileur, littéralement tout le temps passé sur l'image est consacré au système de rendu, les calculs des autres systèmes sont pratiquement «gratuits»:

Unity Editor


Build

Il est à noter que la plupart du temps est consacré au processus de conversion des couleurs de Color en Vector4 et d'ajout à la liste. (). Nous pouvons facilement nous débarrasser de la première - nous reporterons la transformation au moment de la génération des particules, car la couleur ne change pas dans le processus:

// 
public struct ParticleData : IComponentData
{
    public Color color;
    public Matrix4x4 matrix;
}
// 
public struct ParticleData : IComponentData
{
    public Vector4 color;
    public Matrix4x4 matrix;
}

Ce changement nous a permis de nous débarrasser complètement de l'opération de conversion coûteuse: le

nombre d'images par seconde pour 200 000 particules après qu'il soit passé à 61.

Il est possible d'optimiser le remplissage des listes, par exemple, pour stocker tous les tableaux de couleurs, en les générant une fois, mais cette solution ne me semble donc pas élégante, donc Je serai heureux de suggestions constructives dans les commentaires.

Conclusion

ECS en général et Unity DOTS en particulier sont d'excellents outils pour des scénarios et des classes de tâches spécifiques. Ils remplissent leur rôle dans le traitement efficace d'une énorme quantité de données et vous permettent de créer des simulations qui, en leur absence, auraient demandé beaucoup plus d'efforts. Cependant, ne considérez pas DOTS comme une «solution miracle» et jetez des pierres aux développeurs qui adhèrent aux concepts Unity traditionnels dans les nouveaux projets - DOTS n'est pas pour tout le monde et pas pour chaque tâche.

PS

Tout le monde peut se familiariser avec le projet dans mon référentiel github , mais comment installer la build comme fond d'écran sur Wallpaper Engine : lien .