Représentation dynamique de points à l'écran

[Solitonique]

Bonjour,
J'aurais besoin d'un conseil de la part de quelqu'un qui a déjà eu à régler ce genre de problème :
J'aimerais développer un programme pour visualiser les interactions à distance entre plusieurs points.

Par exemple imaginez des points disposés sur un plan dont le mouvement dépend de la position des autres points.
(L'interaction entre point A et point B sera décrite par une fonction dont un des paramètres est la distance entre ces 2 points.)
Le seul langage que je connaisse permettant de faire cela est le javascript, mais ce serait trop lent je suppose dès que la population de points augmente.

Peut-être un logiciel mathématique qui offrirait la possibilité d'écrire des macros pour arriver à ce résultat ?

Sinon je peux découper le problème en 2 phases. Phase 1 je calcule toutes les positions successives dans le temps, phase 2 je les affiche successivement à l'écran pour en voir le mouvement. Dans ce cas un logiciel permettant d'afficher dynamiquement des points en lisant séquentiellement un fichier avec les coordonnées suffirait.

Merci d'avance pour toute suggestion.
-----

[azad]

Salut
Pas évident !
Avec deux points ça peut aller, déjà trois ça pose quelques problèmes. Au delà c'est la folie. Même en utilisant une loi simple (genre loi de Newton) il faut prendre en compte les coordonnées de chacun des points, les masses de chacun d'eux et les conditions initiales (vitesse, direction). Pour commencer avec seulement trois points essaies de calculer la fonction décrivant les variations du barycentre du système et tu verras que ça n'est pas évident. Je m'étais risqué à la chose avec Mathematica et trois points, un gros central et deux satellites et le jeu consistait à satelliser les deux petits autour du centre en jouant sur les conditions initiales. Ca marchait, mais ce n'était probablement pas une simulation très fidèle.
Tu peux simplifier (peut-être) un peu la chose en donnant la même masse à chacun des points, une vitesse nulle à chacun d'eux, mais cet état ne va durer que pour le premier pas de ta simulation, ensuite tu vas être confronté aux lois de la thermodynamique et même dans un espace à deux dimensions, c'est difficile à gérer. Bon courage.
Sinon, je crois savoir qu'il existe dans Maple un module de simulation et d'animation, des lois de la gravitation qui permet cela avec un nombre de particules arbitraire.

[Paraboloide_Hyperbolique]

Bonjour,

Il y a en effet deux "grands" problèmes différents:

1: les instabilités numériques qui peuvent apparaître du fait de la discrétisation des équations considérées. Par exemple, avec la loi de gravitation de Newton le modèle peut "exploser" si deux corps passent trop près l'un de l'autre et que le pas de temps est trop grand. Une solution est de choisir un pas de temps adaptatif et de considérer qu'il y a "collision" en-deçà d'une certaine distance entre deux points.

2: calculer les interactions entre un grand nombre de points. Pour n points, il y a de l'ordre de n² interactions. Cela peut vite devenir ingérable. Une solution est de construire une liste des points "voisins" d'un point et d'ignorer les interactions avec les points "non-voisins" (si cela est possible).

[Solitonique]

Non, je ne cherche pas à simuler un problème de gravitation à N corps. C'est beaucoup plus simple. Et dans mon cas l'accumulation d'erreurs à chaque itération n'est pas grave, il s'agit juste d'avoir une idée du mouvement général.

Et les points ne sont pas dépendants de tous les autres mais seulement de certains : çà simplifie

Mon vrai problème pour le moment est de pouvoir visualiser à l'écran, de façon assez fluide, le mouvement des points.

[A voir en vidéo sur Futura]

[Paraboloide_Hyperbolique]

Bonsoir,

A priori, j'utiliserais Matlab (ou son équivalent gratuit: Octave) qui permettent de réaliser simplement un affichage à l'écran. Sans plus de détails sur ce que vous souhaitez simuler, je ne peux pas beaucoup plus vous aider.

[Solitonique]

Merci beaucoup, j'irai voir...

[galerien69]

ben avant de passer à matlab/octave, faut voir combien t'as de point et à quoi ressemble ta fonction que t'appliques sur les points (et leur voisinage?).
Et faut aussi voir c'est quoi la cadence de rafraichissage.

Parce que ca se fait js c'est amplement suffisant. Je te laisse regarder quelques demo avec le webgl

[Solitonique]

Je regarde aussi HTML5 Canvas.
http://www.html5canvastutorials.com/
La population de points n'est pas énorme pour commencer (une dizaine de points) après je verrai.
La fonction à appliquer à chaque point fera un peu de trigonométrie, ce qui est consommateur de ressources, mais çà devrait passer.

J'ai regardé les démos de webgl sous les conseils de Galerien69, je suis bluffé ! Faut que je regarde tout çà de plus près çà m'a l'air très intéressant ! ^^
https://developer.mozilla.org/fr/demos/tag/tech:webgl

Merci à tous pour vos conseils.

[obi76]

Bonjour,

Avec deux points ça peut aller, déjà trois ça pose quelques problèmes. Au delà c'est la folie.

N'exagérons rien, c'est un algorithme de complexité 2 si il est codé de la manière la plus simple qui soit (i.e. lister tous les couples de points possibles), mais à mon avis on peut facilement arriver à la centaine de points (à peu près 5 000 interactions à calculer) sans trop de problème, au bout d'un moment ça va coincer c'est sur... mais pas avec 3 !

[azad]

C'est vrai que j'exagère un peu, mais si l'on veut une animation un peu réaliste, on doit prendre un incrément de la variable "temps" très petit, ce qui bien entendu ne change rien à l'algorithme utilisé, mais augmente assez vite les temps de calculs. D'autant que parfois apparaissent des singularités, par exemple si deux points sont très proches, voire en contact, ce qui donne aux variables des valeurs hors limites. En fin de compte quand on s'attaque à ce genre de problème, on fini toujours par adopter des simplifications qui nous font prendre conscience des limitations de notre modèle…. et l'on baisse les bras.
Mais enfin, cela fait plaisir de voir qu'il existe des gens qui reprennent le flambeau.

[Xoxopixo]

Bonjour,

C'est vrai que j'exagère un peu, mais si l'on veut une animation un peu réaliste, on doit prendre un incrément de la variable "temps" très petit, ce qui bien entendu ne change rien à l'algorithme utilisé, mais augmente assez vite les temps de calculs.

Prendre un incrément très petit, à priori, ne règle pas le problème et ralenti fortement la simulation.
Le problème vient du fait qu'on prenne des "points" et donc qu'il est possible que des points s'approchent les uns des autres jusqu'à une distance quasi nulle, voir nulle, produisant des "singularités".

Il vaut donc mieux définir un "rayon" pour les points (et définir ce qui se passe lorsqu'il y a collision), et diminuer/augmenter l'incrément temporel de manière adaptative.

[obi76]

Il vaut donc mieux définir un "rayon" pour les points (et définir ce qui se passe lorsqu'il y a collision), et diminuer/augmenter l'incrément temporel de manière adaptative.

ou beaucoup plus simple : maximiser la distance lors du calcul de l'interaction, de sorte qu'elle soit toujours supérieure à un epsilon fixé arbitrairement.

Quant à avoir une animation fluide... il suffit de pouvoir le faire 50 fois par seconde, ce qui revient à 250 000 calculs d'interaction par seconde. Un calcul d'interaction se réduisant à quatre produits, une somme, une division, il va sans dire que tout processeur digne de ce nom peut LARGEMENT suffire à cela.