Question

Je conçois mon propre moteur de système de particules, c'est à des fins d'apprentissage, je ne veux pas vraiment utiliser un moteur existant.

En ce moment je généré de belles particules, mais je veux la mise en page du moteur pour le rendre plus facile de travailler avec eux.

J'ai pensé sur une classe « système de particules »,

cette classe contiendrait les références suivantes:

particlesList :. Une liste des particules qui composent le système

systemEmitter : L'émetteur du système pour les particules, la classe de l'émetteur doit être en mesure d'effectuer plusieurs techniques d'émission de particules, comme par exemple, en émettant des lignes, des points, en émettant de façon aléatoire à partir d'un polygone. De plus, cette classe devrait faire des émissions de contrôle, comme émettant vers un point, loin d'un point, dans une direction et le temps d'émettre.

particleController : gère par exemple la rotation autour d'un point, des tailles de particules variables, les couleurs de particules variables, des zones autour du système auquel les particules réagissent de différentes façons, la détection de collision (avec d'autres objets ou à l'intérieur de la si des particules devient necesary).

particules Renderer : En charge de l'élaboration de ce système, les types de Blending variables, des textures de particules, types de particules comme des triangles, cercles, coutume ...

Ces quatre éléments, composeraient la classe système de particules. Certains FX peut nécessiter plus d'un système de particules, par exemple un FX incendie, pourrait utiliser un système pour le feu, un système de fumée et un système d'étincelles.

est ce que j'ai dans mon esprit, mais j'aimerais vraiment savoir si cette approche de conception est bonne, ou si vous voyez que je me manque quelque chose ou pourrait / devrait faire quelque chose de différent. Je n'ai pas pensé à une manière facile de « sauver » FX, comme par exemple ce qui serait la meilleure façon de dire à mon moteur, « attirer le feu », « dessiner explosion », « fontaine dessiner », etc, le stockage peut-être des informations de FX dans des fichiers XML serait une bonne idée, etc ..

Les opinions sont vraiment les bienvenus, et comme je l'ai dit avant, je veux vraiment construire ce, au lieu d'utiliser un autre moteur, pour des raisons d'apprentissage.

Était-ce utile?

La solution

Cette installation devrait être bien. Ce que j'espère que vous pensez à ce que les données constitueront une particule qui sera dans la classe de particules. Vous voulez avoir seulement l'essentiel pour que vous suffit de lire / écrire aussi peu de mémoire que possible lors de l'exécution du système.

En ce qui concerne le rendant guidé par les données qui devraient être assez simple. Je suggère un xml et l'option de format binaire pour le chargement. de sorte que vous pouvez modifier des choses facilement tout en développant (et ne pas avoir un outil). Une fois que vous avez un outil ou avez terminé peaufinage je convertir le XML en binaire pour le chargement rapide.

Vous pouvez également une classe de gestionnaire qui gère la création et la mise à jour de ces systèmes de particules. Cela vous permettra également une place pour gérer d'autres fonctionnalités qui doit faire avec tous vos systèmes. Voici quelques exemples de c'est de limiter la quantité de systèmes de particules ou des particules qui peuvent être gérées pour des raisons de performances ou d'avoir un plan de collision que tous les systèmes doivent prendre en compte.

Vous mentionnez c'est à des fins d'éducation et en ce qui concerne ces choses sont assez pointilleux nit (mais important si vous devez l'utiliser dans un jeu qui est lourd de particules).

Je suppose cela est d'utiliser une API comme DirectX ou OpenGL pour le rendu. À cet égard, je devrais les effets de particules partagent le même pool de mémoire pour vos informations vertex. Cette aide la vitesse de rendu beaucoup. Je voudrais aussi garder la trace d'une limite de la zone affectée par un système de particules pour une utilisation avec frustum culling (AABB ou cercle).

Une grande partie de la mise à jour d'un système de particules est de savoir comment les attributs vont d'une valeur à une autre. Plus dynamique, vous pouvez faire l'interpolation des valeurs plus vos effets peuvent regarder. Il suffit pourrait être une interpolation linéaire assez bon, mais il peut être préférable d'avoir un graphique dynamique qui est utilisé pour les valeurs interpoler. Par exemple au lieu d'aller de 0 à 255 bleu dans une seconde, il peut être cool d'aller 0-128 en 0,2 secondes, puis 128-255 en 0,8 secondes. Ajoutant que augmentera considérablement les options sur la façon dont vos effets ressemblent.

En outre, je pense que vous avez une assez bonne idée de ce que vous voulez faire. Votre mention de rendu différents types de particules me dit que vous pensez à ce sujet dans le droit chemin. J'ai vu des gens faire des moteurs de particules se concentrer uniquement sur le rendu d'un quad billboard. Avoir la possibilité d'émettre la géométrie 3D rend vraiment les choses superbes. Vous pouvez aussi penser (si vous avez pas déjà) ayant la capacité de votre système à prendre des informations de modèle et de diviser de façon dynamique la dans des particules séparées à émettre. En fait exploser un modèle semble beaucoup mieux que l'affichage de certaines particules d'explosion et à la décoloration sur l'objet ou le passage à un état endommagé.

Autres conseils

Juste quelques idées pour l'optimisation des simples, des particules de sprite 2D.

Une bonne idée est d'envoyer toutes les particules dans un tableau de vertex / VBO, et utiliser un vertex shader pour mettre à jour leurs positions au fil du temps. Ceci est très bien si vous avez une motion simple qui peut être facilement décrit en utilisant une formule mathématique où x(t) et y(t) (qui est, ils ne dépendent que du temps).

Une autre grande idée utilise point sprites au lieu des triangles et des quadriceps. Cela devrait réduire la bande passante requise sur le pipeline à un quart.


Dans mon sim espace j'ai mis en œuvre l'approche la plus triviale: les particules envoyées en utilisant quadriceps texture glBegin() / glEnd(). Ils sont jetés dans le « secteur » actuel comme des objets individuels et sont totalement indépendants à partir du moment de dumping partir. Ceci est la chose la plus primitive, stupide et idiot de le faire et est responsable de la grande réduction des performances, d'autant plus que ce que j'itérer à travers des objets via le iterator de vecteur STL et envoyer chacun d'entre eux de manière séquentielle.

Vous devez considérer combien de particules que vous voulez, et qu'est-ce que vous voulez qu'ils fassent. * Est-ce que vous voulez réagir à l'environnement et entrent en collision? Ensuite, vous devez la mise à jour traitées sur CPU et les données envoyées sur et encore. * Est-ce qu'ils volent juste de la manière la plus stupide possible? Ensuite, vous pourrez peut-être sortir avec l'envoi de toutes les particules comme VBO et TBO, et les mettre à jour dans le shader.

Amusez-vous bien!


Mise à jour de rapporter le commentaire n ° 1 de asker: -)

Ce que je voudrais faire est d'utiliser les principe KISS . Cela signifie: une classe appelée ParticleEmitter contenant un tableau de vertex, un tableau de vitesses, et un STL vector avec les instances de collisionneurs simples comme plan, sphère, triangle. En outre, un * STL vector "global" avec collisionneurs. Ensuite, mettre à jour les vitesses selon collisionneurs.

peut être fait avec Affectors similaires (gravité, vent et autres): un autre vecteur STL en ParticleEmitter avec Affectors et un autre STL vector « global » avec Affectors.

Affectors et collisionneurs seraient des classes qui mettraient en œuvre affectParticle(particle_t*). où struct particle_t { float x,y,z; float vx,vy,vz; }. Je garderais une structure POD, et la mise à jour à exécuter ParticleEmitter::update().

Toutefois, si vous utilisez ce sur iPhone, pourrait-il être overcomplication? Peut-être que vous pouvez vous contenter de ce que vous avez déjà mis en œuvre? Je ne sais pas comment ma conception pourrait affecter les résultats de référence, mais il semble assez raisonnable pour moi si vous gardez la particule, collisionneur et affecteur compte à rebours, car il semble que cela pourrait évoluer avec environ n*c+n*a.

Ce ne sont que mes pensées ad hoc, et comment je mettre en œuvre personnellement. Votre conception ou la conception d'autres personnes, seraient probablement mieux: -)

* « Global » en citations, car il serait probablement judicieux d'utiliser un espace de partitionnement que vous avez utilisé.

J'ai mis la même bonne conception pour mon propre moteur en C ++. Je n'ai pas utilisé les références et les modèles de politique (stratégies - lire « Modern C ++ Desing » de Alexandresku) à la place. polymorphisme statique donne de meilleures performances.

Je veux faire quelques commentaires d'après mon expérience.

  1. Traditionnellement, la plupart des particules utilise AOS (Array of Struct) pour stocker les attributs de particules. Mais cela peut ne pas être la meilleure décision. L'utilisation de la SOA (struct Array) représentation vous donnera beaucoup de flexibilité pour ajouter des attributs de chaque système de particules. Et aussi, vous serez beaucoup plus facile d'améliorer les performances avec SIMD avec SOA. Par exemple, en faisant 4 particules ensemble avec des instructions SSE.
  2. position où la particule émet est l'initialisation d'un seul attribut de particules. Lorsque vous émettez des particules, vous avez probablement besoin d'initialiser d'autres attributs, tels que la vie, la vitesse, etc. Vous pouvez abstraite toutes ces caractéristiques comme initializers. Pour la position, vous pouvez avoir un initialiseur disque, boîte initialiseur, etc.
  3. Certains systèmes de particules modernes adopte le concept d'événement. système de particules peut générer des événements (par exemple la pluie entrent en collision avec le terrain) et d'autres systèmes de particules peuvent écouter et effectuer une action (par exemple émettent splash).

Par ailleurs, je pense que la meilleure façon est d'étudier la conception de l'application existante / middleware, et aussi par l'expérimentation.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top