Discussion :

[Clad3]

Dans ce cas, en effet c'est plus simple de fixé le FadeTime et de changer le LifeTime au depart ( pour la compréhention )

Pour le moment :
A chaque création de particule : je met son LT ( lifetime ) a 1
je met son FT a x + rand()
A chque frame je fait : LT = LT - FT
A chaque renaissance de particule je fait LT = 1 ( je laisse le FT tel quel )


Toi tu me propose :
A chaque création de particule : je met son LT a 1 + rand()
( pas de var menbre FT )
A chque frame je fait : LT = LT - LT*(time_elpased)
A chaque renaissance de particule je ne fait rien

On gagne en effet quelques opération ( mais j'ai constaté que ces opération ne sont pas du tout limitatrice en terme de vitesse d'éxé . [ enfin pour le moment j'ai des choses bien plus gourmandes a régler ; mais peut-etre plutart je m'attarderai dessus ] ).

Enfin et surtout : LT = LT - LT*(time_elpased) , ca donne a mes particules une durée de vie identique ... ce n'est pas ce que je veux dans le cas présent ; de plus ca leur donne en durée de vie quasi infini si je me trompe pas ...
ex : une fois le LT arrivé a 0.1

LT = 01 - 01*0.0002 ... c'est pas gagné pour atteindre le zéro

En bref, je n'ai pas de controle sur la durée de vie de mes particules :/


Enfin je suis septique , mais il se peut que je m'y prenne mal

Ce qui me retient en ce moment , c'est le lien entre

le nombre de particules
le time_elpased
le temps de vie d'une particule ( lié au LT et au FT )

-> le nbre de particule a généré au départ lors de la phase d'ini .

Je pense aussi qu'il me manque des donnée quantitative ( a trouver moi meme ) du style, je veut que chaque particule vive X sec environ , quelle se déplace sur Y pixel ect ...

Bon j'y retourne car je commence a plus trop savoir ce que je dit

merci en tout cas de te pencher avec moi la dessus

[Clad3]

Re
Petits ajout :

J'ai revu un peu beaucoup ma facons de calculer les vitesse de aprticules , avant j'avais choisit de se baser en pixel / ( frame ? ) ou un equivalent en Delta ( ne me demandez pas pourquoi j'avais procédé comme ca ... dans ma tête ca paraissait jolie :p ) .
Je suis passé maintenant a des vitesse en pixel / seconde .
Ca donne de bon résultat , par contre juste un petit pb , je ne suis pas certain que ca donne le résultat attendu en cas en CPU trop lent .

EX :

sur 60.000 particules , j'ai mis 1000 px / seconde ; et je constate nettement que la vitesse n'est pas au rendez-vous ( je sais que ca ne doit aps être fluide, faut pas rêver ; mais le but du time-based-modelling est quand même de gérer ces situations la, non ? ) ...

ma formule est la suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
	// MAJ de la position .
	cVector2D speed_timed ;
	speed_timed.X =  AllParticles[rang].Vitesse.X *(cInputManager::GetInstance().time_elapsed / 1000 ) ;
	speed_timed.Y =  AllParticles[rang].Vitesse.Y *(cInputManager::GetInstance().time_elapsed / 1000 ) ;
	AllParticles[rang].Position = AllParticles[rang].Position + speed_timed ;
	AllParticles[rang].Vitesse = AllParticles[rang].Vitesse + AirGravitation    ;

AllParticles[rang] est la particules qu'il faut MAJ
AirGravitation est un vecteur représentant la gravitation ( 0, -0.5 )
speed_timed est le vecteur représentant le mouvement déduit en fonction du framerate et du mouvement en px/sec contenus dans un vecteur Vitesse ( objet menbre de cahque particule ).

Je ne vois pas ce qui cloche

[:Bronsky:]

Pour le lifetime je n'avais pas vu ça comme ça. En effet ta méthode n'est pas moins performante car tu fais bien un seul random() pour toute la vie de la particule, et pas un à chaque frame.

Dans ta description de ma méthode, la formule LT = LT - LT*(time_elpased) est fausse, je ne comprend pas pourquoi tu multiplie ton time_elapsed par LT (ce qui provoque le pb dont tu parle après). La formule est simplement : LT = LT - time_elpased.
De plus, je pense que tu devrais utiliser 2 variables pour que le problème soit plus clair : une variable lifetime qui est constante, une variable age qui commence à 0 pour rejoindre lifetime. Dans ce cas, à chaque frame, age += time_elapsed et la particule meurt quand age >= lifetime. Là tout le monde comprend en un clin d'oeil.
Ou alors si tu tiens à garder ton approche, renomme "lifetime" en "timeRemaining" ou "lifeRemaining", c'est plus proche de l'utilisation que tu en fais.


Pour ton problème de vitesse, tes formules ont l'air bonnes (enfin presque... cf juste après). Es tu sûr de constater une baisse de vitesse ? C'est très subjectif parfois, une perte de fluidité peut donner l'impression d'une perte de vitesse alors qu'il n'en est rien.

Cela dit, avec ces formules, le résultat n'est pas tout à fait le même selon la machine. En effet, elle sont exactes si l'ont part du principe que la vitesse est constante entre chaque frame. Or, si tes particules ont une accélération (c'est le cas apparemment ici puisqu'il y a une gravitation), tu es bien d'accord que la particule, entre 2 frames, n'aura pas une vitesse constante. En gros tes formules consistent juste à dire "au point A ma vitesse était x, au point B elle est devenue x+accélération", comme si la vitesse avait augmenté d'un seul coup en arrivant à B, alors qu'elle a augmenté progressivement au cours du frame. Bien que tu ne vois évidemment pas ce qui se passe entre 2 frames, et bien cette constatation a quand même une influence sur la position de ton objet à la fin du frame, et ça il faut le prendre en compte pour être absolument exact. La seule solution pour se tirer de ce problème est de passer par un vrai calcul mathématique de la position de la particule à un instant t en fonction de sa vitesse et de son accélération. Rappelle-toi : la position est l'intégrale de la vitesse, qui est elle-même l'intégrale de l'accélération. La position est donc finalement l'intégrale double de l'accélération. Allez je te donne le résultat , c'est :
positionActuelle + (acceleration*time_elapsed*time_elapsed)/2.f + vitesse*time_elapsed

Donc à chaque frame on doit recalculer la position ainsi :
position += (acceleration*time_elapsed*time_elapsed)/2.f + vitesse*time_elapsed

Essai d'intégrer ça dans tes formules, afin d'avoir une position qui soit réellement fonction de la vitesse et de l'accélération (ici : ta gravitation) et là ton résultat sera vraiment identique sur toutes les machines. Personnellement, j'avais eu ce problème dans mon moteur, quand j'avais voulu donner à mes objets des effets d'inertie : la vitesse globale était la même entre les machines, mais plus la machine était lente plus l'inertie était importante. C'était donc bien un problème d'accélération, et ça s'est résolu tout de suite en calculant la position de façon mathématique.

Pour le calcul de la nouvelle vitesse ne change rien, là c'est exact : tu ne le sais peut etre pas mais ta formule correspond bien à l'intégrale de l'accélération (si on suppose que celle-ci est constante héhé )

[:Bronsky:]

Ooooops non non ta formule de calcul de la vitesse est fausse aussi.... elle ne prend pas en compte le time_elapsed. Si time_elapsed est exprimé en secondes, la vitesse en pixels/secondes et l'accélération (la gravitation) en pixels/secondes², la vitesse est mise à jour ainsi :

vitesse += gravitation*time_elapsed

En fait maintenant que j'y pense je crois que c ça ton problème principal. Fais déjà ça et tu aura bien déblayer le terrain. Ensuite l'intégrale double pour la position, c'est du réglage fin

[Clad3]

Me revoili

Concernant l'ambiguité du nom de mes variable , c'est noté j'y remedirai lors de la création de l'engin final .

Ensuite si j'ai bien comprit , mon pb est que sur une machine lente ; je ne tient pas compte du time_elapsed pour pondéré la modification du a la gravité a chaque frame , c'est cela ?

Si j'ai bien suivit, c'est également ce que tu redit dans ton 2eme post non ?

Rappelle-toi : la position est l'intégrale de la vitesse, qui est elle-même l'intégrale de l'accélération. La position est donc finalement l'intégrale double de l'accélération. Allez je te donne le résultat , c'est :
positionActuelle + (acceleration*time_elapsed*time_elapsed)/2.f + vitesse*time_elapsed

Houla ;o) souvenirs souvenirs ;o)

[Clad3]

Petite note :

J'ai modifié comme tu me la conseilé ma formule de vitesse ( en pondérant la gravitation avec le time_elapsed ) . Ce n'est aps encore au point car je n'ai asp trouvé la bonne valeur de gravitation ... mais la n'est pas le probléme . Soit c'est un pb uniquement lié a cette modification ( mais je doute ) ca fait resssortir un pb global je pense ; ma phase d'initialisation n'est pas bonne du tout on dirai .

Ci-joint un exemple : le jet prend sa forme définitive ( un truc tout faible avec une gravité énorme ) ; et il subsite toujorus une phase initiale .... pourquoi ?

http://max.cat.free.fr/Init.zip

edit : echap , pour quiter l'aplication .
ca pique les yeux car je n'ai inclu la texture utilisé .

[pascal_damien]

Salut,


Ca n'a pas l'air mal, mais en effet au début, il semblerait que le débit soit un peu trop important. Ca vient peut-être du début difficile de time_elapsed à zéro (au fait tu l'initialises à zéro ? ; tu pourrais essayer avec une valeur un peu plus grande pour voir, genre celle que tu obtients lorsque le débit est régulier).

[bafman]

le probleme vient tout simplement du fait que sur un moteur de particules il faut limiter le nombre maximum de créeation de particules a chaque secondes.

par exemple en limitant a 20 particules initialisée par seconde, ca devrait resoudre ton problem... ainsi tu n'aura plus l'ensemble des particules initialisée a la même frame.

un conseil supplementaire (c'est gratuit profitez en ) : commence toujours avec une limitation des particule forte (genre 1 particule par seconde) puis augmente ensuite, jusqu'a obtenir l'effet voulu...

[Clad3]

@pascal_damien , si le pb venais de la, ca ne se verrai pas ( 1 frame ) ; la phase "initiale" dure un bon pacquet de frame ; le pb est donc autre part je pense

@bafman , heu sauf erreur de ma part je n'initilise pas tout a la même frame . ( je n'ai pas encore trouvé la formule parfaite dunbre de aprticule /frame pendant l'ini mais j'ai une valeur genre 2/frame ... )

[bafman]

et combient de temps fait une frame dans l'absolue
il ne faut pas se baser pas frame mais par secondes... si ton moteur tourne a 500 fps ca reveindra au même pour l'oeil de les faire apparaitre en même temps ou a quelques frames de differences...

[Clad3]

Merci, j'ai corrigé de probléme , tout est exprimé en pixel / second et plus en pixel / frame

Mais ca me laisse toujours le probléme du début :/
j'ai beua chercher, je ne vois pas pourquoi j'ai une phase transitoire .
On dirai que la gravitation n'est pas apppliqué durant cette phase ... sans raison apparente , si quelqun a une idée ... merci

edit: Oh ! j'ai une erreur bizzare , dans une fonction d'initialisation ( quanbd mon prog se lance ) j'ai voulu placer un "Sleep(3000) " pour voir si mon time_elpased ne deconnait pas durant les premiére frame ... et ca a pour effet de ... hue je ne sais pas ; mais plus ne saffiche dans mon prog ; alors que un sleep(1) passe bien ; et que ce n'est pas une boucle; mais juste un endroit qui est effectué une fois ou se trouve mon sleep() ) ..
sleep() est il buggé ?

edit 2: ...les joie de la progra :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
a = a + b*c

-> plante ( en simplifiant )

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
d = b*c
a = a + d

-> marche

..enfin bref, je retourne a mon pb, qui ne semble aps du a un mauvais fonctionement de mon time_elapsed .

[Clad3]

Je crois voir le problème ( mais pas la facons de le régler ;o )

J'ai afficher pour une particule donnée , la valeur de la force de gravitation a chaque frame .
Celle-ci est environ 10 fois + faible durant la phase d'initialisation .
Elle va augmenter car le frame-rate va chuter ( car le nbre de particule va augmneter jusqu'à culminer a 6000 ) .

Comment puis-je contourner le pb ?

[bafman]

attention, il ne faut pas oublier que durant la premiere frame de simulation, le temps ecoulé doit etre de 0, sinon ton timer risque de t'envoyer des valeurs de temps bizzard etant donnée qu'il n'a pas encore été utilisé...

[Clad3]

Mon timer fonctionne bien , il me renvoie qquchose genre 3 ms lors de la premiére itération de génération des particules .
Le pb ne veint pas de la premier frame, mais d'une phase entiére ( un bon paquet de frame ) ... et je suis dans le flou :/

[Clad3]

Hum ca commence a sentir le tournage en rond :p
je suis a la recherche de nouvelle piste j'attend aussi les votre

edit: aprés un petit test , j'ai constaté que : si mes fps ne chute pas ( ex avec 60 particule, et non 6000 ), l'animation est fluide / sans phase de transition ( visible , donc pas sur ) et la gravité na PAS le meme effet que avec 6000 particule .. il y a donc un pb qqupart :/ mais "where?"

[bafman]

tu ajoute bien la gravitée en fonction du temps ? du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
newPos = pos + (gravité * elapsedTime)

[Clad3]

rho et mince c'est encore ma faute :/ j'ai oublié de précisé hier soir, j'ai trouvé la solution, en fait c'était un petit pb de ma classe vecteur 2D , j'aivas oublié une ou deux surcharge d'opérateur avec certain type, et ca compilais mais ne donnias pas les résultat attendu . ( en gros je lui donnais des doubl et il récupérait des int ... )

Tout semble allez bien ; je ne constate plus de phase d'initialisation ... je peut me lancer pour commencer dans une optimistion de l'affichage de mes quad ( display list pour commencer) ... Enfin bref merci a tous ...et ce n'est que le début ^^ j'ai du pain sur la planche maintenant lol

[bafman]

attention, les display liste ne sont utilisables que si tu affiche toute les particules d'un coup (donc pas de particules morte) ou si elle sont triée morte/pas mortes (tu peut aussi utiliser un tableau d'index mais c'est du boulot pour pas grand chose...)
le mieux au niveau optimisation est d'utiliser les point_sprite et point parameter qui permettent de n'envoyer qu'un point par particule...

[Clad3]

Merci du conseil, je vais me renseigner la dessus

[bafman]

mmm j'ai un gros doute sur ce que j'ai dit plus haut... en fait je ne parlait pas des display listes mais des vertex array... pour les display list, c'est encore pire,tu perd toute possibilitée de modifier la geometrie, donc c'est inutilisable pour un moteur de particules en perpetuel mouvement...