KDE Frameworks 5

Les bibliothèques KDE, utilisées pour construire les applications KDE, se modernisent avec la sortie de KDE Frameworks 5.0 début juillet et 5.1 début août. La principale différence par rapport à KDE Platform 4/kdelibs est la modularisation : les composants sont désormais découplés, les dépendances réduites au maximum, de telle sorte qu’il n’est plus nécessaire de lancer une artillerie KDE complète pour lancer une application qui en utilise seulement une fraction. La première version proposait déjà une cinquantaine de composants, apportant des fonctionnalités bienvenues et manquantes dans Qt (bien qu’une partie a déjà été intégrée dans Qt 5), avec très peu de dépendances en dehors de Qt lui-même ; KDE Frameworks 5.1 porte le compte à une soixantaine. L’objectif est de ne plus faire de différence entre une application Qt et une application KDE.

Organisation des dépendances

Les modules des KDE Frameworks 5 se divisent en trois catégories, selon leurs dépendances à l’exécution :

  • les éléments fonctionnels n’ont aucune dépendance ;
  • les éléments d’intégration peuvent avoir des dépendances afin d’intégrer les éléments fonctionnels au système d’exploitation ou à la plateforme ;
  • les solutions, par contre, sont libres au niveau des dépendances.

De même, ils se répartissent en trois niveaux (tiers) selon leurs dépendances lors de la compilation : au premier niveau, les seules dépendances autorisées sont Qt et d’autres bibliothèques externes à KDE et à Qt ; au deuxième niveau, les modules ne peuvent dépendre que du premier niveau ; au troisième niveau, les dépendances peuvent être enregistrées envers tous les niveaux.

Ces deux hiérarchies ne sont pas orthogonales : une solution de troisième niveau peut dépendre d’autres solutions d’autres niveaux.

Dépendances autorisées

Fonctionnalités

Les modules fonctionnels proposent une série de fonctionnalités bien utiles à un grand nombre d’applications, comme :

  • KArchive gère les techniques de compression les plus populaires, comme ZIP, 7-Zip, TAR ou XZ : il peut compresser et décompresser tant des flux de données (GZip, BZip2, XZ) que des archives proprement dites (7Zip, Ar, TAR, ZIP) ;
  • KPlotting propose des fonctionnalités simples pour l’affichage de graphiques, en ce compris l’anticrénelage ou la superposition (en quelque sorte, il s’agit d’une version simplifiée de Qwt) ;
  • Threadweaver facilite l’écriture de code multifil grâce à la notion de travaux (jobs), avec une gestion des dépendances et une intégration au système de signaux et de slots de Qt ;
  • KConfig s’occupe de la configuration des applications, avec une génération de code pour la lecture et l’écriture de ces fichiers, mais également le lien entre les fichiers de configuration et l’interface graphique pour changer les paramètres.

Côté intégration, Sonnet fait le lien avec la correction orthographique (tant aspell, hspell, hunspell qu’enchant) et Solid fournit un accès aux données issues directement du matériel (niveau de batterie, état du réseau, etc.). Dans ce dernier cas, pour certaines fonctionnalités, certaines dépendances à l’exécution sont requises. KI18n intègre GNU gettext, une bibliothèque pour la gestion des traductions ; ce module facilite le travail avec d’autres flux de traduction, plus souvent basés sur gettext.

Jusqu’à présent, ces fonctionnalités sont du premier niveau. Au troisième, pour les solution, KIO propose une interface d’édition de fichiers identique, qu’ils soient stockés en local ou en distant. KService propose des fonctionnalités avancées de gestion des extensions, comme leur localisation sur le système de fichiers.

Sources

Frameworks 5 (dont l’image), First release of KDE Frameworks 5, Second release of KDE Frameworks 5

Sortie d’Inqlude 0.7

Après trois années de développement, l’idée d’Inqlude, soit un dépôt de bibliothèques, un gestionnaire de paquets centré sur Qt, arrive à un certain niveau de maturité : l’auteur considère le projet comme prêt pour les utilisateurs précoces. Notamment, l’outil est utilisé pour générer le site Web inqlude.org ; parmi les bibliothèques présentes, un grand nombre provient des KDE Frameworks 5. À terme, il se veut l’équivalent de Bower ou npm en JavaScript, de RubyGems ou encore de pip pour Python.

Les métadonnées sont gérées, comme d’autres avant lui, par des fichiers de manifeste, écrits en JSON. La gestion du téléchargement et de l’installation des paquets n’est pas encore prête : une implémentation simple est d’ores et déjà disponible, mais il manque encore des métadonnées pour rendre le processus utile.

Les prochaines versions sont déjà planifiées :

  • 0.8 : la documentation sera améliorée pour faciliter les contributions ;
  • 0.9 : les fichiers de manifeste ne pourront plus changer de structure
  • 1.0 : l’outil pourra gérer des paquets en local, ce qui le rendra effectivement utile pour les utilisateurs et développeurs d’applications Qt.

En l’état, le projet permet déjà d’avoir un aperçu de l’écosystème Qt, des diverses bibliothèques non inclues dans la distribution officielle de Qt mais néanmoins utiles.

Source : Announcing first Inqlude alpha release

Nouvelle licence pour Qt : LPGL 3

Depuis les débuts de Qt, il y a une vingtaine d’années, l’édition libre existe. Elle fut d’abord limitée aux plateformes UNIX et X11, puis s’est progressivement ouverte, notamment pour Windows et diverses systèmes embarqués. De même, la licence a évolué : depuis une licence non standard, de plus en plus libre avec les versions (qui se souvient de la QPL ?), Qt 4 est passé à la GPL 2, ce qui a eu pour effet d’éliminer les conflits juridiques qui empêchaient d’utiliser Qt dans une application GPL, avec une mise à jour vers la GPL 3 dès sa diffusion par la FSF. L’une des principales fonctionnalités de ces licences est d’imposer que les logiciels dérivés (soit tout utilisateur) publie son code source sous la même licence (« licence virale »). En 2009, Qt 4.5 devient disponible sous la LGPL 2.1 : la licence commerciale n’est plus requise pour un développement fermé, la LGPL n’impose plus la licence sur les produits dérivés.

Cependant, cette version de la LGPL n’est pas parfaite : on peut lui reprocher de n’être pas assez claire au sujet des modifications de la bibliothèque, Qt en l’occurrence. Ainsi, bien qu’en violation totale de l’esprit de la licence, certains constructeurs interdisent l’installation de versions modifiées de la bibliothèque sur leurs appareils. La FSF a corrigé cette faille dans la LGPL 3, qui formalise de manière juridique l’intention première, ce qui protège mieux la liberté des utilisateurs. C’est pour cette raison que Digia proposera Qt 5.4 également sous licence LGPL 3, en plus de la LGPL 2.1 et de la licence commerciale.

Nouveaux modules

Cependant, certains modules de Qt ne seront disponibles qu’en LGPL 3 et sous une licence commerciale, comme le nouveau Qt WebEngine (pour l’édition libre). D’autres nouveaux modules pourront être libérés (alors que Digia ne les prévoyait que dans l’édition commerciale !), comme Qt Canvas3D (support complet de WebGL à l’intérieur de Qt Quick) ou Qt WebView (intégration assez légère du moteur de rendu Web natif dans Qt, actuellement uniquement pour Android). De même, le style Android pour les Qt Quick Controls sera disponible : il posait problème avec la LGPL 2, puisqu’il utilise des composants sous licence Apache 2.0, une licence incompatible, mais pourra être intégré grâce à la LPGL 3.

Impact sur les utilisateurs de Qt

Tous ceux qui utilisaient Qt sous la licence GPL 3 n’auront aucun souci à se faire, étant donné la compatibilité avec la LGPL 3. Tous les modules de Qt 5.3 seront toujours disponibles sous LGPL 2.1, ce qui ne posera aucun problème. Par contre, si vous mettez à jour vers Qt 5.4 et utilisez l’un des nouveaux modules, disponible uniquement en LGPG 3, vous devrez vous plier aux exigences de la nouvelle version.

Impact sur KDE

Lors du lancement du projet KDE, un environnement de bureau libre entièrement basé sur Qt, un accord juridique a été établi entre Trolltech (qui développait Qt) et KDE e.V. (l’entité légale derrière KDE), afin de s’assurer que Qt reste toujours disponible sous une licence libre : l’idée est que, si le projet quittait la scène du libre, le code puisse toujours évoluer, sans remettre en question KDE (cette utilisation d’une bibliothèque pas entièrement libre a été un frein à son adoption à la fin des années 1990). Cet accord est géré par la KDE Free Qt Foundation, administrée tant par KDE e.V. que par Digia.

Ce changement de licence est une occasion d’améliorer le contrat liant ces deux entités. Notamment, toutes les plateformes, mobiles ou non, y sont intégrées (soit Windows, OS X, iOS, Windows RT, actuellement). Également, la fondation reçoit les droits sur toutes les contributions au Qt Project.

Voir aussi les textes de licence : GPL 3, LGPL 3.

Sources : Adding LGPL v3 to Qt, Protecting Software Freedom – the Qt License Update

Unification de l’écosystème Qt

Les dernières années furent relativement mouvementées pour Qt : le passage de Trolltech à Nokia, la création du Qt Project, puis le passage de Nokia à Digia, bientôt la création d’une société indépendante de Digia (mais toujours entièrement contrôlée par Digia) qui s’occupera exclusivement de Qt. Les objectifs de Trolltech et Digia sont fort similaires : Qt est un produit qu’ils vendent, les revenus servant à développer l’outil, à l’améliorer, le résultat étant visible tant dans l’édition gratuite (open source) que commerciale. D’ailleurs, actuellement, les trois quarts des modifications du code proviennent d’employés de Digia ; en plus de gérer une grande partie de l’infrastructure hébergeant le projet, Digia est donc la première société à contribuer au projet Qt.

Cependant, les versions commerciale et libre ont commencé à diverger : outre le fait que l’édition payante offre, en sus du support, une série de bibliothèques (Qt Quick Entreprise Controls, Charts, Qt Quick Compiler, etc.) et est adaptée aux plateformes embarquées (QNX, VxWorks, etc.), les installeurs et même les sites Web sont différents (http://qt.digia.com/ pour l’édition commerciale, https://qt-project.org/ pour le libre). Par conséquent, ces deux éditions entrent en compétition directe l’une avec l’autre, se présentant comme des produits opposés, avec des difficultés pour passer d’une édition à l’autre.

Pour réduire cette fracture, Digia s’apprête à créer une nouvelle société, dont le seul objet sera le développement de Qt. Elle sera cependant entièrement administrée par Digia. En même temps, le site Web côté Digia pour Qt sera retiré, au profit d’un site unique pour les deux éditions, qui donnera alors une vue plus large de l’écosystème Qt, en comparant les éditions libre et payante. Également, les paquets d’installation seront rationalisés, avec un seul installateur pour les deux éditions : la migration d’une édition à l’autre sera plus simple, tout en réduisant la charge de travail lors de chaque version. L’objectif est de fournir des paquets mieux testés et donc de meilleure qualité (il ne faudra plus tester les deux séparément).

Le plan a d’ores et déjà été discuté lors du Qt Contributor Summit, qui s’est déroulé en juin dernier à Berlin, avec les principaux contributeurs : les premiers éléments devraient être visibles avec la sortie de Qt 5.4. L’inconvénient, déjà reporté par la communauté, serait une plus grande difficulté de distinguer le contenu réservé à l’édition commerciale, payante.

Sources : Defragmenting Qt and Uniting Our Ecosystem, Digia to Streamline its Organizational Structure

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/