Preview route

Après une longue phase de prototypage dont je ne vais rien montrer pour l’instant (Terrain, Route, Facade…), voici quelques nouvelle du projet :

Architecture

Un grand problème fait rage depuis la nuit des temps dans le monde de la programmation. Dans de nombreux cas nous en avons rien à faire des performances… Mais lorsque c’est le cas nous devons faire un choix entre la modularité et les performances ! C’est bien triste mais je voudrais que le générateur de ville soit modulaire. Donc comment faire puisque de nombreux algorithme sont assez lourd. Dois-je préférer la modularité au détriment de la performance ? Je pense avoir trouver un bon compromis, j’attends vos avis…

Le générateur est composer de plusieurs couche :

Workflow du générateur de ville

  1. Le Parser prend en entré un fichier XML et en sortie produit des Parameters
  2. Le Generator prend en entré des Parameters et en sortie produit des CityObjectsDescriptor ( RoadsDesc, IlotsDesc, BuildingVolumesDesc, FacadesDesc, IndoorsDesc, …)
  3. Le City prend en entré des CityObjectsDescriptor et en sortie produit des données topologiques ( RoadGraph, BuildingVolume, …)
  4. Le Meshing prend en entré des informations topologiques pour en produit des données géométriques interprétable par un moteur graphique (*.fbx, *.collada…)

Le Scripting :

De nombreuses options du générateur peuvent être modifier par scripting. Comme la manière dont les routes sont générées, la manière dont les ilots sont subdivisés…

De nombreuse solution existe par exemple le Lua, Python (des librairies existe déjà, lua++, boost.python…). D’autre programmeur on trouvé une autre solution pour résoudre le problème de la modularité. Certain on crée un compilateur C-Like vers du ByteCode qu’il interprète au Runtime… La solution du C-Like to ByteCode est dans certain cas comparable aux méthodes avec du lua et python (puisque certain compilateur lua et pyhton génère du ByteCode, il existe même compilateur qui génère du Code Machine à partir du python…). La solution du C-Like vers du ByteCode demande beaucoup de code alors que je voudrais me concentrer sur le générateur de ville.

Voici ma solution :

Dans un fichier XML je décris des fonctions de la manière suivante :

<Function name= »GaussLike » value= »Exp(-_1*_1) » />

De ce fichier, dans le bloc des Parameters je génère les informations nécessaire à la création du code C++. Puis dans le Generator je génère du Code C++ qui est compiler en *.DLL (ou *.so selon les plateformes). A partir d’ici il me suffit de stoker un pointeur de fonction 🙂 Une simple indirection, puis j’ai du code directement lu dans le CPU sans interpréteur quelconque. Si l’on change le script un simple déchargement et chargement de DLL puis une remise à jour les pointeurs de fonction 🙂 et voilà notre scripting mis à jour

Exemple :

Le bout de xml suivant :

<Function name= »DistanceRatio » value= »Clamp( _1/_2, 0.f, 1.f ) » />

Génère le code C++ suivant :

DLL_EXPORT
float DistanceRatio( float const _1, float const _2 )
{
return Clamp( _1/_2, 0.f, 1.f );
}

Voilà rien de bien complexe 🙂

Les routes

Comme quasi-toute les références sur la génération de route je me base sur des L-System. Un système avec une tortue qui avance. La tortue à de nombreux paramètre comme la longueur, la largeur, sa probabilité de crée des routes enfants, le nombre max d’enfant…

Une tortue est assez idiote. Elle est issu d’une route et peut créer une route devant elle et des routes enfants à sa gauche et sa droite, schéma :

Turtle schema

Lorsque l’on veut crée une nouvelle route on demande à la tortue associée dans quel direction, quel distance fera cette route, est ce qu’on lui crée des enfants et combien…

Voici quelque exemple (ces exemples sont issu du même programme seul les fonctions définie dans le xml et les paramètres change) :

 

exemple 0

exemple 1

exemple 2

exemple 3

exemple 5

exemple 6

exemple 7

exemple 8

exemple 9

exemple 10

exemple 11

 Voici la première préview. Prochain objectif, améliorer le générateur de route en donnant plus de paramètre au tortue pour faire des routes tournant autour d’un point, pour pouvoir avoir le pattern « Paris »…

Bientôt je présenterais une vidéo montrant le générateur en « temps réel »…