gem-graph-client/TODO (next version).txt

L'utilisation d'OpenGL fait que la première version de Gem-graph sera tout naturellement en 3D. Le modèle de marche aléatoire de dimères sera aussi facile à y réaliser que dans un modèle 1D (on pourrait même se servir d'une seule règle au lieu de deux !) (mais deux règles permettront un meilleur rendu).

Modifier la forme des flèches ? 
Pour cette première version, la forme "central star" + "cône" a l'avantage de la simplicité.
La "central star" de chaque cube est commune aux six flèches possibles qui sont orientées chacune vers une face différente.
Dans la version actuelle, elle est redessinée si plusieurs flèches sont dans le même cube.
Ce dessin est peu coûteux (deux lignes superposées pour chaque nouvelle flèche)
et ce cas (plusieurs flèches dans le même cube) sera peu fréquent dans les premiers modèles développés. Mais... TODO

Le plus simple serait un trait allant du centre d'un cube au centre d'une de ses faces. Ce serait peu lisible pour des objets mais pourrait avoir un intérêt pour les tags (balises) éventuellement associés aux objets ou situations. Ces tags seraient machine-readable. Nécessairement. Seraient-ils human-readable aussi ? Ce serait idéal ! A inventer ou essayer, en tout cas. 
Un seul trait aurait sûrement un intérêt dans la représentation de voisinages de Moore 3D (Je préfère ne pas imaginer ça pour l'instant !  Il va falloir choisir de ne représenter ou de ne visualiser qu'une partie des connexions à la fois...).

Le premier objectif des versions à venir est l'extension du voisinage. Un voisinage type von Neumann 3D - le plus simple possible si on le veut symétrique par rapport aux axes de l'espace - est tout à fait indiqué pour cette première version. Mais les versions à venir devraient travailler en priorité avec des voisinages type Moore 3D approximativement spériques de rayon proche de celui de l'espace local. 
Par ailleurs, Gem-graph ne peut avoir sa puissance théorique maximale que s'il peut utiliser un voisinage étendu à tout l'espace. Mais cette puissance est vraisemblablement inutile, sauf pour les démonstrations mathématiques d'équivalence avec les automates cellulaires, par exemple, ou d'autres formalismes.
Par ailleurs, il est d'ores et déjà possible d'utiliser pleinement le "poids" (weight) ou la "charge" (load) des flèches.

! WARNING !   J'ai inversé pôle Nord et pôle Sud. Et c'est à corriger, je pense. 👀️
Ce sera une convention, bien sûr. Mais comment la choisir ? J'ai imaginé superposer repère orthonormé et repère géodésique. 
Si je regarde un repère orthonormé 3D:
les +x sont à ma droite, les -x à ma gauche  (Est - Ouest)
les +y en haut, les -y en bas   (Zénith - Nadir)   et...  si l'axe des z vient vers moi,
les +z sont derrière moi et les -z devant.   Donc les -z sont au Nord (que je regarde) et les +z sont au Sud.

Les vertex situés aux intersections des "grilles" (X-X, Y-Y et Z-Z) sont-ils utiles ?
Ils le seraient si ses cubes individuels étaient coloriés ou soulignés pour mettre en valeur des flèches qu'ils contiennent ou d'autres particularités.
Mais tant qu'il n'est pas possible de rendre sélectivement transparentes les parois de cubes individuels (ou de tel ou tel objet dessiné par les flèches), cette fonction est inutilisable et les vertex situés aux intersections des grilles sont donc inutiles.
On pourrait ne garder que ceux situés sur les faces de l'espace qui, eux, servent à tracer les grilles X-X, Y-Y et Z-Z.
Le nombre de vertex de l'espace serait alors de 12 par cube-unité (soit 12 * x * y * z) plus les vertex intersections des seules faces de l'espace (soit (x * y + x * z + y * z) * 2). 
A raison, bien sûr de trois nombres par vertex plus les couleurs.

Je comprends (maintenant seulement !) que si des régions du buffer lignes (idem pour le buffer triangles) sont laissées vides (occupées par des zéros) elles seront néanmoins redessinées en permanence et que le seul moyen d'éviter cela est de réallouer la taille du buffer à chaque délétion ou chaque ajout de flèche.

Néanmoins, lorsque le nombre de flèches présent dans l'espace est invariant, - cas de mes premiers modèles - il peut être avantageux de travailler dans un buffer de taille fixe. Il faut, pour cela, fixer une "densité maximale de flèches dans l'espace" nécessairement arbitraire. 
Bien que ce nombre reste toujours arbitraire, on peut estimer que certaines de ses valeurs seront plus utiles/utilisables que d'autres :
- un espace totalement vide ou totalement saturé ne pourrait rien représenter
- un espace trop vide ou trop plein (à définir - c'est intuitif) aurait peu de chances de représenter des phénomènes intéressants. La marche aléatoire d'un seul ou de quelques dimères dans un grand espace, par exemple, servira plus de test pour le bon fonctionnement de Gem-graph que de modèle d'étude.
- on peut considérer un espace rempli de flèches aux 2/3 comme équivalent à un espace repli au tiers (1/3) mais où les flèches seraient écrites "en creux" et, par conséquent, moins lisibles. Inutile, donc, de remplir plus de la moitié de l'espace. 
D'expérience,
- les densités de l'ordre du tiers (1/3 des unités de l'espace occupées par au moins une flèche) suffisent à représenter un nombre de phénomènes tel qu'il n'est pas nécessaire, au moins dans un premier temps, de prévoir davantage (mais des réalloc sont toujours possibles) et les densités trop fortes sont peu lisibles.
Un buffer lignes pourrait donc avoir une taille fixe qui serait calculée selon les paramètres suivants :
-   x * y * z = nombre de cubes
-   nombre de flèches moyen par cube  = 2   (il s'agit d'un nombre "moyen" qui surestime très probablement le nombre de flèches utilisé par la plupart des modèles)
-   dessin d'une flèche seule dans un cube = 3 + 4 traits (soit 14 nombres)
Faut-il coder cette option ?