96 lines
3.1 KiB
Markdown
96 lines
3.1 KiB
Markdown
# BloubWorld
|
|
|
|
C'est quoi ?
|
|
|
|
Le BloubWorld (que l'on appelle aussi BloubSpace) est un espace borné
|
|
dans lequel se déplacent des **bloubs**, lesquels sont
|
|
des sortes de particule
|
|
munie de certaines propriétés (age, grosseur, vitesses, etc...).
|
|
Lesquelles valeurs peuvent évoluer en fonction du temps.
|
|
|
|
## Description d'un bloub
|
|
|
|
Attention cette description n'est qu'un exemple, mais les points
|
|
essentiels de la première étape sont là.
|
|
Les caractériques dynamiques : position et vélocités.
|
|
Coté physique : l'age en bloubcycle (avec un maximum), la taille,
|
|
un petit nom, et un état (coucou la FSM).
|
|
|
|
|
|
```
|
|
type t_bloubs
|
|
character(8) :: nick
|
|
logical :: alive
|
|
integer :: state
|
|
integer :: num ! ???
|
|
real :: px, py, pz
|
|
real :: vx, vy, vz
|
|
real :: radius
|
|
integer :: age, agemax
|
|
end type t_bloubs
|
|
```
|
|
|
|
C'est (preseque) simple, en fait.
|
|
Le plus compliqué, c'est de savoir quoi faire de ce fatras
|
|
de *bigdata*.
|
|
|
|
On peut fabriquer des gazillions de bloubs, et ensuite
|
|
les lacher dans un espace clôt, avec des parois
|
|
rebondissantes. Chaque choc va un peu les user, et au bout d'un moment,
|
|
ils vont mourir. C'est comme ça, c'est la vie des bloubs.
|
|
|
|
## Comment ça fonctionne ?
|
|
|
|
Pas trop mal pour un premier jet. Il suffit de lire
|
|
le script `runme.sh` pour avoir une idée de l'enchainement
|
|
des opérations. Lequel enchainement est décrit plus bas.
|
|
|
|
## Les logiciels
|
|
|
|
Pour le moment, l'ensemble des opérations est gérée par un script shell
|
|
qui enchaine des opérations plus élémentaires. Oui, je sais, ce n'est
|
|
pas optimal, mais c'est un cadre idéal pour les bricolages hasardeux.
|
|
|
|
Ces opérations agissent sur des fichiers de type `.blbs` qui sont,
|
|
vu du fortran, des dumps séquentiels du type t_bloubs. Un format
|
|
de fichier qui va être modifié assez souvent, ne gardez pas d'archives.
|
|
|
|
### genbloubs
|
|
|
|
Fabrication d'une population de bloubs plus ou moins aléatoires.
|
|
Deux paramètres : le nom du fichier et le nombre de bloubs.
|
|
Les règles de génération *devraient* être paramétrables.
|
|
|
|
### movebloubs
|
|
|
|
Le cœur actif du système : c'est lui qui, à chaque tick, va déplacer
|
|
les bloubs, gérer les rebonds avec la boudary-box, éliminer les
|
|
bloubs usés par les chocs, et faire naitre de nouveaux bloubs
|
|
si le besoin s'en fait sentir.
|
|
|
|
Seul problème, il n'a pas de notion directe du temps, parce qu'il est
|
|
juste de passage dans un pipeline.
|
|
|
|
### exportbloubs
|
|
|
|
Sortie sur `stdout` de certaines propriétes des bloubs, qui seront
|
|
reprise par un (ou des) scripts écrits en `awk`, afin de générer
|
|
ce qu'il faut pour les différents moteurs de rendu.
|
|
**Le format de sortie est susceptible de changer sans préavis.**
|
|
|
|
Bon, pour le moment, il n'y a que POVray, mais Gnuplot arrivera en second.
|
|
|
|
### mergebloubs
|
|
|
|
Alors, celui-ci, il n'est pas vraiment au point. Il faut tout ré-écrire
|
|
et faire gaffe à l'explosion quadratique.
|
|
|
|
## TODO
|
|
|
|
- Concevoir un système de _bouding box_ facile à utiliser
|
|
- Réfléchir à une politique de vieillissement des bloubs
|
|
- le `merge` de deux bloubs est-il un acte politique ?
|
|
|
|
|
|
|