Cela fait un petit moment que les nouveautés du moteur pour l’année 2018 sont annoncées (cf. notre article sur le nouveau calendrier de sortie des versions), notamment depuis la dernière GDC. Cependant, les fonctionnalités promises n’étaient qu’en version bêta, jusqu’au 2 mai.

La version 2018.1 d’Unity n’est plus en bêta… Et elle apporte son lot de surprises !

Cette nouvelle version est perçue comme l’une des plus chargées en nouveautés depuis longtemps. Et il y a de quoi : Scriptable Render Pipeline, Shader Graph, ECS, … Oui d’accord, je sens bien qu’il va falloir clarifier un peu tout ça.

Avant de faire le tour des principales fonctionnalités proposées dans cette version, il faut tout de même que vous soyez prévenus : certaines fonctionnalités sont encore marquées « preview », ce qui signifie qu’elle ne sont pas prêtes à être utilisées dans un environnement de production.

SRP : Scriptable Render Pipeline (Preview)

Jusqu’à maintenant, le moteur ne proposait que deux pipelines de rendu : le Forward Rendering et le Deferred Rendering. Ces deux modes sont en quelque sorte des ensembles de réglages indiquant au moteur de quelle façon les objets, les lumières, etc. sont traités, depuis le code jusqu’à devenir des pixels sur vos écrans. Ces réglages vont jouer non seulement sur le rendu en lui-même, mais également les performances du jeu. Mais il n’est pas possible de les modifier, en tous cas pas finement.

Cette problématique est résolue avec cette nouvelle version 2018.1. En effet, Unity rend scriptable le pipeline de rendu à travers une API en C#, ce qui permet non seulement de voir, mais également de modifier le comportement du pipeline de rendu.

A titre d’exemple, cette fonctionnalité est accompagnée de deux implémentations, disponibles d’ailleurs comme templates à la création d’un nouveau projet :

• Le High Definition Render Pipeline (HD RP), fait pour exploiter au maximum le hardware récent (PC supportant DirectX 11, PS4, XBox One, …)
• Le Lightweight Render Pipeline (LW RP), fait pour le mobile et les applications exigeant beaucoup de performances (comme la réalité virtuelle ou augmentée)

C# Job System et ECS (Entity Component System)

La combinaison de ces deux nouveautés bouleverse un peu la façon dont on organise le code et les objets d’un projet Unity.

L’Entity Component System

Commençons par l’ECS. Historiquement dans Unity, on a toujours utilisé les composants. Le code de ces composants hérite généralement de « god classes », des classes contenant tout un tas de propriétés et de fonctionnalités telles que MonoBehaviour. Or, un composant dispose souvent d’outils dont il ne se servira jamais, de par cet héritage.

L’Entity Component System répond à cette problématique, en permettant une approche plus « data-driven« . L’idée étant d’avoir d’une part des données ou collections de données, et de l’autre d’avoir un système qui n’exploitera que les données qu’il utilise et dont il est sûr d’avoir besoin. Cette approche permet d’avoir un code plus léger et mieux organisé. Par ailleurs, séparer les données des entités qui les exploitent facilite également la parallélisation d’opérations…

Le C# Job System

En parlant de parallélisations, c’est là que les Job Systems de Dotnet entrent en jeu. Cette nouveauté exploite au maximum les processeurs multicores en parallélisant des opérations (ou jobs), en offrant une protection contre les « pièges » du multithreading (race conditions, deadlocks, …).

Paralléliser des opérations va permettre de beaucoup gagner en performance. Par ailleurs, autre nouveauté, Unity Technologies a intégré le Burst Compiler, qui travaille directement sur les jobs. L’idée étant que lorsque vous travaillez avec les C# Jobs, Burst récupère ces jobs et optimise leur code, en fonction des capacités de la plateforme sur laquelle le jeu a été produit. Cela permet d’avoir un code source très rapide et performant en tirant pleinement avantage de la plateforme ciblée.

Notez que l’ECS et le Burst Compiler sont marqué « Preview », et ne sont pas prêts à être utilisés en production.

Shader Graph (Preview)

Pour réaliser des shaders sur Unity, vous vous êtes peut-être essayé au ShaderLab. A moins que vous ne vous soyez épargné des heures de prises de tête sur les sciences obscures du scripting de shaders avec des plugins comme ShaderForge ou Amplify (deux plugins de scripting nodal pour la création de shaders).

Alors qu’Unreal Engine 4 est équipé de son Material Editor depuis sa sortie, Unity dispose enfin d’un outil de scripting nodal de shaders. Cette fonctionnalité fait partie des fonctionnalités inscrites dans la Roadmap d’Unity depuis longtemps, naturellement très demandée par les designers.

Je me suis amusé à traduire le shader « pseudo random noise » de Shaders Laboratory avec ce nouvel outil, et je dois admettre qu’il est très facile à utiliser.

D’ailleurs, si la notion de Shader vous échappe, je vous invite à revoir le MUUG#505 d’Anthony Blachet sur les shaders. C’est d’ailleurs à lui que l’on doit la chaîne Shaders Laboratory.

Petit dernier pour la route : 2D SpriteShape (Preview)

Dans le genre outil sympathique pour faire un jeu en 2D, le package 2D SpriteShape se pose là. Il permet de donner à des sprites une forme particulière en suivant une courbe, et remplir la forme tracée avec un sprite tileable qui se répète. Si vous avez déjà utilisé un plugin comme Ferr 2D Terrain Tool, le principe est le même.

Et tout plein d’autres nouveautés…

La liste des fonctionnalités ne s’arrête pas aux quelques unes exposées ci-dessus… Il y en a beaucoup plus, et je vous invite à les découvrir sur le post officiel de la sortie d’Unity 2018.1.