Interview avec Valerie DOGNIN, Product Owner, et Geoffroy Lacarrière, Ingénieur Etudes Développement C++ chez AVSimulation
Pouvez-vous m’expliquer ce qu’est unreal ?
G. Lacarriere: Unreal est principalement un moteur 3D, mais c’est aussi un certain nombre d’outils autour de ce moteur 3D qui facilitent la création d’applications 3D, à tout niveau ; récupérer des éléments graphiques et faire le traitement des optimisations qu’on va ensuite pouvoir afficher à l’écran.
Utilisez-vous Unreal chez AVSimulation ?
G. Lacarriere : Aujourd’hui, oui. Avant l’utilisation d’Unreal chez AVSimulation nous utilisions un moteur du nom d’OpenSceneGraph. C’est un ancien moteur qui commence à devenir complètement obsolète, qui nous limite sur beaucoup de sujets sur lesquels nous aimerions évoluer. C’est ce qui demande beaucoup de temps, d’énergie, et de développement pour faire des choses qui ne sont pas natives au moteur OSG mais qu’ils le sont presque pour Unreal. OSG a accumulé un retard technologique qui au fur et à mesure des années ne rattrapera jamais l’état actuel des avancées en matière de 3D, de photoréalisme…
Le retard dans l’avancée du moteur OSG a donc déclenché votre besoin de changement de moteur ?
G.Lacarriere : Effectivement, notre objectif est d’arriver à l’image 3D la plus photoréaliste possible, aussi bien en matière de rendu visuel, pour les utilisateurs de simulateurs, mais également sur toute la notion de capteurs pour être le plus représentatif.
Lorsque vous avez commencé à chercher un nouveau moteur. Qu’est-ce qui a fait que vous avez choisi Unreal et non pas un autre moteur ?
G. Lacarriere: Nous avons effectué un comparatif des moteurs existants qui allaient offrir plus d’avantages à nos utilisateurs dans l’industrie de la 3D. Unreal est arrivé dans le top 3 des moteurs que nous avions sélectionnés. Il avait un avantage par rapport à d’autres moteurs du type Unity: Il était codé en C++ et en open source pas les autres.
On avait à la fois un côté technique et à la fois un côté pratique, dans le sens où nos équipes de développement connaissent le C++ et l’aspect open source. Cette connaissance représente un intérêt pour notre client car nos développements sont plus stables et rapides. Nous étions rassurés par le fait qu’on puisse changer ou comprendre comment est fait le moteur en interne.
Êtes-vous sur une utilisation complète d’Unreal ?
V. Dognin : non, nous sommes encore dans la phase qui va durer quelques années. Pour le moment seul le module visuel et camera sensor se voient mis à jour sous Unreal. Dans les années à venir il y aura Terrain et SCANeR Studio. Le but, à long terme est d’avoir transitionné tout OSG vers Unreal
Qu’est-ce qui est actuellement le plus challenging dans cette phase de transition ?
G. Lacarriere: C’est la cohabitation avec l’ancien moteur, pour l’instant on ne peut pas changer de l’un à l’autre. On a tout un écosystème qui est encore très dépendant de l’ancien moteur, ce qui oblige une cohabitation des deux moteurs le temps de la transition. Ça amène des contraintes. Une des contraintes concerne les assets 3D qui sont construit et formatés pour l’usage de l’OSG mais qui auront un formalisme différent pour Unreal afin de profiter complètement des performances du moteur.
On ne peut pas encore utiliser la technologie Unreal partout , nous sommes obligés de la restreindre un peu le temps de, pour le moment il y a cohabitation le temps de la transition
Pouvez-vous faire des simulations sur le moteur Unreal ?
G. Lacarriere: Oui, tous les scenarios actuels de conduite ou autres sont compatibles. Le visuel fonctionne, les caméras, les sensors fonctionnent, mais pour l’instant, pour la partie Unreal ça s’arrête là. On a du warping-statique, le warping-dynamique est en cours d’intégration. Il y a plein de petites choses comme ça. Mais oui, il est possible de lancer une simulation pour le besoin par exemple d’un rendu visuel avec quelques avec quelques capteurs. Mais si, le besoin est plus avancé on utilisera l’ancien visuel qui se trouve sur l’OSG. Dans l’attente d’être 100% isofonctionnel avec l’ancien visuel nous recommandons d’utiliser le visuel Unreal comme une preview. Mais nous couvrons d’ores et déjà plus de 80% du scope fonctionnel sur ce nouveau visuel Unreal. Dans l’attente d’être 100% isofonctionnel avec l’ancien visuel nous recommandons d’utiliser le visuel Unreal comme une preview.
De ce qu’on peut voir et lire Unreal est bien plus qu’un moteur 3D. C’est une plateforme de développement. Avez-vous l’intention d’utiliser Unreal pour développer vos propres capteurs, caméras, et si oui quel serait l’avantage ?
G. Lacarriere : Unreal contient beaucoup d’outils de gestion et d’analyse de la 3D, de la lumière, de colorimétries, d’effets visuels, des passes de rendus, des optimiseurs, de profiling…et autres qui seront utiles à tout nouveau développement.
V. Dognin : Nous ne sommes pas fournisseurs de capteurs, notre but n’est pas de faire nous-mêmes les capteurs, mais de fournir aux utilisateurs la possibilité de tester les capteurs, d’avoir les bons paramètres de configuration qui représenterons leurs capteurs. Il est probable que nous proposions des exemples pour que les utilisateurs puissent avoir une idée du rendu.
G. Lacarriere : Dans le moteur 3D, il y a le but d’afficher une image réaliste. Le capteur caméra va lui analyser cette image qui permettra d’avoir une image plus Réaliste. Pour le développement du capteur, ça va être plus intéressant d’avoir plus de détails à analyser. Éventuellement plus de conditions météo, des effets de perturbations, ce qui est très intéressant pour le développement d’un capteur qui n’aurait pas été possible ou bien, moins possible avec l’ancien moteur.
Dans la version 2021.1 de SCANeR avez-vous tout porté sous Unreal ?
G. Lacarriere : Non, malheureusement, cela n’est pas encore ISO fonctionnel. Mais le but, c’est d’arriver à être feature complète sur l’équivalent de l’ancien visuel et de proposer aussi des améliorations et d’autres évolutions futures que ne permettaient pas l’ancien moteur.
Les utilisateurs peuvent-ils utiliser Unreal dans un simulateur ?
G. Lacarriere : lorsqu’il s’agit d’un simulateur simple qui utilise du Warping statique, oui. Mais dans un simulateur avec du motion non.
quand pensez-vous que cela sera disponible ?
V. Dognin : Le warping-dynamique sera pour la prochaine sortie, la 2022.1 de SCANeR, une fois que cela sera fait, on pourra simuler sur de plus gros simulateurs.
Vous avez mentionné que la fonction headlights était, pour l’instant, limitée sous Unreal. Aavez-vous pour projet de la faire évoluer ? Si oui, quand et quels seraient les avantages pour les utilisateurs ?
V. Dognin : Dans l’idéal, on aimerait le faire cette année, mais je ne pense pas que nous aurons le temps de tout finaliser. Pour avoir toutes les fonctionnalités de SCANeR aujourd’hui portées sur Unreal ce sera plutôt l’an prochain.
Quel est le processus pour mettre headlight à jour dans Unreal ? Quelles contraintes cela implique ?
V. Dognin : Aujourd’hui, nous avons différents outils qui permettent de paramétrer Headlights, ce qui n’est pas simple. En effet, cela demande beaucoup de métier, et c’est toute cette couche métier qu’il faut que l’on ajoute à Unreal, pour avoir à la fois la qualité de rendu, mais ne pas perdre aussi toute la connaissance métier qu’on a acquis jusqu’à aujourd’hui, et depuis 20 ans. Le challenge est d’amener toute cette couche métier, dans ce que Unreal fait déjà. On se pose beaucoup de questions, sur ce qui existe déjà dans Unreal, ce que nous avons déjà acquis, ce que l’on pourrait exploiter, ce qu’il faut qu’on refasse.
G. Lacarriere : Aujourd’hui, on a besoin de paramétrer le visuel pour être en mode headlight pour activer beaucoup plus d’options de calcul, de lumière et d’autres. C’est ce que qu’on cherche à avoir de manière native sur le moteur Unreal. Le développement du headlights va nous permettre d’être plus proche du rendu réaliste sans avoir forcément besoin d’un mode particulier. C’est-à-dire que le mode Headlight, à terme, sera le mode de rendu par défaut.
Avez-vous recontré des contraintes lors de la transition de moteur Unreal avec l’ancien ?
G. Lacarriere : Au début, oui, il y avait des contraintes, que l’ancien moteur imposait dont on ne pouvait se détacher et qui nous ont freiné sur le développement. Mais petit à petit, on a fait sauter les verrous, pour développer des outils qui permettaient de s’abstraire de ce genre de contrainte. Notamment sur tout ce qui concerne les modèles 3D de véhicules qu’on a à disposition, à défaut d’avoir des infographistes sous la main pour pouvoir faire des modifications ou des mises à jour des modèles 3D. Une autre contrainte, le besoin d’un rendu réaliste dans Unreal, et pour ça il nous fallait des améliorations graphiques. Ce dont nous n’avions pas besoin dans l’ancien moteur car il ne gérait pas certains effets.
Pour éviter d’avoir un nouveau moteur 3D affichant un visuel qui paraît être déjà daté, il fallait qu’on ait une couche de mise à jour. Il a fallu développer des petites astuces pour utiliser les vieux modèles 3D pour les mettre en haute définition.
Les clients SCANeR 2021.1 ont-ils le choix entre l’utilisation de l’ancien modèle et Unreal ? Ou bien cela est imposé par le logiciel ?
V. Dognin : Pour l’instant, les deux sont toujours présents dans la 2021.1 et ce sera probablement toujours le cas pour la 2022.2. Tant que nous n’aurons pas une ISO fonctionnalités entre notre ancien moteur et le nouveau, on n’enlèvera pas l’ancien. On ne veut pas pénaliser les utilisateurs dans nos choix de transformation.
G. Lacarriere : On indique que le visuel Unreal est une preview. C’est-à-dire que les utilisateurs de SCANeR continuent d’utiliser le visuel actuel, mais ont déjà un aperçu de ce que sera le prochain visuel.
Comment cela se passe pour les clients qui décident de travailler sur Unreal, les scènes sont-elles automatiquement optimisées ou alors faut-il faire un travail pour les rendre photo-réalistes ?
G. Lacarriere : alors, je serais amené à dire les deux, nous avons une passe automatique, qui va essayer d’améliorer les choses. Ça dépend réellement de la donnée source. Ça dépend également de comment l’infographie a été faite et si les règles de nommage ont été respectées.
Ce qui va se passer, c’est qu’on va essayer de reconnaître des éléments, quand on les reconnaît, on les améliore par une version, une nouvelle génération. Pour la partie automatique, si cette détection ne marche pas, on arrive à afficher l’élément en l’état mais sans les améliorations. On donne la possibilité aux utilisateurs avancés de venir refaire une passe avec l’éditeur Unreal pour pouvoir améliorer leurs assets et intégrer les nouveaux s’ils le souhaitent et ainsi pouvoir afficher tout ça comme si c’était d’origine.
Un mot de conclusion ?
G. Lacarriere : Un mot-clé sur le moteur 3D, qui est la raison du pourquoi on se conditionne à cette nouvelle génération : PBR « Physically based rendering », c’est la raison principale des changements de moteur, technologiques et changement de génération. Avant, il y avait une manière de calculer la 3D qui n’était pas réaliste et qui s’accoutumait de certains paramètres pour essayer de rendre ça plus crédible. Avec PBR, il y a un paradigme qui a changé, on a décidé que pour arriver à du photoréalisme, il fallait se baser sur des valeurs physiques. Se baser sur du réel pour simuler le réel. C’est ça qui permet d’avoir cet aspect vraiment différent dans la 3D.
| Si vous voulez en savoir plus à propos de Unreal Engine et AVSimulation, cliquez sur le lien suivant et découvrez l’article de Epic Games: Multi-purpose car simulation environment gets a boost from Unreal Engine – Unreal Engine |