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, j'ai généré de belles particules, mais je veux mettre en place le moteur pour faciliter la tâche de travailler avec eux.
J'ai réfléchi à une classe "Système de particules",
Cette classe contiendrait les références suivantes:
particulesList : une liste des particules qui composent le système.
Systememitter : l'émetteur de système pour les particules, la classe émettrice doit pouvoir effectuer plusieurs techniques d'émission de particules, comme par exemple, émettre des lignes, des points, émettant de manière aléatoire d'un polygone. De plus, cette classe devrait effectuer un contrôle des émissions, comme émettre vers un point, loin d'un point, dans une direction et du temps pour émettre.
Ces quatre éléments, composeraient la classe du système de particules. Certains FX peuvent nécessiter plus d'un système de particules, par exemple un feu FX, pourraient utiliser un système pour le feu, un système de fumée et un système d'étincelles.
C'est ce que j'ai dans mon esprit, mais j'aimerais vraiment savoir si cette approche de conception est bonne, ou si vous voyez, je manque quelque chose ou pourrait / devrait faire quelque chose de différent. Je n'ai pas pensé à un moyen facile de "sauver" FX, comme par exemple quelle serait la meilleure façon de dire à mon moteur "Draquer le feu", "Draw Explosion", "Dessiner la fontaine", etc., peut-être stocker des informations sur FX dans les fichiers XML serait une bonne idée, etc.
Les opinions sont vraiment les bienvenues et, comme je l'ai dit auparavant, je veux vraiment construire cela, au lieu d'utiliser un autre moteur, pour des raisons d'apprentissage.
4 Réponses :
Cette configuration devrait être bien. Ce que j'espère que vous pensez, c'est ce que les données constitueront une particule qui sera dans la classe de particules. Vous ne voudrez que disposer uniquement des éléments essentiels, vous devez donc seulement lire / écrire le moins de mémoire que possible lors de l'exécution du système.
En ce qui concerne les données informatiques axées sur les données qui doivent être assez simples. Je suggérerais une option de format XML et binaire pour le chargement. Donc, vous pouvez modifier facilement des trucs tout en développant (et ne pas avoir d'outil). Une fois que vous avez un outil ou avez-vous fait modifier, je convertirai le XML en binaire pour un chargement rapide.
Vous pouvez également souhaiter une classe de gestionnaire qui gère la création et la mise à jour de ces systèmes de particules. Cela vous permettrait également de gérer une autre fonctionnalité qui a à voir avec tous vos systèmes. Quelques exemples de celles-ci limitent la quantité de systèmes de particules ou de particules pouvant être gérées pour des raisons de performance ou d'avoir un plan de collision que tous les systèmes devraient prendre en compte.
Vous mentionnez que ceci est à des fins de l'éducation et, en ce sens, ces choses sont assez difficiles (mais importantes si vous souhaitez utiliser cela dans un jeu de particules lourdes).
Je suppose que cela utilise une API comme DirectX ou OpenGL pour rendre. À cet égard, je voudrais que les effets de particules partagent tous le même pool de mémoire pour vos informations de sommet. Cela aide beaucoup la vitesse de rendu. Je garderais également une trace d'une limite de la zone touchée par un système de particules à utiliser avec l'abattage de tronc (AABB ou cercle).
Une grande partie de la mise à jour d'un système de particules est la manière dont les attributs vont d'une valeur à une autre. Plus vous pouvez faire la dynamique d'interpoler les valeurs, mieux ce sont les effets. Une interpolation simplement linéairement pourrait être suffisamment bonne, mais il peut être préférable d'avoir un graphique dynamique utilisé pour interpoler les valeurs. Par exemple, au lieu d'aller de 0 à 255 bleu en une seconde, il peut être refroidir de 0 à 128 en 0,2 seconde, puis 128-255 en 0,8 seconde. L'ajout de cela augmentera considérablement les options sur la lecture de vos effets.
En plus de cela, je pense que vous avez une très bonne idée de ce que vous voulez faire. Votre mention de rendu de différents types de particules me dit que vous pensez à cela de la bonne manière. J'ai vu que les gens fabriquent des moteurs de particules qui se concentrent simplement sur le rendu d'un quad paniqué. Avoir la possibilité d'émettre une géométrie 3D fait vraiment fière allure. Vous voudrez peut-être aussi penser à (si vous n'avez pas déjà) avoir la capacité de votre système de prendre des informations du modèle et de les diviser dynamiquement en particules distinctes à émis. En réalité, explosant un modèle semble grandement mieux, puis affichant une particule d'explosion et la décoloration de l'objet ou la commutant à un état endommagé.
Merci pour votre réponse!, Ouais, je pense à rendre cela avec OpenGL. De plus, l'idée d'interpolation non linéaire est vraiment bonne et devrait pouvoir créer de très bons visuels avec elle.
Quelques idées d'optimisation des particules simples, 2D Sprite.
Une bonne idée est d'envoyer toutes les particules d'une graisse Vertex / VBO et d'utiliser un Shader Vertex pour mettre à jour leurs positions au fil du temps. C'est génial si vous avez un mouvement simple qui peut être facilement décrit à l'aide d'une formule mathématique où Une autre bonne idée consiste à utiliser des sprites points au lieu de triangles et de quads. Cela devrait réduire la bande passante requise sur le pipeline à un quart.
Dans mon espace SIM J'ai mis en œuvre l'approche la plus triviale: des particules envoyées sous forme de quads texturés à l'aide de Vous devez déterminer le nombre de particules que vous souhaitez et que voulez-vous qu'ils fassent.
* Voulez-vous qu'ils réagissent aux environnements et à la collision? Ensuite, vous avez besoin de la mise à jour de la CPU et des données envoyées.
* Est-ce qu'ils viennent de voler de la manière la plus stupide possible? Ensuite, vous pourrez peut-être vous en sortir avec toutes les particules sous forme de VBO et TBO, et mettez-les à la mise à jour dans Shader.
amusez-vous!
mis à jour pour se rapporter au commentaire n ° 1 de l'Asker: -)
Ce que je ferais est d'utiliser le Kiss Principe . Cela signifie: une classe appelée Similaire peut être fait avec des affectines (gravité, vent et telle): un autre vecteur stl dans Les affectins et les collidènes seraient des cours qui implémentaient Cependant, si vous exécutez ceci sur iPhone, pourrait-il être surchargé? Peut-être que vous pouvez vous échapper avec ce que vous avez déjà mis en œuvre? Je n'ai aucune idée de la façon dont ma conception pourrait affecter les résultats de référence, mais cela me semble assez raisonnable si vous gardez la particule, le collisionneur et l'affection comptent, car cela sonne comme si cela pourrait être à l'échelle avec environ Ce ne sont que mes pensées ad-hoc et comment je l'appliquerai personnellement. Votre design, ou la conception d'une autre personne, serait probablement meilleure: -)
x (t) et y (t) (c'est-à-dire qu'ils ne dépendent que de temps).
GLBEGIN () / Glend () . Ils sont largués dans le "secteur" actuel comme des objets individuels et sont complètement indépendants de l'heure du dumping. C'est la chose la plus primitive, stupide et idiote à faire et est responsable d'une grande réduction de la performance, d'autant plus que ce que je fais, c'est itérer à travers des objets via Itérateur de vecteur stl et envoyez chacun d'eux séquentiellement.
Particleemitter contenant un tableau de vertex, une gamme de vitesses et un vecteur stl avec des instances de collidènes simples tels que plan, sphère, triangle. En outre, avoir un «code global» * stl vecteur avec des collidènes. Puis mettez à jour les vitesses selon les collidènes.
Particleemitter avec des affectins et une autre "code global" stl vecteur avec des affectins.
affectantparticules (particules_t *) . où struct partile_t {float x, y, z; flotteur VX, VY, VZ; } . Je conserverais une structure de pod et exécutez la mise à jour dans ParticleMitter :: Mise à jour () .
N * C + N * A .
* "global" sous des citations, car il serait probablement logique d'utiliser n'importe quel partitionnement de l'espace que vous avez utilisé.
Bonjour Ivan, merci pour la réponse, je développe actuellement ce système sur l'iPhone, j'ai fait de bons progrès, car j'ai atteint mon jalon sur le rendu 3.000 16x16 pixels GL_POINT_SPRITES, en utilisant des VBO et réalisez entre 45 et 55 fps. Je pense que c'est assez décent. Cependant, je veux maintenant commencer à travailler sur la manière dont les particules peuvent interagir et entrer en collision avec d'autres objets, ont réfléchi à certains égards, mais j'aimerais vraiment entendre parler de quelques idées à ce sujet. Merci encore.
J'ai mis en place la même bonne conception pour mon propre moteur en C ++. Je n'ai pas utilisé de références et de stratégies de modèles (Stratégies - Lisez à la place «la découverte C ++ moderne» de Alexandresku). Le polymorphisme statique donne une meilleure performance.
Je veux faire quelques commentaires en fonction de mon expérience.
Au fait, je pense que le meilleur moyen consiste à étudier la conception des applications / middleware existantes, ainsi que par expérimentation.