La fin du moc ?

Qt est un framework C++ relativement ancien. Pour supporter des fonctionnalités intéressantes (gestion des signaux et slots, métaobjets, introspection, etc.) sur un grand nombre de compilateurs pas forcément très au courant des standards C++, il a dû développer un outil de génération de code, le moc (metaobject compiler).

Il donc n’est pas suffisant de compiler les fichiers source d’une application et de les lier avec le framework, puisqu’il faut générer du code. Ce simple oubli a déjà causé bien des pertes de temps, même pour des développeurs plus chevronnés. Les outils de compilation s’y sont habitués (QMake, CMake et d’autres), les EDI également… mais pas forcément les utilisateurs : il est la cause d’un certain nombre de grandes incompréhensions de la part de débutants avec le framework. Les plus puristes n’apprécient pas non plus cette partie hors standard de la chaîne de compilation.

Plus techniquement, moc est un outil en ligne de commande qui prend en entrée un fichier source de l’application avec des macros particulières (la plus connue étant Q_OBJECT) et génère un autre fichier source à ajouter à la compilation. Ce dernier implémente les métaobjets grâce aux informations récoltées par ces macros particulières. Pour cette étape de génération, moc utilise un analyseur assez naïf qui se limite à l’extraction des informations nécessaires à son bon fonctionnement, il achoppe donc sur du code C++ plus avancé ou sur les nouveautés de C++11/14.

Clang

Une première expérience était de remplacer l’étape du moc externe au compilateur par une extension de ce compilateur, afin de générer le code nécessaire à la volée. moc-ng s’occupe de cette partie, avec un plug-in pour Clang (un compilateur C++), mais aussi un outil en ligne de commande équivalent au moc mais utilisant Clang pour l’analyse du code source de l’application (et évite donc les écueils de la solution actuelle).

Clang est bien connu pour ses messages d’erreur, bien plus explicites que ceux d’autres compilateurs. Proposer le moc en tant qu’extension permet de générer des messages d’erreur en cas de mauvaise utilisation des commandes du générateur, notamment en cas de typo. Le message généré par le moc actuel est très suboptimal :

Grâce aux fonctionnalités plus avancées de Clang pour la recherche dans les fichiers source, l’extension propose même la correction de la typo à l’origine de l’erreur :

Bien qu’il ne s’agisse que d’une expérience, d’une preuve de faisabilité, cette réimplémentation fonctionne bien : elle peut remplacer le moc pour la compilation d’une grande partie de Qt, les tests n’échouant pas plus souvent qu’avec le moc officiel.

Se passer du moc

Boost implémente déjà les concepts de signaux et slots sans utiliser de précompilateur dans Boost.Signals2. Le moc propose également des fonctionnalités d’introspection et de réflexion, c’est à ce moment que le comité de standardisation du C++ entre en jeu : le document N3814 est une demande de propositions pour la réflexion à la compilation. Cette fonctionnalité sera intégrée au plus tôt dans C++17 et aucune version n’est actuellement implémentée dans un compilateur.

La proposition N3951 donne de nouvelles significations aux mots clés typedef et typename, de telle sorte que le code

class SomeClass {
public:
  int foo();
  void bar(int x);
};

vector names = { typename... };
auto members = std::make_tuple(typedef...);

deviendrait équivalent à

 vector names =  { "SomeClass",  "foo", "bar" };
auto members = std::make_tuple(static_cast(nullptr), &SomeClass::foo, &SomeClass::bar);

Ainsi, un compilateur implémentant cette fonctionnalité pourrait générer l’équivalent du QMetaObject actuel à l’aide de quelques traits, sans outil extérieur. Pour le moment, il est possible d’expérimenter cette fonctionnalité en réécrivant soi-même les typedef… et typename… dans le prototype, avec le grand avantage de garder la compatibilité binaire avec le code généré par le moc : les structures générées donnent tous les slots, les signaux et les propriétés requises pour la construction du métaobjet à l’exécution. Pour distinguer les signaux et slots, C++11 propose des attributs, mais il serait plus agréable de les placer au niveau des spécifications d’accès de groupe (soit une extension du document N3955) :

class MyObject : public QObject {
    Q_OBJECT
public [[qt::slot]]:
    void fooBar();
    void otherSlot(int);
public [[qt::signal]]:
    void mySignal(int param);
public:
   enum [[qt::enum]] Foobar { Value1, Value2  };
};

Sources : Proof Of Concept: Re-implementing Qt moc using libclang et Can Qt’s moc be replaced by C++ reflection?

Voir aussi :

Qt Creator 3.1 beta

Qt Creator 3.1 est désormais disponible en préversion, peu après Qt 5.2. Parmi les nouveautés, le moteur d’analyse du C++ interne peut être remplacé par Clang : l’avantage principal est que Clang est bien plus précis sur la sémantique du C++ que le moteur interne, mais au prix de performances bien moindres (ce qui a d’ailleurs ralenti fortement le développement de cette fonctionnalité, en cours de développement depuis 2011).

Pour rappel, Clang est un compilateur C++ basé sur LLVM, une architecture de compilateurs libre notamment développée par Apple et désormais utilisée sur un certain nombre de BSD. Il supporte une série de langages proches de C++, comme C ou Objective-C. Il s’agit également du premier compilateur libre à supporter complètement le standard C++14, notamment avant GCC.

Outils de développement

Cette fonctionnalité est activable à la demande, comme un plug-in (ClangCodeModel). Les binaires proposent cette fonctionnalité, mais elle n’est pas (encore) activée par défaut. La différence principale à ce niveau sera pour ceux qui compilent eux-mêmes Qt Creator : il faudra disposer de libclang (détails dans les sources).

Autre changement au niveau des outils de développement, toute version de GDB sans script Python est désormais dépréciée (la dernière plateforme pour laquelle une telle version de GDB n’est pas disponible est OS X, mais LLDB le remplace avantageusement, surtout avec le support de fonctionnalités autrefois réservées à GDB). Le profileur QML a été aux petits oignons, avec un grand nombre de bogues corrigés.

Un autre plug-in expérimental fait son apparition : Beautifier, pour reformater du code. Il peut utiliser les outils externes Artistic Style, Clang-format et Uncrustify.

Support de Windows RT

La dernière préversion de Qt 5 propose un support expérimental de Windows RT, Qt Creator se met au diapason avec un nouveau plug-in (encore expérimental, comme le support de WinRT dans Qt) pour supporter cette plateforme. Tout ne fonctionne pas encore, mais il est déjà utilisable. Parmi les fonctionnalités qui fonctionnent déjà bien :

  • enregistrement du Windows Runtime et de Qt pour Windows Phone ;
  • support de Windows Runtime et des Windows Phone Kit ;
  • compilation d’applications pour Windows Runtime et Windows Phone ;
  • lancement d’applications par un bouton depuis l’EDI.

Pour le moment, cependant, le débogage n’est pas encore fonctionnel, le bouton est d’ailleurs grisé dans l’interface.

Plus en détail, pour gérer le déploiement et le lancement d’applications, le plug-in utilise deux nouveaux outils en ligne de commande, windeployqt et winrtrunner, proposés par Qt 5.3. En tant que plug-in expérimental, le support de Windows RT n’est pas activé par défaut.

Sources : Qt Creator 3.1 beta released et Experimental Version of Qt Creator’s WinRT Plugin

NVIDIA HairWorks pour la simulation de poils

Précédemment, NVIDIA avait offert des détails techniques sur un algorithme de simulation de poils, follow the leader. Associé aux développements précédents de la firme, NVIDIA HairWorks fournit une technologie complète intégrée de simulation de poils. Elle est d’ores et déjà utilisée dans Call of Duty: Ghosts et Witcher 3 et entre en compétition avec TressFX, la technologie d’AMD, notamment utilisée dans Tomb Raider.

Ces deux implémentations partagent déjà un point commun : l’utilisation de DirectCompute, la technologie de GPGPU proposée par Microsoft dans le cadre de DirectX – une technologie indépendante du fabricant de cartes graphiques –, alors que précédemment tout PhysX utilisait NVIDIA CUDA. Ce choix a été justifié par le fait que la plus grande partie du temps est utilisée pour l’affichage des poils, pas pour le calcul : il était alors plus efficace de travailler au plus près de l’API graphique. Il ne s’agit donc pas d’un revirement complet pour NVIDIA (tous les prochains développements n’utiliseront pas forcément DirectCompute). Au niveau de la portabilité, les consoles actuelles devraient être supportées dans le futur.

Par rapport aux techniques précédemment montrées, NVIDIA HairWorks intègre les différents composants dans un solveur unique qui traite tant les humains que les animaux, sur des corps dynamiques. Il permet également de simuler de l’herbe. Parmi les fonctionnalités supportées, on peut compter la préservation des formes, l’évitement des étirements des poils, divers contrôles sur les forces dynamiques, l’inertie, les collisions (relativement simples pour le moment, des fonctionnalités plus avancées arriveront avec le temps, comme des détections plus robustes et contre des objets déformables) ou encore le support de plusieurs processeurs graphiques (aucune implémentation sur CPU n’est actuellement prévue). Un grand nombre de paramètres sont disponibles : raideur, l’ondulation, la variation de longueur, l’humidité (le moteur est capable de gérer des transitions de poils secs à humide et inversement).

Le rendu de poils requiert énormément de données : pour Call of Duty, il faut compter un demi million de poils simultanément. Les algorithmes de rendu utilisent donc énormément les fonctionnalités de pavage (tesseletion) de DirectX 11, ce qui permet de créer de manière dynamique un très grand nombre de poils sans utiliser trop de mémoire. Ensuite, une étape de posttraitement a lieu, notamment pour calculer les ombres (qui correspondent à la peau sous-jacente).

Côté artiste, une série d’outils est utilisée (courbes de guidage, notamment), en réutilisant des outils tiers (comme Shave and a Haircut pour Maya ou bien Hair and Fur pour 3DS Max).

Le produit devrait être disponible de manière publique « dans un futur très proche ».

Source : http://physxinfo.com/news/12197/introducing-nvidia-hairworks-fur-and-hair-simulation-solution/

Sortie d’APEX 1.3

APEX 1.3 vient de sortir et supporte PhysX SDK 3.3, récemment sorti.

Un des changements de cette version est plus architectural : tout le code de support des versions précédentes a été migré dans un nouveau module, APEX Legacy. Il suffira de le charger pour que les données des versions précédentes soient lisibles (au lieu de charger un module de support par module d’APEX, comme APEX Clothing Legacy ou APEX Destructible Legacy).

Les modules Destruction et Clothing supportent désormais les mandataires d’affichage (render proxies) : les données nécessaires à l’affichage sont désormais stockées dans un objet séparé, qui peut être détaché des acteurs. Ainsi, dans un contexte multifil, le moteur physique peut très bien avoir des acteurs déjà supprimés car plus nécessaires, alors que toutes les données ne sont pas encore affichées : en détachant cet objet de rendu, les données sont gardées.

Destruction

Du côté artiste, le module de destruction propose désormais des groupes comportementaux. Ainsi, toute une série de paramètres (seuil de dommage, propagation des dommages, densité, etc.) seront stockés au niveau d’un groupe, au lieu de chaque débris.

Interface des groupes comportementaux

Le paramètre de propagation des dommages (damage spread) est une triplet contenant un rayon minimum, un multiplicateur de rayon et un exposant de décroissance, qui remplace le paramètre de rayon de dommage. Quand un dommage est causé à une structure destructible, elle possède un certain rayon (qui peut être nul dans le cas d’un point) ; une fois multiplié et additionné au rayon minimum, cette valeur – appelée rayon maximum – indique la distance après laquelle la structure n’est plus impactée par le dommage ; tous les points entre ces deux rayons sont touchés de manière dégressive (selon une loi précisée par l’exposant de décroissance), tous les points dans le rayon minimum reçoivent un dommage maximal.

Le système de fracturation en temps réel est désormais disponible, après une série d’annonces (comme une démo de couplage avec des fluides ou des algorithmes). L’effet semblera alors plus naturel et plus détaillé, il dépendra plus fortement du point d’impact et de la force appliquée que de la fracturation précalculée. Il faut noter que, pour APEX 1.3, la fracturation ne se fera que comme du verre.

Fracturation en temps réel

Tissus

Le solveur amélioré disponible dans PhysX 3.3 est désormais à la base des simulations de tissus, ils supportent donc les autocollisions, les collisions avec d’autres objets de tissus, ainsi que des collisions (plus limitées) avec le décor.

Particules

Les différents modules liées aux particules (APEX Basic FS, Basic IOS, Emitter…) sont désormais fusionnés dans APEX Particles, ce qui limite de factor le nombre de DLL à déployer avec les applications les utilisant mais aussi le code de chargement des différents modules.

Un nouveau type d’entité facilite les interactions entre les particules et la turbulence, en liant ces acteurs et données en un seul acteur manipulable en temps réel (des émetteurs de particules, une grille de turbulence, un champ de force, une source de chaleur et d’autres peuvent être ainsi fusionnées). Chacun des effets individuels peut avoir des caractéristiques temporelles différentes, comme une durée ou des compteurs ; de même, un système parent-enfant est déployé, ce qui fait que le déplacement de l’acteur racine déplace tous les enfants.

Éditeur d'effets de particules

Source : http://physxinfo.com/news/12024/apex-1-3-released-features-first-iteration-of-real-time-fracturing/

Sortie de PhysX 3.3 et des plug-ins 3DS Max et Maya en version 3.0 (ainsi que PhysX 3.2.5 et APEX 1.2.5)

Après une phase de préversions privées, PhysX 3.3 est désormais disponible au grand public. En résumé, il apporte de nouvelles fonctionnalités (principalement sur la simulation des tissus), mais surtout de grandes améliorations de performances et le support de nouvelles plateformes (GPU Kepler, ARM NEON, Windows 8 Modern, Wii U. Les détails sont disponibles en ligne.

En même temps, les intégrations aux modeleurs 3D 3DS Max et Maya ont été mises à jour en version 3.0 : ces plug-ins ne supportent plus PhysX 2.8, ils se tournent exclusivement vers PhysX 3 et APEX 1.3.

Également, les branches précédentes reçoivent une série de mises à jour, dont l’objet est exclusivement la correction de bogues : PhysX 3.2.5 et APEX 1.2.5.

Sources : http://physxinfo.com/news/11796/physx-sdk-3-3-0-final-release/, http://physxinfo.com/news/11962/physx-plug-ins-have-received-3-0-update/, http://physxinfo.com/news/12003/physx-sdk-3-2-5-and-apex-1-2-5-are-available/.

NVIDIA FLEX, le solveur GPU unifié

Le mois dernier, NVIDIA a annoncé une série de nouveautés pour les développeurs de jeux, dont un nouveau solveur unifié qui fonctionne sur GPU (avec la technologie CUDA, donc actuellement limité aux puces NVIDIA, bien qu’une version DirectCompute soit prévue et une autre sur CPU dans les esprits) – tant sous Windows que Linux, pour le moment.

FLEX est un solveur multiphysique pour les effets visuels. Il hérite notamment des travaux sur PBF pour la simulation des fluides, avec une extension au couplage bidirectionnel entre les liquides et les autres types d’objets (pas seulement des solides, mais également des tissus). Il s’inspire d’outils comme nCloth (intégré dans Maya) ou Lagoa (Softimage), mais en les utilisant en temps réel.

Par rapport à PBF, FLEX veut être plus général et traiter des objets comme des liquides, des matériaux granuleux (sable, poussière), des tissus (y compris des drapeaux ou des journaux), des solides et corps déformables. Il utilise une représentation unique pour tous ces objets, ce qui lui permet de traiter des couplages de manière naturelle. Il reste possible d’écrire son propre code pour faire l’interface avec d’autres solveurs comme ceux d’APEX.

Il s’agit d’un solveur différent de ceux disponibles actuellement dans le SDK PhysX, il n’est d’ailleurs pas prévu pour les mêmes utilisations (un moteur traditionnel prévu pour les solides sera plus approprié pour des personnages ou du raycasting). En particulier, il ne réutilise pas d’algorithme implémenté dans PhysX : il est même utilisable totalement indépendant du moteur de NVIDIA. L’intégration de FLEX dans PhysX devrait arriver dans la version 3.4 ; actuellement, il faut encore faire le pont entre les deux soi-même, pour ceux qui ont accès au SDK (la disponibilité générale se fera avec PhysX 3.4).

Source : http://physxinfo.com/news/11860/introducing-nvidia-flex-unified-gpu-physx-solver/

Sortie de V-Play 1.4, le moteur de jeu en QML

V-Play est un moteur de jeu multiplateforme basé sur le framework C++ Qt. Il supporte ainsi toutes les plateformes compatibles avec ce dernier (Windows, OS X, Linux, mais aussi MeeGo, Symbian, iOS, Android ou Blackberry 10), soit des plateformes fixes ou mobiles de type smartphone ou tablette.

Au niveau du code, il utilise la plateforme Qt Quick et le langage déclaratif QML, combiné avec JavaScript. Il fonctionne sur Qt 4.8.1, soit Qt Quick 1.1. Le paradigme déclaratif permet d’écrire un code très succinct, mais l’interface réalisée s’adaptera sans peine à toutes les résolutions d’écran et à tous les ratios. Le développement se passe dans Qt Creator, l’EDI spécifiquement créé pour Qt.

Tous les composants QML sont implémentés en C++, ce qui devrait ainsi fournir un bon niveau de performances. Il intègre le moteur physique Box2D, également entièrement accessible en QML. Il fournit une série de services bien utiles actuellement, comme les achats intégrés dans le jeu, une intégration avec les réseaux sociaux (Facebook) et des publicités, en plus de services d’analyse (Flurry). Il laisse toujours un accès à la plateforme sous-jacente, notamment pour afficher des notifications natives, utiliser un accéléromètre ou ouvrir une page Web.

La version 1.4 ajoute le support de Blackberry 10, du téléchargement de paquets depuis le jeu (afin de proposer aux magasins d’applications des binaires plus légers). L’EDI se complète d’une série d’assistants pour créer des maquettes de jeux fréquents plus facilement. L’utilisateur peut également prendre des captures d’écran depuis le jeu et a droit à de meilleurs retours haptiques.

Il faut cependant remarquer qu’il n’est pas entièrement gratuit, mais qu’une telle version existe. Le support des plateformes est limité aux desktop, Symbian et MeeGo (soit aux systèmes d’exploitation mobiles morts : dommage, pour un moteur prévu spécialement pour les jeux type mobile). Dans tous les cas, il est possible de compiler le jeu en local. Un service de test à distance pour toutes les plateformes est fourni ; dans l’édition gratuite, il est limité à trente essais par mois. Il est nécessaire de s’enregistrer pour ne fut-ce que télécharger le SDK.

Sources : http://devblog.blackberry.com/2013/08/getting-started-with-the-v-play-gaming-engine/ et http://v-play.net/.

APEX Hair/Fur

APEX, le framework de simulations physiques basé sur PhysX, verra bientôt l’ajout d’un nouveau module pour les cheveux et autres poils. Actuellement, le module APEX Clothing propose la simulation de tissus qui suivent le personnage qui les porte, comme dans BioShock Infinite.

The Witcher 3: Wild Hunt, attendu en 2014, profitera du module APEX Hair/Fur, qui proposera le même type de fonctionnalités – mais pour des cheveux et des poils, humains ou non.

Ces simulations utilisent des dizaines de milliers de cheveux inextensibles en temps réel pour atteindre cet objectif de réalisme, ce qui requiert une grande puissance de calcul, offerte par les derniers GPU de la marque. Auparavant, ce genre d’effets était limité aux films, puisqu’il n’y avait pas besoin de temps réel.

Pour une simulation aussi rapide, il faut effectuer très peu d’itérations pour chaque image. La technique utilisée, nommée follow the leader (FTL) est géométrique et ne requiert qu’une seule itération, sans pour autant avoir des poils qui s’étirent. L’amélioration apportée par les équipes de NVIDIA est l’extension de cette technique à des cas non statiques.

Chaque poil est constitué d’une série de particules liées les unes aux autres par des distances au repos. À chaque itération, ces particules se meuvent et il faut restaurer l’espacement entre deux (pour éviter l’étirement desdits poils). La version statique de l’algorithme FTL parcourt les positions de tous les points, l’un après l’autre, en modifiant les positions de telle sorte que la particule se situe sur une sphère centrée sur la précédente. La nouvelle position est donnée par le point le plus proche sur la sphère de l’ancienne position.

La nouveauté consiste à améliorer cet algorithme pour le rendre plus dynamique, sortir des hypothèses de quasistaticité. Il faut alors stocker, en plus de la position, la vitesse de chaque particule de chaque poil. L’itération corrigera tant la position que la vitesse, en utilisant la technique de dynamique basée sur les positions (aussi utilisée pour la simulation de fluides). La correction est en général basée sur l’inverse de la masse de chaque particule, mais cela génère un comportement relativement chaotique (exposé dans la vidéo ci-dessous), corrigé par un terme d’amortissement numérique. (Tous les détails sont donnés dans l’article Fast Simulation of Inextensible Hair and Fur, voir plus loin.)

Sources : How NVIDIA Delivered Hairier Effects for Your Favorite Games, Fast Simulation of Inextensible Hair and Fur.

Simulation des fluides basée sur la position : évolutions montrées au SIGGRAPH 2013

La simulation des fluides basée sur la position (position based fluids) est une manière de simuler les fluides basée sur le framework PBD (position-based dynamics) de PhysX, notamment utilisé pour les tissus et autres objets déformables. Comme toujours pour des jeux, cette simulation doit être rapide et stable (demander peu d’itérations pour converger), en sacrifiant la précision des résultats.

Cette approche combine une technique SPH classique (smoothed-particles hydrodynamics) avec ce framework PBD. Cette technique permet d’imposer l’incompressibilité d’un fluide (son volume varie peu, peu importe la pression appliquée, comme l’eau) de manière bien plus efficace qu’avec une approche de type SPH pure, grâce aux contraintes de position. Techniquement, il s’agit toujours d’un solveur itératif basé sur dix kernels CUDA.

Avec un terme plus artificiel de pression, ce nouveau solveur améliore la distribution des particules et crée des effets similaires à la tension de surface. Le confinement des vortex (une technique de simulation des écoulements dominés par des vortex) est aussi utilisé pour laisser l’utilisateur injecter de l’énergie dans le fluide.

Au SIGGRAPH 2013, Miles Macklin (un des auteurs de cette méthode de simulation) a présenté les dernières améliorations en date de l’algorithme : les interactions à double sens entre un fluide et des solides ou des tissus.

Les diapositives de cette présentation sont disponibles en ligne.

Il faut aussi noter que Eric Wolter propose une autre implémentation du même concept en C++ mais avec OpenCL : sources sur GitHub.

Sources : http://physxinfo.com/news/11109/introduction-to-position-based-fluids/ et http://physxinfo.com/news/11679/siggraph-2013-latest-improvements-to-position-based-fluids/

PhysX 3.3 Beta 2

Après une première phase de tests privés, voici PhysX 3.3 Beta 2, une préversion publique. PhysX 3.3 apporte un grand nombre de fonctionnalités ainsi que des améliorations de performances. L’article sur la préversion privée contient la description des fonctionnalités majeures ajoutées.

Parmi les autres points importants de cette version, on peut citer un support plus étendu des plateformes : les GPU Kepler, la dernière famille de GPU de NVIDIA ; la console Wii U ainsi que les applications Windows 8 Modern UI (l’interface traditionnelle était déjà supportée) ; sur les processeurs ARM, le jeu d’instructions NEON (instructions SIMD) est à présent utilisé. Il faut cependant remarquer que les exemples ne sont pas disponibles pour Windows RT ou la Wii U.

Notes de version.