Qt 5.10 accueillera Vulkan : les premiers pas

Les discussions pour une première gestion de Vulkan dans Qt ne sont pas récentes : elles datent de 2016 sur le gestionnaire de tickets du projet, avec les premiers résultats attendus pour Qt 5.10, en fin de cette année 2017.

Ceci se passe dans un contexte double : d’un côté, Vulkan a été développé comme successeur à OpenGL, pour exploiter au mieux les cartes graphiques (notamment pour la réalité virtuelle et des applications aussi gourmandes) ; de l’autre, Qt 5.8 avait pour nouveauté majeure côté Qt Quick une refactorisation du moteur de rendu du graphe de scène, pour le découpler d’OpenGL, avec de premiers travaux pour utiliser Direct3D 12 (l’équivalent Vulkan de Microsoft) pour le rendu de scènes Qt Quick.

Un premier objectif pour faciliter l’utilisation de Vulkan avec Qt est de fournir une série de classes (comme les QOpenGL) qui facilitent l’écriture de code portable. Notamment, la création d’une surface de rendu Vulkan est loin d’être aisée en devant gérer toute une série de plateformes :

QWindow *window;

#if defined(VK_USE_PLATFORM_WIN32_KHR)
    VkWin32SurfaceCreateInfoKHR createInfo;
    createInfo.hwnd = (HWND) window->winId();
    ...
    err = vkCreateWin32SurfaceKHR(...);
#elif defined(VK_USE_PLATFORM_WAYLAND_KHR)
    VkWaylandSurfaceCreateInfoKHR createInfo;
    ...
    err = vkCreateWaylandSurfaceKHR(...);
#elif defined(VK_USE_PLATFORM_ANDROID_KHR)
    VkAndroidSurfaceCreateInfoKHR createInfo;
    ...
    err = vkCreateAndroidSurfaceKHR(...)
#elif defined(VK_USE_PLATFORM_XCB_KHR)
    VkXcbSurfaceCreateInfoKHR createInfo;
    ...
    err = vkCreateXcbSurfaceKHR(...)
#elif ..

Il serait nettement plus pratique (et orienté Qt) d’écrire un code concis et compréhensible comme :

QWindow *window;
VkSurfaceKHR surface = QVulkanInstance::surfaceForWindow(window);

Une gestion de Vulkan dans Qt, même basique, faciliterait donc grandement cette étape très importante dans l’utilisation de l’API. C’est donc le premier objectif de ce nouveau module Qt Vulkan et des classes QVulkan.

Un deuxième objectif à court terme pour ce module est de fournir une abstraction pour une fenêtre dont le rendu est entièrement effectué par du code Vulkan, tout comme QD3D12Window et QOpenGLWindow. Certes, ces classes ont quelques limitations, mais facilitent la prise en main. Ainsi est arrivée QVulkanWindow.

Par contre, pour Qt 5.10, les objectifs ne sont pas beaucoup plus élevés que cela. Notamment, l’API Vulkan n’est aucunement cachée à l’utilisation : Qt aide à créer des fenêtres, à gérer les différences entre plateformes et à charger dynamiquement les fonctions de Vulkan. La nouvelle API n’est, pour le moment, pas du tout utilisée dans des modules comme Qt Quick, Qt 3D, Qt Canvas 3D, QPainter : cela pourrait venir dans le futur, mais pas pour Qt 5.10. Des fenêtres Vulkan peuvent être combinées avec des interfaces à base de widgets à l’aide de la fonction bien connue QWidget::createWindowContainer(), tout comme des fenêtres OpenGL.

Au niveau des plateformes, Qt Vulkan peut être utilisé sous Windows (quand le SDK LunarG est installé et définit la variable d’environnement VULKAN-SDK), Linux (avec xcb, pas encore Wayland) et Android (avec les API de niveau 23 et 24, même si les en-têtes Vulkan ne sont disponibles que depuis le niveau 24).

Les bibliothèques Vulkan sont chargées dynamiquement, c’est-à-dire à l’exécution : il n’est nécessaire que de disposer des en-têtes de Vulkan (une version assez récente, au moins la 1.0.13) lors de la compilation de Qt, pas plus. Dans un futur proche, certaines configurations de test pourraient venir avec une bibliothèque Vulkan, mais ces détails sont en cours de fignolage et devraient être corrigés d’ici à la sortie de Qt 5.10.

Source : Vulkan Support in Qt 5.10 – Part 1.

Les dernières nouveautés de NVIDIA GameWorks

À la GDC 2017, NVIDIA aura annoncé une nouvelle carte graphique pour joueurs, extrêmement puissante et avec un tarif raisonnable (la GTX 1080 Ti est plus puissante que la Titan X Pascal, mais à un prix presque réduit de moitié), mais également toute une série de nouveautés dans ses produits pour développeurs de jeux, rassemblés sous la bannière GameWorks. Il s’agit notamment d’effets et de simulations physiques prêtes à l’emploi.

De manière générale, bon nombre de produits GameWorks deviennent compatibles avec DirectX 12, proposent une implémentation Direct Compute en plus de CUDA (ce qui permet d’utiliser l’accélération graphique avec des cartes AMD, mais uniquement sous Windows), ainsi que l’ouverture du code source d’une série de bibliothèques supplémentaires.

DirectX 12 pour les développeurs

La grande différence entre les versions 11 et 12 de DirectX est le niveau d’abstraction : il faut moins de code pour un même effet avec DirectX 11, le pilote graphique s’occupe de l’optimisation d’une série de primitives de haut niveau (qui déchargent donc le programmeur d’une grande partie du travail). Au contraire, avec DirectX 12, le programmeur récupère une énorme flexibilité, mais doit effectuer le travail que le pilote n’effectue plus.

Les possibilités d’optimisation sont donc bien plus grandes, mais les risques également. NVIDIA travaille sur les deux fronts : proposer de nouveaux outils de développement et préparer toutes ses bibliothèques GameWorks pour DirectX 12. Côté outils, Nsight 5.3 apporte la compatibilité avec DirectX 12 et certains casques de réalité virtuelle. PIX, le débogueur visuel DirectX de Microsoft, peut également lire les compteurs de performance des cartes graphiques GeForce.

NVIDIA annonce aussi un nouvel outil : Aftermath, une bibliothèque à intégrer aux jeux afin de déboguer plus facilement les cas de crash. Le principe est d’introduire des marqueurs à intervalle régulier dans le code, où l’état du GPU est sauvegardé. Lors d’une analyse après crash, il devient possible de remonter la ligne du temps au niveau de ces marqueurs. Au niveau de la performance, Aftermath est extrêmement léger : il n’a pas d’impact mesurable sur un jeu. Il peut donc être inclus dans des jeux en production, sans être cantonné au niveau du test.

Nouveautés GameWorks

Une nouvelle version de FleX, le moteur de simulation de particules unifié, est apparue : la 1.1.0 peut exécuter ses calculs sur un processeur graphique par CUDA ou par Direct Compute ; cela ne veut pas dire que CUDA est abandonné, puisque FleX est maintenant compatible avec la version 8.0. Quelques fonctionnalités ont été ajoutées, l’API a été uniformisée avec d’autres bibliothèques physiques de NVIDIA.

Bien évidemment, FleX est maintenant compatible avec DirectX 12. En particulier, la bibliothèque peut tirer parti des fils d’exécution asynchrones pour lancer ses calculs quand le GPU est moins utilisé par le rendu graphique.

Flow est une nouvelle bibliothèque pour le rendu et la simulation de volumes, principalement de la fumée, du feu, des fluides enflammés. Elle remplace et généralise Turbulence et FlameWorks.

HairWorks, pour la simulation de poils et de cheveux, apporte principalement la possibilité d’utiliser la bibliothèque avec DirectX 12 (la version 1.3 est d’ores et déjà disponible sur GitHub, mais pas encore ailleurs).

Le module de destruction, autrefois connu sous le nom de APEX Destruction, a été complètement réécrit pour pleinement profiter des cartes graphiques modernes, tout en laissant la plus grande flexibilité aux développeurs. Blast se focalise sur l’implémentation de la destruction des objets, pas de la simulation physique en général ou de l’affichage : ces points doivent être gérés par l’application (évidemment, un module d’extension intègre Blast dans le moteur physique maison, PhysX). Côté simulation, les contraintes sont simulées de manière bien plus détaillée qu’à l’époque APEX Destruction, ce qui permet de créer les fissures aux endroits les plus faibles. (Plus de détails sur le site officiel.)

De manière similaire, APEX Clothing laisse la place à NvCloth. La bibliothèque semble avoir été réécrite pour plus de flexibilité, comme Blast, avec une compatibilité DirectX 11 et 12, les solveurs pouvant fonctionner indifféremment sur CPU ou sur GPU.

Libération du code source

La libération du code source de GameWorks est une opération de longue haleine, débutée en 2015. NVIDIA continue dans la lignée, avec plus de code disponible. Cependant, les conditions ne semblent pas changer : pas de licence libre, enregistrement obligatoire mais gratuit.

Sources et images : communiqué de presse de NVIDIA, NVIDIA talks DX12, including GameWorks support, GDC 2017: NVIDIA Gameworks goes DX12 and more !.

Annonce de Qt 3D Studio

Qt est un framework à l’origine prévu pour la conception d’interfaces graphiques. Avec les années, il s’est de plus en plus ouvert à la troisième dimension : tout d’abord, en facilitant l’utilisation d’OpenGL dans des interfaces Qt, puis en allant jusqu’à proposer un moteur 3D complet, Qt 3D. Ce petit monde est en passe d’évoluer radicalement grâce à NVIDIA. En effet, le fabricant de processeurs graphiques a fait l’une des plus grandes contributions libres à Qt : leur système de conception d’interfaces 3D à destination des graphiques, NVIDIA DRIVE Design Studio, un outil déjà mis à l’épreuve et utilisé dans bon nombre de systèmes en production à l’échelle industrielle. L’outil est en développement depuis de nombreuses années et, au fil de son existence, a été connu sous les noms de NVIDIA UI Composer ou Anark Gameface.

Cette contribution se chiffre en centaines de milliers de lignes de code (!), avec un outil graphique, la bibliothèque de fonctions utilisée, ainsi qu’une intégration avec Qt (notamment Qt Quick). Qt possèdera donc très bientôt un environnement 3D de très haute qualité, l’un des meilleurs sur le marché. L’outil de NVIDIA sera renommé pour faire référence à Qt plutôt qu’au caméléon (même s’il est lui aussi vert) : Qt 3D Studio.

Une application conçue avec l’outil de NVIDIA peut d’ores et déjà être étendue à l’aide de code Qt Quick, dans tous les sens du terme : on peut intégrer une partie Qt 3D Studio dans une application Qt Quick existante, mais aussi adapter l’interface produite par les graphistes à l’aide de code QML. L’intégration avec Qt 3D est prévue à terme ; actuellement, l’outil utilise son propre moteur de rendu, entièrement découplé de Qt 3D (pour des raisons de performance, il réutilise cependant le contexte OpenGL de la scène Qt Quick).

Le travail ne fait que commencer : le projet Qt n’a reçu le code que cette semaine, il ne sera disponible au grand public que lorsqu’il sera prêt — aucune date n’est avancée pour le moment, mais les premières versions devraient arriver “rapidement”. Actuellement, rien n’est spécifique au GPU utilisé (le code emploie OpenGL ES 2.0, pas d’extension propriétaire de NVIDIA). Cependant, l’éditeur mélange des parties écrites avec Qt et d’autres avec MFC : il faudra réécrire ces dernières pour qu’il soit utilisable sur toutes les plateformes (pas seulement Windows) ; le code de rendu n’a pas cette limitation. La réflexion est lancée pour l’intégration de l’éditeur dans Qt Creator, mais les plans initiaux prévoient de le garder comme outil indépendant.

Cette contribution marque le degré d’importance de Qt dans l’écosystème de l’automobile. Les ambitions de la Qt Company dans le domaine ne sont plus à prouver, après l’annonce l’année dernière de Qt Automotive Suite.

Sources : Introducing Qt 3D Studio, Nvidia spendiert Qt Hunderttausende Zeilen Code, The Qt Company Adopts NVIDIA DRIVE Design Studio.

Le prochain compilateur de shaders de Microsoft est libre

C’est de plus en plus l’habitude du côté de Microsoft : libérer du code source quand cela n’a pas de valeur de le garder privé. Maintenant, c’est au tour de DirectX de voir un de ses composants libéré : plus particulièrement, la prochaine version du compilateur de shaders (de petits fragments de code qui paramètres le rendu à l’écran, notamment les effets spéciaux), d’ores et déjà sous licence MIT.

Ce nouveau compilateur se base d’ailleurs sur une architecture entièrement libre : LLVM (plus connu grâce à Clang, le compilateur C et C++ qui s’axe autour de LLVM). L’objectif est d’arriver à un compilateur fonctionnel plus rapidement, mais aussi de profiter de l’écosystème complet (outils, documentation, expertise, notamment) pour faciliter l’innovation dans le futur. Notamment, LLVM fournit un certain nombre de passes d’optimisation du code, ce qui pourrait améliorer fortement la performance des shaders dans le futur.

Le langage de programmation est HLSL, spécifique à DirectX (OpenGL utilise GLSL). La version SM6 offre quelques avantages syntaxiques par rapport à l’itération précédente, notamment pour profiter de l’architecture de type SIMD des processeurs graphiques actuels : ils sont très performants pour appliquer une même opération sur plusieurs données simultanément. Ceci devrait faciliter l’écriture de shaders pour la suppression d’éléments invisibles, l’éclairage ou encore les opérations d’entrée-sortie.

La sortie de ce nouveau compilateur est une nouvelle représentation intermédiaire, nommée DXIL (c’est le même principe que pour Vulkan et SPIR-V). Elle n’est comprise que par les dernières préversions de Windows 10 (Windows 10 Insider Build 15007).

Cette libération de code source pourrait avoir une série d’effets secondaires. Par exemple, Wine (l’implémentation d’API Windows pour Linux, qui permet donc d’y lancer des applications Windows sans les toucher) aura une brique de moins à implémenter pour DirectX 12. Grâce à d’autres développements autour de LLVM, il devrait être possible de compiler un shader HLSL en SPIR-V et l’utiliser avec Vulkan. Toutes les répercussions ne sont pas encore visibles. Le développement de nouveaux outils par-dessus cette couche libre serait fortement facilité par l’intégration du code de Microsoft dans LLVM, mais cela n’a pas l’air d’être au programme (les passes d’optimisation et la génération du code DXIL y auraient leur place).

Voir le code source sur GitHub.

Source : New DirectX Shader Compiler based on Clang/LLVM now available as Open Source.

Première version publique de PhysX 3.4

PhysX est le moteur physique de NVIDIA, l’un des plus importants sur le marché. À l’origine, le moteur vient d’AGEIA, il portait alors le nom de NovodeX ; la spécificité de la société était de fournir une carte d’extension au format PCI ou PCI-Express, dont le but était d’accélérer les calculs physiques. Depuis lors, NVIDIA a repris le cheval de bataille de l’accélération matérielle, mais avec des cartes graphiques, nettement plus courantes.

Pour la branche 3.x, NVIDIA prévoyait initialement une nouvelle version tous les six mois. Le rythme a été tenu entre les quatre premières versions… puis a été complètement abandonné pour la 3.4 : PhysX 3.3 est sorti fin 2013, il y a trois ans. Sur cette durée, les développeurs du moteur ont laissé paraître quelques indices, notamment au niveau des optimisations, avec récemment une intégration à l’Unreal Engine 4.13. Ils ont aussi été actifs sur d’autres technologies orientées physiques, comme FleX (simulateur de particules unifié), Cataclysm (simulation de liquides), HairWorks (simulateur de cheveux et poils), etc.

La version 3.4 apporte une grande nouveauté au niveau de l’accélération matérielle : la simulation des corps rigides sur GPU (GRB). À part les articulations, toutes les fonctionnalités des corps rigides sont implémentées sur GPU : la simulation, les requêtes sur l’état des corps, l’interaction avec des tissus et des particules, avec la même aisance et la même API que sur CPU. Cette implémentation utilise CUDA (elle n’est accessible que sur des GPU NVIDIA) et requiert un GPU raisonnablement récent (de génération Kepler, c’est-à-dire au moins la série 600) ; sinon, l’implémentation sur CPU est la seule disponible (et elle est nettement plus rapide que celle de PhysX 3.3).

Dans les nouveautés majeures, de nouvelles fonctions ont été ajoutées pour accéder aux détails de la génération des contraintes de contact ; la détection continue de collisions fait son apparition. NVIDIA APEX est maintenant complètement découplé de PhysX : il n’est plus nécessaire d’avoir la moindre parcelle de code PhysX pour utiliser un module APEX (le code commun a été factorisé et se situe en dehors de PhysX).

Au niveau des plateformes, cette version fait le ménage. Ainsi, parmi les consoles, la PS 3, la PS Vita, la XBox 360 et la Wii U ne sont plus gérées, tout comme Windows RT et Android x86. L’accélération GPU nécessite au moins une carte NVIDIA GeForce série 400 et elle n’est plus disponible sur les systèmes d’exploitation plus anciens (Linux 32 bits, Windows XP 64 bits, Windows Vista). Pour le développement, Visual Studio 2010 cède sa place à la 2015 (les versions 2012 et 2013 sont toujours compatibles).

Cette version n’est toujours pas finale : cette étape est attendue pour février. En attendant, le code source est déjà disponible pour les personnes inscrites.

Source : Pre-release version of PhysX SDK 3.4 is now available on GitHub.

Voir aussi : les notes de version.

Sortie de Unreal Engine 4.14

La nouvelle version trimestrielle de Unreal Engine est arrivée. Par rapport à la précédente, cette 4.14 propose de nouveaux effets graphiques, certains spécifiquement prévus pour la réalité virtuelle. Les outils d’animation voient arriver bon nombre d’améliorations, depuis l’arrivée du nouvel éditeur de cinématiques Sequencer avec la version 4.12. Côté mobile, Vulkan est maintenant géré sur les plateformes Android. La compatibilité avec Visual Studio 2017 est aussi arrivée pour Windows (même si la version 2015 reste préférée pour le moment). Le moteur physique inclus, PhysX, a été mis à jour vers la dernière version, ce qui améliore fortement la performance ; de nouvelles fonctionnalités du moteur physique seront intégrées dans les versions à venir du moteur de jeu.

Moteur de rendu en avant

Le nouveau moteur de rendu en avant combine les fonctionnalités d’éclairage avec l’anticrénelage à plusieurs échantillons (MSAA). Avec les optimisations spécifiques aux matériaux à afficher, ce moteur de rendu est particulièrement bien adapté à la réalité virtuelle. Bon nombre de fonctionnalités sont d’ores et déjà gérées, comme :

  • les lumières stationnaires, y compris avec des ombres dynamiques (pour les objets qui se déplacent) ;
  • les réflexions multiples et planaires ;
  • les lumières précalculées et issues des fenêtres de toit ;
  • les lumières déplaçables sans ombres.

Par contre, pas encore de lumières déplaçables avec ombres, d’occlusion ambiante au niveau de l’écran (SSR, SSAO), de translucidité dynamique.

Ombres de contact

La nouvelle fonctionnalité d’ombres de contact donne des rendus très détaillés des ombres dynamiques sur les objets. Elle fonctionne à l’aide de lancer de rayons très courts, pour vérifier dans le tampon des profondeurs si un pixel est touché par une ombre ou pas. Ainsi, la technique permet un rendu précis des points de contact de la géométrie de l’objet avec le rayon.

Génération automatique de niveaux de détail

Auparavant, les éditeurs de contenu devaient générer à la main différent niveaux de détail (LOD) pour chaque modèle 3D, en faisant varier le nombre de polygones à afficher à l’écran tout en gardant un rendu aussi bon que possible. Désormais, Unreal Engine peut prendre en charge cette étape, de manière automatique. L’algorithme implémenté est basé sur des simplifications quadratiques du maillage de l’objet, pour minimiser les différences de rendu en fusionnant des polygones.

Scénarios de lumières précalculées

Dans les applications de réalité virtuelle et de visualisation architecturale, le rendu doit être aussi précis que possible tout en gardant une bonne performance (d’un côté, pour la performance, de l’autre, pour la qualité du rendu). Pour ces cas, Unreal Engine permet maintenant de précalculer toute une série de scénarios d’éclairage d’une scène : par exemple, un scénario de nuit et un autre de jour.

Composant câble amélioré

Les câbles peuvent maintenant avoir un rendu nettement plus réaliste : le moteur de jeu considère leurs collisions avec l’environnement (y compris avec friction) et permet d’y attacher des objets et des effets.

Génération procédurale par bruit vectoriel

Le matériau de bruit est très utile pour la génération procédurale de matériaux. Cependant, jusqu’à présent, il était limité à des valeurs scalaires en sortie. Cette limitation est maintenant levée : le bruit peut être généré en trois ou quatre dimensions. Ainsi, ces nouveaux nœuds permettent de générer de manière aléatoire des couleurs, par exemple. L’inconvénient est qu’ils sont nettement plus coûteux en temps de calcul.

PhysX 3.4

La nouvelle version d’Unreal Engine utilise la dernière version du moteur physique NVIDIA PhysX (3.4). Les améliorations principales de ce côté sont la performance et l’utilisation en mémoire de la simulation des corps rigides et des requêtes dans la scène (plus particulièrement en utilisant plusieurs cœurs pour les calculs). Aussi, la détection de collision en continu (CCD) sur les objets en déplacement rapide est maintenant gérée : par exemple, cela permet de détecter la collision avec une balle à grande vitesse. Les prochaines versions d’Unreal Engine exposeront plus des nouvelles fonctionnalités de PhysX.

Simulation des véhicules

Les déplacements des véhicules n’étaient pas toujours gérés de manière très réaliste : les forces qui s’appliquaient sur les pneus étaient considérées sur le véhicule lui-même et non sur le pneu. Ainsi, le moteur n’arrivait pas à simuler un véhicule qui tanguait. Cette limitation a été levée et les forces des pneus peuvent être directement appliquées sur les pneus.

Source et images : Unreal Engine 4.14 Released!.

Sortie d’Unreal Engine 4.13

L’Unreal Engine nouveau est arrivé, trois mois après le précédent, comme d’habitude. Là où la version précédente se concentrait sur la réalité virtuelle, la version 4.13 s’éparpille plus, même si l’éditeur en réalité virtuelle est toujours l’objet d’une grande attention. Parmi les domaines d’améliorations, on compte cette fois le rendu et l’éditeur de cinématiques, même s’il est impossible de citer toutes les nouveautés en peu de mots.

Éditeur de cinématiques Sequencer

L’éditeur non linéaire de cinématiques apparu dans la 4.12 reste le théâtre d’opérations d’envergure, avec la possibilité d’enregistrer en direct une partie dans le jeu développé. Cette capture n’est pas une vidéo : au contraire, toutes les animations, tous les effets, tous les sons sont mémorisés séparément et peuvent être modifiés dans l’éditeur ! Au moment de cette capture, il est aussi possible de limiter l’enregistrement à une série de composants et de propriétés.

Rendu

Du côté du rendu 3D, les lampes ont vu leur code optimisé : si une lumière ne se déplace pas dans la scène, une bonne partie des calculs déjà effectués peuvent être réutilisés sans problème pour la prochaine image à afficher. Le problème de performance vient surtout du calcul des ombres que crée la lumière (plus précisément, de la carte des profondeurs). Cette optimisation est appliquée automatiquement et ses résultats sont intéressants : pour afficher l’image ci-dessous, avec trente-trois points de lumière, il faut compter 14,89 ms pour l’affichage des ombres ; grâce aux caches implémentés, la même partie prend 0,9 ms d’affichage, ce qui permet d’ajouter d’autres effets (il faut cependant compter deux millisecondes pour l’affichage de la lumière, une contribution qui n’est pas touchée par cette optimisation).

Unreal Engine permet de générer des matériaux de manière aléatoire grâce à des fonctions de bruit. La famille d’algorithmes disponibles s’est agrandie pour recevoir le bruit de Voronoï, très souvent utilisé pour la génération procédurale. Il s’applique notamment très bien à la génération de marbre, le rendu étant très réaliste après un peu de configuration.

Il devient possible de superposer des couches de matériaux sur une topologie statique, ce qui peut avoir un effet de lissage entre les différents calques, sans utiliser de projection.

L’interaction avec des composants d’interface graphique intégrés dans le monde peut se faire avec n’importe quel pointeur laser (pas simplement directement avec la souris). L’action ainsi générée simule celle que pourrait avoir un composant matériel : un clic gauche ou droit… ou toute autre interaction. Cette amélioration vient en support à celles de l’éditeur en réalité virtuelle (voir plus bas).

Les applications mobiles pourront utiliser des effets de type posttraitement, par exemple comme si l’image venait d’une vieille télévision. Ces effets ne peuvent pas encore exploiter toutes les informations disponibles pour le rendu (la profondeur de chaque pixel n’est pas encore accessible), mais cela devrait venir avec une version ultérieure. Ces effets ne sont pas disponibles sur les versions les plus ancestrales d’Android.

Les opérations de pavage des paysages sont maintenant bien plus rapides qu’avant, l’accélération matérielle étant mieux utilisée : cette technique de rendu n’est utilisée que pour les plus hauts niveaux de détail, elle ne l’est plus du tout pour les plus faibles (comme des zones lointaines).

Éditeur en réalité virtuelle

Le nouvel éditeur en réalité virtuelle, apparu pour la 4.12, est toujours l’objet d’une grande attention. Il devient possible de peindre sur des textures existantes, par exemple.

Il permet aussi de peindre rapidement une série d’arbres, en sélectionnant simplement le type de feuillage à créer.

 

Bien évidemment, cette nouvelle version vient avec bien d’autres nouvelles fonctionnalités et optimisations, décrites dans les notes de version.

Source et images : UNREAL ENGINE 4.13 RELEASED!.