Pas de code!

Sensations de brûlure dans la main, le poignet et le coude... Pas en état d'écrire du code en soirée, il faut que je me réserve pour la journée, faut bien croûter! Cependant, pour satisfaire la curiosité des millions de fans, je poste ma locomotive et mon wagon. J'espère bientôt les voir rouler sur ma voie ferrée!

C++0x - Initialisation

Vous en avez assez d'écrire des tartines de code pour initialiser vos conteneurs? Ça tombe bien, C++0x pense à vous! Sans plus attendre, comparez:

  std::vector<int> vi;
  vi.push_back(1);
  vi.push_back(2);
  vi.push_back(3);
  vi.push_back(4);
  vi.push_back(5);

à

  std::vector<int> vi {1, 2, 3, 4, 5};

Cool, non? La bibliothèque boost::assign fournissait déjà des utilitaires similaires, mais c'est beaucoup plus facile à utiliser comme ça. Bien entendu, ça marche également pour les types plus complexes:

  std::vector<std::string> vs {"a", "b", "c", "d"};

Et, cerise sur le gâteau, on peut imbriquer les initialisations:

  std::vector<std::vector<int> > vvi {{1, 2}, {3, 4, 5}};

  std::vector<std::vector<std::string> > vvs 
  {{std::string("a"), std::string("b")},
    { std::string("c"), std::string("d"), std::string("e")}};

Notez cependant que dans le second exemple, il faut passer le constructeur, car g++ (au moins) ne le fait pas implicitement comme pour l'exemple non-imbriqué.

Je trouve cette fonctionnalité particulièrement intéressante pour écrire des tests unitaires, car c'est typiquement là que l'on a besoin d'objets déjà définis. Plus d'excuses pour ne pas en écrire, donc!

Downgrade de fglrx sous Debian

La dernière mise à jour de Squeeze m'ayant cassé mon driver (blocks noirs dans Firefox, vachement pratique...), je me suis mis dans la tête, après avoir infructueusement tenté de trouver une option qui résoudrait le problème, de downgrader le paquet. C'est moins technique qu'il n'y parait:

Tout d'abord, vérification des paquets à changer. Ça tombe bien, le cache contient les paquets récemment mis à jour:

$ cd /var/cache/apt/archives/
$ ls | grep fglrx
fglrx-atieventsd_1%3a10-5-1_amd64.deb
fglrx-atieventsd_1%3a10-6-1_amd64.deb
fglrx-driver_1%3a10-5-1_amd64.deb
fglrx-driver_1%3a10-6-1_amd64.deb
fglrx-glx_1%3a10-5-1_amd64.deb
fglrx-glx_1%3a10-6-1_amd64.deb
fglrx-glx-ia32_1%3a10-5-1_amd64.deb
fglrx-glx-ia32_1%3a10-6-1_amd64.deb
fglrx-modules-dkms_1%3a10-5-1_amd64.deb
fglrx-modules-dkms_1%3a10-6-1_amd64.deb

Ah ah! On dirait bien qu'il faut redescendre de la 10-6-1 à la 10-5-1. Installons chacun des paquets fglrx en version 10-5-1 avec dpkg:

$ dpkg -i fglrx-driver_1%3a10-5-1_amd64.deb
$ dpkg -i fglrx-modules-dkms_1%3a10-5-1_amd64.deb
$ dpkg -i fglrx-glx_1%3a10-5-1_amd64.deb
$ dpkg -i fglrx-glx-ia32_1%3a10-5-1_amd64.deb
$ dpkg -i fglrx-atieventsd_1%3a10-5-1_amd64.deb

(bon, d'accord, on peut mettre tous les paquets sur la même ligne).

Reboot...

Et je retrouve l'accéleration, et Firefox sans le mode "protection des témoins". Pfiou!

Gestion des véhicules

Enfin, le problème de la gestion des véhicules est résolu!

Enfin, quand j'aurais implémenté mon design que voici:



En effet, le souci, c'est que, comme beaucoup de gens, j'imagine, j'ai mes idées dans les endroits les plus ésotériques (c'est à dire dans les endroits où réfléchir est la chose la plus intéressante disponible). Je me précipite dès que possible donc sur un papelard pour fixer tout cela au clair.

L'idée principale, ici, c'est que chaque véhicule possède un chemin, et suit ce chemin sans discuter. Le chemin permet donc d'abstraire tout ce qui est en dessous: vitesse max, arrêts nécessaires, position des wagons pour les trains. Lorsque le véhicule arrive au bout du chemin, il peut alors demander au réseau (ferré ou routier, hein, pas le réseau de communications. Quoique...) comment, à partir de sa position actuelle, aller à sa prochaine destination. Le réseau fait tourner son petit Dijkstra (que je vais probablement préférer à A*, mais j'en recauserai), et renvoie un nouveau chemin que le véhicule peut apposer à son chemin courant. Et c'est reparti!

Créer ses textures dans Blender

Enfin, j'ai compris comment générer ses textures dans Blender! Le "Node edit" mode, que je n'avais jamais vu auparavant, permet en effet de graphiquement définir de complexes textures procédurales. Tout est expliqué dans cet excellent tutoriel.

Voilà le mur tel que je l'ai généré:



Cela m'ouvre beaucoup d'horizons pour la modélisation des bâtiments. Ces textures donneront je l'espère vie aux bâtiments high-poly, et se laisseront "cuire" gentiment vers le low-poly.

OpenSceneGraph et cache

C'est tout bête, et pourtant il m'a fallu tâtonner un petit peu. Par défaut, OSG recharge chaque ressource en un nœud complétement séparé, même si le fichier est le même. Changer mes 100 gratte-ciel identiques prenait donc environ 10 secondes, et faisait grimper la mémoire à 600 megs.

Perte de temps, perte de mémoire, et c'est exactement pour cela qu'il existe l'objet "osgDB::ReaderWriter::Options". Voyez plutôt:

osg::ref_ptr<osgDB::ReaderWriter::Options> 
   cachingOptions(new osgDB::ReaderWriter::Options);
cachingOptions->setObjectCacheHint
   (osgDB::ReaderWriter::Options::CACHE_ALL);

...

osg::Node * node = 
   osgDB::readNodeFile("truc.osg", cachingOptions.get());

Et voilà comment passer de 10 secondes à un chargement presque instantané, et de 600 à 280 megs. Facile!

Des grattes-ciel

Voilà 50 grattes-ciel sur mon terrain. Les modèles ont été faits sous Blender, et ont environ 5600 faces chacun, ce qui est beaucoup! Au rendu, OSG ne s'en sort pas trop mal, puisqu'il m'en affiche une bonne partie tout en restant au dessus des 100 images par seconde.

C'est typiquement le genre de situation qui va nécessiter des niveaux de détails! A très courte distance, le bâtiment est détaillé juste comme il faut. Mais de loin, il va falloir sérieusement réduire le nombre de faces. La solution que je compte suivre est de créer une version peu détaillée du bâtiment (pas beaucoup plus qu'un bête cylindre!), et de "cuire" les normales du modèle détaillé vers une texture pour le modèle peu détaillé. L'on peu ainsi espérer un rendu à peu près équivalent à distance, avec peut-être une centaine de polygones, au lieu de plusieurs milliers.

Au passage, les défauts de rendu liés au crénelage sont tristement visibles. Je compte pour le moment attendre que wxWidgets fournisse le support pour l'anti-crénelage, et si j'en ai besoin plus tôt, j'insérerai une surface SDL ou SFML pour faire le boulot.