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.
- 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.
- 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)
