Cette session présente:
- les différents types d'expérience VR/AR/MR
- les différents casques et dispositifs
- le workflow de création d'un projet Mixed Reality
- les notions essentielles pour la MR et Unity
- les configurations optimales pour versionner un projet Unity (Yaml, MergeTool, LFS...)
- les outils de développement industriel pour faire un code maintenable (unit tests, unity test, mock, injection...)
- les bonnes pratiques d'architecture du code
La version complète est disponible sur : https://jaayap.github.io/Unity_Best_Practices/
Une étude dédiée aux casques Virtual Reality par cas d'usage est disponible sur : https://blog.octo.com/casques-vr-pour-votre-projet/
Session présentée à la conférence Rebuild 2018 Nantes par Jasmine Lebert et Vincent Guigui
La réalité augmentée : qui ajoute du contenu informatif, des pixels (de la lumière) et du son à des environnements, avec une relation interactive limitée.
La réalité virtuelle qui bypass la vraie réalité au profit d’une réalité faite de pixels et de sons. Immersion totale et isolement idoine.
Outils / logo automatisation : meshlab / simply gone
Exporter des fichiers dans un format générique (.fbx) permet d’avoir un fichier moins volumineux qu’un fichier propriétaire (.3ds)
Chaque personne du projet doit avoir une licence du logiciel sur sa machine ( 3DS max)
.dae (Collada),
Export 2 morceaux si on veut bouger l’ance
Format des textures : TARGA ou PNG
Trouver shader dédier Mobile et MR
warning : compatibilité / différence des versions / course entre les diff logiciels
Unity reactif / mrtk aussi / windows sdk : trois logiciel en perpetuelle évolution
Attention mise a jour
Recommandation actuelle (unity / microsoft / MRTK)
Structure de document / panneau de propriété / console / solution explorer /
Schema exemple smartmerge
Comment ça marche ?
Il faut configurer un merge tool dans git : dans le fichiers git config on va mettre un lien vers un .exe fournit avec l’installation de unity
Comment ça marche ?
Il faut configurer un merge tool dans git : dans le fichiers git config on va mettre un lien vers un .exe fournit avec l’installation de unity
permettent de repérer rapidement les régressions ou les mauvais comportements.
Rédiger des tests unitaires sert à vérifier le comportement du code
Add : plus de tech / clean archi
KISS : Keep It Simple & Stupid,
principe de la responsabilité unique (un élément possède qu’une seule raison d’être modifié).
YAGNI : You Ain’t Gonna Need It,
essayer d’anticiper les problèmes futurs, n’est pas une bonne idée. Il est préférable de s’occuper du présent et de ne pas faire d’hypothèse sur ce que l’application pourrait utiliser.
- SRP (Single Responsibility Principle)
Ne faire qu’une seule chose mais la faire bien. Une classe doit avoir une et une seule raison de changer.
- OCP (Open-Closed Principle)
Une classe doit être ouverte à l’extension mais fermée à la modification (plugins)
- LSP (Liskov Substitution Principle)
Toutes implémentation d’une interface doit pouvoir se substituer à une autre
- ISP (Interface Segregation Principle)
Une classe ne doit implémenter une interface que si elle a réellement le besoin de remplir son contrat
- DIP (Dependency Inversion Principle)
Le code ne doit pas interagir directement avec l’extérieur mais doit passer par des abstractions (et vice versa).
Robert C.Martin (uncle bob)
« Always leave the code you’re editing a little better than you found it »
Domain : Métier, cœur de l’application
Infrastructure : « port and adapters »