Site de Sylvain Petitgrand


I\ Contenu

Mes programmes se trouvent pour l'instant sur la page de mon frère (c'est quelque peu mélangé). Il y a 70% de C 10% d'assembleur et 20% de Visual Basic.
Les sujets abordés sont :

  • La simulation thermique (aux différences finies)


  • La simulation optique (fronts d'onde dans des fibres, des lentilles, sur des miroirs de forme quelconque)
    C'est une simulation en 2D simplifiée de la propagation des ondes electromagnétique dans un milieu d'indice variable. On dessine ses composant optiques dans un logiciel de dessin (les nuances de bleu correspondent aux variations d'indice). Un exemple se trouve dans la (gallerie d'images - Divers)


  • La simulation atomique:
    Cela met en évidence les phénomènes liés aux migrations des dislocations, à l'évaporation/condensation, ainsi que les effet de désaccord de maille, les effets élastiques, la dilatation, ... . Le point que je trouve intéressant c'est la diversité des phénomènes physiques qui se manifestent. La simulation utilise une seule équation fondamentale, un potentiel de type Lennard-Jones, et la matière et ses propriétés apparaît.
    Les développements envisagés sont d'appliquer ce type de simulation aux interactions de spin pour simuler les comportements ferromagnétiques ou paramagnétiques en agissant sur la portée et le signe de l'interaction.
    Ces simulations ont définitivement une limitation liée au nombre de particules et d'interactions à traiter, et je ne vois pas dans l'évolution prévue des puissances de calcul comment passer de la simulation 2D de 50x50 atomes avec 25 images/secondes à la simulation 3D d'un volume macroscopique de matière. En l'état actuel des choses j'arrive à calculer l'équivalent de ((50x50 atomes)x(50x50 atomes - 1)/2)x(25 images/seconde) = 78 millions d'interactions par seconde ( seule la partie sigificative de ces 78 000 000, correspondant à une distance interatomique inférieure à la distance d'évanouissement du potentiel d'interaction, est calculée, car je n'ai 'que' 1 400 millions de cycles d'horloge par seconde, et le calcul complet correspond à des milliers de cycles par interaction). Pour cela l'espace 2D est découpé en zones de dimensions caractéristiques de la distance d'interaction maximale, et les interactions ne sont calculées qu'entre un atome d'une zone donnée et chacun de ses voisins appartenant à l'une des 3x3 zones les plus proches. Un exemple se trouve dans la (gallerie d'images - Divers)

  • Dans tous les cas ces simulations donnent un affichage animé de la situation et de son évolution à des fins pédagogiques.

  • Le raccord d'images automatique, pour faire des panoramas à partir de vidéos ou de photos chevauchantes
    C'est une de mes activités actuelles, après m'être intéressé à l'exploitation de la redondance d'images pour améliorer la résolution spatiale. J'avais déjà réalisé des expériences quand j'avais raccordé les photos prises d'avion (voir la gallerie d'images - Divers)


  • Le traitement du son : Par exemple le changement de la hauteur sans changer la longueur d'un morceau, et réciproquement, ce qui permet de changer le tempo, ou la voix d'un homme en femme ou en hippopotame, et réciproquement.


  • La compression du son : j'ai réalisé un compresseur basé grosso modo sur la discrétisation des coefficients de la TF du signal. Il est plus rapide que la compression/décompression en MP3 (le lecteur utilise moins de CPU que Winamp), la contrepartie et un taux de compression de 6.7 au lieu de 11 pour le MP3. J'ai réalisé par la suite un Input Plug-In pour Winamp qui permet de lire mes fichiers avec Winamp. Ensuite j'ai fais un PlugIn graphique, un feu d'artifice synchronisé avec la musique (voir la gallerie d'images - Divers)


  • La compression vidéo : j'ai réalisé un compresseur basé sur une discrétisation grossière des couleurs associée à un filtrage non linéaire préservant les contour. C'est rapide et surtout ca ne fait que 200 lignes en C. Le taux de compression n'est pas terrible (x4) quand on filme un panorama, par contre si la caméra est fixe et filme des mouvements dans une scène on atteint 200. C'est une évolution de ce que j'avais fait pour tranférer l'interface des programme dans le cadre du contôle à distance par réseau. Je l'applique à un petit appareil photo numérique qui fonctionne en WebCam (je récupère les images par l'interface VidéoForWindows)


  • Les fractales, passage obligé quand on programme ... Mon programme est animé : On passe continument d'un type de fractale à un autre en fonction de la position de la souris. On peut sauvegarder l'image en bitmap jusqu'à des résolutions 16384x12288x256 (Cela permet de changer la palette de couleur après coup, pour l'adapter à son goût sans avoir à recalculer). Accessoirement on connait le nombre de tops par instruction suivant les types de processeurs. La boucle de calcul est en assembleur, tout dans les registres du copro et sans acces mémoire durant le calcul d'un pixel.
    La cadence varie de 10fps à 0.2fps suivant la compexité du fractale affiché en 1024x768x24 bits


  • Un jeu de voitures en Visual Basic (Le moteur 3D était toutefois en assembleur pour des raisons évidentes). Visual Basic 5 compilé offre des performances tout à fais satisfaisantes pour ce qui est des calculs en virgule flottante (pour les opération graphiques rien ne vaut l'assembleur). De plus la possibilité d'interfacer Direct3D rend ce langage tout à fait viable à l'avenir pour de telles réalisations.
    Le terrain était dessiné dans un grand bitmap 8192x6144 qui servait de texture du sol, avec des bitmaps en niveaux de gris plus petits pour les élévations, les lignes de chronométrage, les variations d'adhérence, ...
    On peut jouer en réseau par modem, et par port série ou parallèle. L'IA est gérée et pilote de facon évolutive jusqu'à la limite de la sortie de piste pour des courses spectaculaires. Les points à améliorer sont le moteur physique qui est purement phénoménologique, l'IA qui est un grand cas-par-cas anticipé et pondéré, et la génération de la piste qui est limitée en surface et en résolution spatiale (pas de vibreurs par exemple) (voir la gallerie d'images - 3D)


  • Un jeu de voitures en C qui tire parti des enseignements du précédent. La technique est meilleure, mon frère développe l'interface OpenGL, et j'ai réalisé le générateur de piste en 3D avec bacs à sable, vibreurs, différentes textures de piste. Mais le temps nous manque ... (et moi je dois rédiger ma thèse) (voir la gallerie d'images - 3D)


  • Et mon plus gros projet, une librairie en C qui contient :

  • Un moteur 3D en C (8, 16, 24, et 32 bits avec gestion des textures, des objets 3D, de la lumière et du brouillard). J'ai mis le moins d'assembleur possible, et on peut configurer pour ne pas utiliser du tout d'assembleur. Le but est de montrer que la puissance des processeur croit suffisemment vite pour ne pas avoir besoin de carte accélérée pour la 3D relativement sobre (je ne parle pas de 3D comme dans Quake3D ou il y a simultanément fumée, lumière, transparence et bilinéar, qui sont définitivement une trop lourde charge pour les moteurs software).
    Le choix est de travailler sans Z-Buffer, en réutilisant au maximum le résultat du tri de l'image précédente. En restant assez bas niveau le C est aussi performant que l'assembleur. Le moteur software prend l'avantage sur l'accélération 3D en particulier lorsqu'un grand nombre de faces doit être affiché (comparaison effectuée sur une carte sans Transform and Lightning). C'est avantageux pour les représentations 3D de surfaces mesurées en profilométrie optique et AFM contenant typiquement 768x576 faces, qui sont des applications majeures de cette librairie.


  • Une gestion du son (directX)


  • FFT, filtrage numerique, discrétiation


  • Buffering (Ring buffer, buffer disque, buffer de bits ...)


  • Interfaces graphiques


  • Interfaces réseau (UDP, SMTP, POP3, FTP, contrôle à distance)


  • Gestionnaires de mémoire et des outils de chronométrage spécifiquement pour le débogage et l'optimisation