Dans quel SDK doit-on mettre les mains?

La fin des billets de blog est en vue, vous allez bientôt connaitre la valeur de retour de cette étude comparative des SDK appliqués à la réalité virtuelle

D’abord, résumons les différents SDK abordés:

Tableau récapitulatif des 5 SDK

Comparatif des SDK pour la RV
SDK
Logo Neoaxis
Neoaxis

Logo Ogre3d
Ogre3D

Logo Unity
Unity

Logo CryEngine
Cryengine

Logo OSG
OpenSceneGraph
Licences
$0 ou $95 à $295 env.

MIT

Propriétaire

0€* ou 20% de royalties

LGPL
Moteur 3D AAA+ AAA+ AAA+ AAA+ AA+
Moteur physique PhysX®, ODE Absent PhysX® Engine Natif Modulable
Rendu sonore 2D/3D, OGG, RTSound Absent FMOD, outils intégrés 2D/3D, natif, RTSound 2D/3D, OpenAL et FMOD
Réseau Oui Non Oui Oui Non
Sorties graphiques 3d, Web browser, 360° 3d, multi-écrans, 360° 3d, CAVE, holobench 3d, standards industriels 3d, multi-écran, CAVE
E/S utilisateurs

  • Joysticks
  • Wiimote
  • Kinect

A la charge des développeurs
  • Contrôleurs
  • Motion Control

  • Joypads (PlayStation)
  • Joysticks/Volants
  • Microsoft Kinect (R)

  • Joysticks
  • volants
  • Motion Control limité
GUI Editable via le SDK, in-game GUI S’interface avec MyGUI ou CEGUI Modulable avec UnityGUI Créées via le SDK Modulable avec Qt
Plateformes
  • Windows
  • MAC
  • Navigateur Web
  • iOS
  • Android
  • GNC
  • Windows
  • Mac
  • Android
  • iOS
  • Linux
  • GNC
  • Windows
  • Mac
  • Android
  • iOS
  • Linux
  • Navigateur Web
  • Flash
  • PS3
  • Xbox 360
  • Wii / WiiU
  • Windows
  • XBox
  • Playstation 3
  • Windows
  • GNU/Linux
  • MacOS/X
  • Android
Langages
  • C# scripts
  • Support libs C/C++
  • CORE
  • C++
  • C# scripts
  • Boo
  • Javascript
  • UnityScript
  • C/C++
  • Pas de script interne
  • C++

Synthèse de chaque SDK


  • Logo Neoaxis

    Neoaxis

    Un SDK très facile à prendre en main, avec de nombreuses possibilités et un large choix
    de sorties graphiques pour la RV, ainsi que des entrées/sorties utilisateurs variées.
    Son principal problème réside dans l’absence de versions autre que Windows et MAC (les version iOS, Android et GNC
    sont en développement, mais ne sont pas encore terminées).
    Cet inconvénient est compensé par une communauté très active sur le forum de Neoaxis, et
    par la sortie régulières de nouvelles versions et un fil d’actualités important.

    SDK Conseillé ! Avec un avenir prometteur.


  • Logo Ogre3d

    Ogre3D

    Ogre est un moteur 3D très utilisé et robuste, avec une communauté très active
    et une forte notiriété.
    Néanmoins, dans le cas de la RV, le temps de développement nécessaire avant de pouvoir l’utiliser est
    très long, ce qui nous amène plutôt à recommander l’usage d’un SDk basé sur Ogre au lieu d’utiliser directement Ogre.

    Moteur 3D déconseillé, les temps de développement étant trop longs.


  • Logo Unity

    Unity

    Ce SDk est très connu dans le monde du jeu vidéo et possède une grande notoriété.
    Il est adapté à la RV, avec une communauté active, mais il est handicapé
    par sa license, assez restrictive dans sa version gratuite et au coût de base
    prohibitif de $1500 pour la version commerciale.

    SDK envisageable, si on a des moyens et qu’on ne souhaite pas attendre que Neoaxis sorte en version Android/iOS.


  • Logo CryEngine

    Cryengine

    Magnifique. Aucun autre mot ne décrirait le rendu graphique réalisé par ce SDK. Les outils de développement
    sont nombreux et bien pensés. La notoriété de Crytek n’est plus à faire depuis
    ces dernières années (après la sortie de la série FarCry ou Crysis). De plus, ce SDK est utilisé dans certains
    logiciels d’architecture. Sa license est clairement orientée vers les jeux-vidéos commerciaux.

    SDK non recommandé pour la RV, mais à envisager pour le développement d’un jeu vidéo.


  • Logo OSG

    OpenSceneGraph

    Un SDK qui avait fait ses preuves… “dans le temps”!
    Aujourd’hui, la communauté est sur le déclin,
    et les dernières nouvelles dates souvent de plus d’un an. Le site n’est également pas le plus simple à prendre en
    mains au début. On remarquera quand même l’existence de livres sur ce SDK,
    ce qui souligne peut-être aussi la grande difficulté que l’on peut avoir à l’appréhender.

    SDK non-recommandé, en tous cas pour les néophytes. De plus, la faible activité de sa communauté
    risque de jouer sur sa durée de vie et sur sa capacité à suivre l’évolution des normes.

Résultat de l’étude

Le classement final des SDK est le suivant:

  1. Logo Neoaxis
    Neoaxis, si le besoin de déployer sur Android n’est pas pressé
  2. Logo Unity
    Unity, s’il faut déployer vite sur de nombreuses plateformes, même si c’est cher
  3. Logo Ogre3d
    Ogre3d, si on a du temps à perdre passer
  4. Logo OSG
    Open Scene Graph, si on est conservateur et qu’on n’a pas peur d’être seul
  5. Logo CryEngine
    CryEngine, si on veut développer un jeu (rien à voir avec la RV donc)

return (new Neoaxis());

Licence Creative Commons
Cette œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution – Partage dans les Mêmes Conditions 3.0 France.
Auteurs: MONIER Vincent, SFEIR Raphael

Moteur ou SDK? réponse avec Ogre3D

Depuis le premier billet, on vous a surtout présenté des SDK. Cette-fois ci, intéressons-nous à un logiciel de plus bas niveau: le moteur 3D.
La plupart des SDK utilisent le même moteur, (ou un dérivé) : Ogre 3D.

L’étude du moteur sera effectuée selon les axes suivants :

Logo Ogre3d

Présentation générale et licences d’utilisation
Ogre (Object-Oriented Graphics Rendering Engine) est un moteur de rendu graphique gratuit, actuellement sous licence MIT.
Il est donc possible:

  • de télécharger gratuitement le moteur 3D compilé ou ses sources
  • d’éditer les sources, sans restriction de publication (elles peuvent être republiées sous licence MIT ou sous une autre licence, ou non publiées)
  • d’utiliser Ogre3D sans nécessairement devoir afficher son logo ou un splash screen au démarrage

La seule condition est de conserver, dans le logiciel construit à partir d’Ogre3D, un fichier contenant la licence MIT d’Ogre (et bien sûr, de ne pas “s’approprier” le travail de la communauté qui a développée Ogre).

Notez que cette licence assez permissive d’Ogre3D ne s’applique qu’à Ogre3D: elle ne s’appliquera pas forcément aux modules complémentaires que vous utiliserez.

Le moteur 3D et son rendu

Ogre3D est un des meilleurs moteurs du marché. Certainement le meilleur si on compare les moteurs gratuits entre eux. C’est simple: quasiment tous les moteurs 3D dits ‘gratuits’ sont des dérivés directs ou indirects d’Ogre.
Grâce à une communauté très dynamique, le moteur est souvent mis à jour, et il bénéficie ainsi de nombreuses avancées au moment même de leur mise sur le marché par les entreprises spécialisées dans les moteurs payants.
La démo officielle devrait d’ailleurs facilement vous convaincre de la puissance de rendu du moteur.

Un exemple de rendu du moteur Ogre3D

Un rendu d’Ogre 3D (SteamPunk Legend)
Motorm4x, jeu de voitures utilisant Ogre3D

Un 4×4 en action, rendu par Ogre3D (Motorm4x)

Les fonctionnalités offertes par Ogre3D
Ces fonctionnalités sont nombreuses, vous en trouverez la liste sur la page de présentation du moteur.
Parmi ces fonctionnalités graphiques, citons:

  • Texturing / Shaders:
    • Support des shaders (assembleur ou haut niveau) via Cg, DirectX9 HLSL ou GLSL
    • Multi-textures
    • Texcoords (modification en temps réel de la géométrie d’une texture)
    • Manipulations RGBA, permettant de modifier les couleurs et transparence d’une texture en temps réel
    • Prise en charge automatique du GPU (Ogre3D optimise votre code pour le GPU de la machine-hôte)
    • TLOD, permettant de simplifier le rendu d’une texture si la caméra est trop loin pour en voir les détails
    • Large support de formats d’images (png, jpg, tga, bmp, dds, textures 1d, textures volumétriques ou compressées)
    • Mise à jour en temps réel des textures (permettant d’afficher une vidéo dans la texture par exemple ou de changer une texture à la volée)
  • Modèles 3D:
    • Séparation sommets/faces/index pour plus de flexibilité
    • LOD progressifs (le modèle est simplifié de façon continue en fonction de la distance à la caméra), manuels ou automatiques
    • Support d’un format XML souple
    • Surfaces courbes (grâce aux surfaces bi-quadratiques de Bézier)
    • Animation:

    • Modèle ‘skeleton’ permettant d’animer un squelette qui sera appliqué sur un ou plusieurs modèles 3D
    • Fusion d’animations (avec une pondération) permettant de générer des animations complexes à partir d’animations simples, de base
    • Contrôle temps réel des bones pour réaliser des animations gérées en temps réelles et non plus afficher une animation pré-conçue
    • Morpho-animations pour les visages et les expressions
  • Libre choix dans le système de gestion de la scène 3D (octree, flat,…)
  • Effets spéciaux:
    • Billboards (une texture toujours affichée face à la caméra)
    • Particles (débris et éclats)
    • Ribbon trails (rubans pour, par exemple, un effet de fumée derrière un avion qui tourne)

Le moteur physique

Ogre3D n’est qu’un moteur graphique, il faudra donc lui adjoindre un moteur physique pour bénéficier d’effets de collision ou de gravité.
En disposant des sources du moteur, on peut considérer que n’importe quel moteur physique pourra être ajouté. Toutefois, il est recommandé de se tourner vers NVidia PhysX ou vers un équivalent open source, ODE (un peu moins performant ni complet).

Les rendus sonores

Là encore, Ogre3D pêche, puisqu’il ne dispose pas de système de rendu sonore. On pourra toutefois se tourner vers OpenAL, librairie audio en open-source.

La compatibilité réseau

Une fois de plus… rien.
Et, malheureusement, il n’existe pas de véritable “référence” open-source pour ce type de librairie. On pourra quand même se tourner vers:

Les sorties graphiques (stéréo-vision)

Cette-fois ci, Ogre3D a une longueur d’avance! En effet, en tant que moteur de rendu graphique, Ogre peut se permettre de négliger les librairies audio ou réseaux, mais il ne pouvait pas négliger les rendus 3D et stéréoscopiques.
Utilisé conjointement avec NVidia 3D vision, en réutilisant des plugins open-source comme OS3D ou bien en natif, la stéréo-vision (anaglyphe, stéréoscopique ou multiple-écrans) sera parfaitement prise en charge.

L’interface utilisateur (appliquée à la RV)

Via les sources d’Ogre, il sera possible d’implémenter ses propres entrées-sorties utilisateur, car rien ne permet cela nativement.
Étant donné que le code source d’Ogre est sous licence MIT et donc, disponible pour l’édition, il sera possible (mais certainement assez fastidieux) d’implémenter tout type d’entrée utilisateur, que ce soient des gants, des casques, des joysticks ou des souris 3D.

L’interface graphique (GUI)

Via CEGUI (LGPL) ou MyGUI (MIT), il est facile d’ajouter les interfaces graphiques que l’on souhaite.
Ces librairies permettront également des interfaces un peu plus poussées, mais il faudra alors étudier plus en détail leur documentation.

Les plateformes supportées (développement et déploiement)

Ogre supporte de très nombreuses plateformes, parmi lesquelles on pourra citer:

  • Windows (toutes versions confondues), sur Visual C++ ou Code::Blocks
  • Linux (gcc 3+)
  • MAC OSx (XCode)
  • NaCl
  • WinRT
  • Windows Phone 8
  • iOS
  • Android

De plus, Ogre3d s’adapte automatiquement au type de GPU et à la technologie 3D utilisée (OpenGL ou DirectX).

Les langages de programmation supportés

Ogre est codé en C++, et pourra donc être modifié selon les normes de ce langage.
De base, Ogre est le plus “compatible” possible: il sera donc intéressant de garder cette inter-opérabilité pendant toute la phase de développement, en évitant par exemple d’utiliser des librairies spécifiques à un OS particulier.

Synthèse du moteur

Ogre possède de nombreux avantages (licence MIT, C++, compatibilité, communauté active,…) mais il présente le gros défaut de n’être qu’un moteur de rendu graphique.
Il faudra donc se tourner vers des SDK pour des projets sur le long terme, ce qui évitera de dépenser trop d’énergie à comprendre
chacune des bibliothèques qu’il faut ajouter à Ogre pour l’enrichir de toutes les fonctionnalités non-graphiques dont il ne dispose pas.


Nom Ogre3D
Licence MIT
Moteur 3D Excellent
Très régulièrement mis à jour
Moteur physique Absent
Rendu sonore Absent
Réseau Absent
Sorties graphiques Au choix des développeurs
3D stéréo, anaglyphe, multi-écrans, 360°
E/S utilisateurs A la charge des développeurs
GUI S’interface avec MyGUI ou CEGUI
Plateformes Windows, Mac, Android, iOS, Linux, google native client…
Langages Code source libre
c++ (Visual studio, C::B, XCode…)

Licence Creative Commons
Cette œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution – Partage dans les Mêmes Conditions 3.0 France.
Auteurs: MONIER Vincent, SFEIR Raphael

Unity, un SDK costaud et gratuit

Il est temps de passer en revue un nouveau framework ! Aujourd’hui, nous allons nous intéresser à un autre outil très connu des joueurs et créateurs de jeux : Unity !

L’étude du framework sera effectuée selon les axes suivants :

Logo Unity3d

Présentation générale et licences d’utilisation

Unity est un moteur de jeu multiplateformes ainsi qu’un IDE, créé par Unity Technologies en 2005. Des développeur danois, David Helgason, Joachim Ante et Nicholas Francis ne parvenant pas à créer des succès commerciaux pour leurs jeux vidéos, décidèrent de s’orienter vers les outils de créations et d’éditions de jeux. Leur ligne directrice était de “démocratiser la création de jeux”.
La toute première version de Unity fut lancée en 2005 et était destinée aux ordinateurs Mac exclusivement. Le succès fut au rendez-vous, et aujourd’hui la dernière version stable de Unity est la version 4, sortie fin 2012, qui supporte plus de 10 plateformes différentes.

Unity est un produit sous license propriétaire, et deux licenses sont disponibles : Unity et UnityPro.
UnityPro dispose de toutes les fonctionnalités du produit hormis le support de certaines plateformes et coûte environ 1500€. Quant à Unity, c’est une version entièrement gratuite et assez complète, même si elle dispose de moins de fonctions que la version Pro.
Il est possible de commercialiser un produit réalisé sous Unity sans payer de royalties, même pour la version gratuite. Toutefois, une compagnie réalisant un chiffre d’affaire de plus de 100,000$ doit obligatoirement utiliser la version Pro.
Le code source de Unity est protégé, mais il est possible, exceptionnellement, que Unity confère des licences pour ce code source. Ces licences sont toutefois réservées à de grandes entités commerciales car le processus coûte très cher et est fortement réglementé. De petites structures ou des institutions de l’éducation n’ont aucunes chances d’accéder à une telle licence.

Le moteur 3D et son rendu

Visuellement, le moteur Unity3D est très avancé. Bien qu’il ne soit pas tout à fait aussi puissant que le CryEngine, il permet la réalisation de jeux “AAA”, avec une qualité visuelle qui n’a pas à rougir de la concurrence. L’autre très grand avantage de Unity est qu’il permet un rendu fluide sur de très nombreux supports : PC, Mac, Xbox, PS3, Wii & WiiU ou encore Linux. Mais aussi des supports plus limités en performance comme iOS, Android, les navigateurs Web ou Flash.

Un paysage généré par Unity

Unity supporte l’API graphique de Windows, DirectX 11 et permet l’utilisation des des compute Shaders, permettant un énorme gain de vitesse sur l’utilisation des shaders. En effet, les compute shader utilisent la puissance des processeur du GPU.
Le rendu graphique offre également de très bons effets de lumière et d’ombres, 100 shaders natifs, une détermination des surfaces cachées (version Pro uniquement), de nombreux effets comme la profondeur de champ, le motion blur, vignettage, tonemapping…

En résumé, le moteur 3D de Unity est très costaud ! Pour en juger par vous-mêmes, voici quelques démos :

Démo Unity sur navigateur Web
Démo lumières
Démo Unity4

Le moteur physique

Unity utilise le puissant moteur physique NVIDIA® PhysX® Engine. Ce puissant moteur permet une gestion de la physique très réaliste ainsi qu’une prise en charge de la physique des vêtements ou des cheveux, ou encore des objets rigides soumis à la physique.

Les rendus sonores

Le moteur audio de Unity est assuré par une librairie très utilisée et très populaire : FMOD. Cette bibliothèque multiplateforme permet de gérer le son sur de nombreux appareils et avec de très nombreux formats : DSL, M3U, WAX, MOD, OGG, MP3, AIFF, WAV, WMA, VAG, et bien d’autres…
Unity permet également d’utiliser des filtres audios DSP (version Pro), des filtres passe-bas ou passe-haut, de la distorsion, un effet d’écho ou de résonance…

La compatiblité réseau

Il est aisé de créer une prise en charge réseau avec Unity. Il existe différentes gestion des serveurs, qu’ils soient “authoritative” (l’ensemble du monde virtuel est les entrées des joueurs sont gérées sur le serveur, rendant la triche, par exemple, très difficile) ou non (les calculs de physique et les contrôles sont gérés par le client, ce qui allège le travail du serveur). Unity travaille avec deux méthodes de communication réseau : le RPC, un protocole client-serveur classique et le protocole de synchronisation (plutôt utilisé pour des données en constante évolution) des états. Il est possible d’utiliser les deux méthodes.

En résumé, la prise en charge réseau du moteur Unity est très complète, très documentée, et paraît performante et facile à prendre en main.

Les sorties graphiques (stéréovision)

Par défaut, Unity ne dispose que de très peu d’outils pour la Réalité Virtuelle. La gestion de la stéréoscopie, des casques ou des caves, par exemple, ne semblent pas possibles sans un travail conséquent.

Introduction à MiddleVR

Heureusement, il existe des plugins comblant ce manque.
MiddleVR est un plugin Unity3D très complet, développé par une compagnie française spécialisée dans la RV, I’m In RV. Il permet l’utilisation de CAVE, de sortie stéréoscopiques, de casques, de HoloBench… MiddleVR permet également le support de la plupart des outils d’interactions : Intersense, Flystick, Vicon, Microsoft Kinect…
Par contre, MiddleVR permet un essai gratuit de 30 jours mais est, ensuite, payant. Le prix n’est pas communiqué.
VRJuggler est également utilisable par Unity. S’il semble moins facile à prendre en main et moins complet que MiddleVR, c’est un outil gratuit et open source.

L’interface utilisateur (appliquée à la RV)

Le paramétrage du contrôle utilisateur de Unity est très simple à prendre en main et très complet. Unity permet l’utilisation de la plupart des contrôleurs du marché : joystick, manettes, volants…

Toutefois, encore une fois, la gestion contrôleurs de RV ne sont pas pris en charge par Unity par défaut. Ici aussi, il faudra l’intégration d’un outil tiers comme MiddleVR pour la prise en charge des contrôles RV.
MiddleVR semble d’ailleurs être l’outil le mieux armé et le plus complet pour l’interaction avec ces contrôleurs.

L’interface graphique (GUI)

L’entité UnityGUI permet de scripter très facilement l’interface graphique d’une application. Cette librairie dispose de nombreuses offrant de nombreuses fonctionnalités pour la gestion du GUI comme des boutons, des personnalisations graphiques, des barres de progression, un positionnement rapide…

A noter que la programmation du GUI est faisable en C# ou en Javascript.

Les plateformes supportées (développement et déploiement)

Unity est sans doute le framework supportant le plus de plateformes du marché. On dénombre ainsi dix plateformes, et pas des moindres :

Windows
Mac
Android
iOS
Linux
Navigateur Web
Flash
PS3
Xbox 360
Wii / WiiU

Attention néanmoins, la version basique de Unity ne comporte que le support de PC, Mac et Linux. Il faut payer des fonctionnalités en plus pour développer sur d’autres supports.

Les langages de programmation supportés

S’il n’est pas possible de toucher au code source du framwork, plusieurs langages de programmation sont supportés pour les scripts applicatifs. Un programmeur peut utiliser le langage personnalisé UnityScript, C#, Boo ou Javascript.

Synthèse du framework

Unity est un framework très complet, très bien documenté et possède l’une des communautés les plus actives du marché. Cet outil se paie le luxe d’être gratuit (pour la version Unity base) tout en offrant un moteur 3D de grande qualité, un IDE intuitif et riche en fonctionnalités.
Malheureusement, Unity ne dispose pas d’outils pour gérer la Réalité Virtuelle. Il faut obligatoirement les développer soi-même ou bien passer par des outils externes. Il existe heureusement des outils complets et de qualité pour pallier à ce manque, comme MiddleVR. Une fois couplé à un tel logiciel, Unity apparaît comme un candidat très sérieux au poste de framework 3D de réalité virtuelle, et semble idéal pour des applications éducatives de RV, par exemple.


Nom Unity
Licences Propriétaire
Moteur 3D Au niveau des jeux actuels
Moteur physique NVIDIA® PhysX® Engine
Rendu sonore FMOD et outils intégrés
Réseau Prise en charge réseau
Sorties graphiques Par défaut, pas de sortie RV. Avec MiddleVR : CAVE, stéréoscopie, Holobench, etc.
E/S utilisateurs Contrôleurs gérés, Motion Control avec MiddleVR
GUI Facilement modulable avec UnityGUI
Plateformes Windows, Mac, Android, iOS, Linux, Navigateur Web, Flash, PS3, Xbox 360, Wii / WiiU
Langages Code source protégé. Scripts avec C#, Boo, Javascript, UnityScript

Licence Creative Commons
Cette œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution – Partage dans les Mêmes Conditions 3.0 France.
Auteurs: MONIER Vincent, SFEIR Raphael

CryEngine, un SDK à vous faire pleurer d’envie

Réalité virtuelle et Framework 3D existants

Pour ce troisième billet, il est naturelle de s’intéresser à une version 3 d’un SDK bien connu des joueurs:
le CryEngine 3.

Le framework sera étudié selon les axes suivants:

Logo CryEngine 3

Présentation générale et licences d’utilisation

Le CryEngine est un moteur de jeu développé par Crytek, depuis 2004 environ. Initialement, il fut développé pour faire office de vitrine technologique pour NVidia. Suite au succès de FarCry, Crytek développera son moteur de jeu de façon plus indépendante. Il est maintenant reconnu comme un moteur de jeu à aprt entière, très performant et visuellement le plus aboutit.

Etant développé par un studio professionnel classique, le CryEngine n’est pas totalement gratuit et encore moins open source.
Toutefois, depuis CryEngine 3, crytek mets gratuitement son SDK à disposition du publique, sous certaines conditions:

  • Le projet doit être non-commercial
  • Les sources ne sont pas disponibles

Attention toutefois à une restriction de license assez délicate définie sur le site de cryengine:
“CryENGINE 3 is free [...] if you are distributing your game or application for free and not charging for your work in producing it, whether directly or indirectly”.
Ce point-là peut être assez délicat car si une équipe de développement travaille sur ce projet en état rémunérée (stage, CDD, CDI…), alors on peut considérer qu’elle fait payer son travail de production, et donc, la clause “not charging for your work in producing it” n’est plus respectée.

Dans le cas d’une license commerciale, les prix peuvent être bien plus prohibitifs, puisque d’après un studio de développement (anonyme car CryTek demande à signer une politique de confidentialité sur la non-divulgation du prix du moteur de jeu) ce prix dépasse le millino de dollars.
Egalement, le site de cryengine définit clairement que 20% des revenus commerciaux du produit fini doivent être retournés à crytek (royalties).

Le moteur 3D et son rendu

Graphiquement, le CryEngine (en version 3) est bluffant.

New York en flammes sur le Cry Engine 3
New York tel qu’on peut le voir en temps réel dans Crysis 2 (Cry Engine 3).


L'abbaye de Cluny par Enodo
D’autres projets utilisant CryEngine 3

Le CryEngine supporte:

  • Le per-pixel rendering, sur DirectX 9, 10, 11 (pas d’OpenGL)
  • Le normal/diffuse/specular/bump/tesslation mapping et l’ambient occlusion (générale ou locale)
  • L’éclairage et ombrage en temps réel (position dynamique du Soleil incluse)
  • Le cycle jour/nuit
  • Le SmoothShadow (atténuation des bords des ombres)
  • La radiosité
  • HDR (High Dynamic Range Rendering) permettant de simuler l’ébouissement et l’effet d’adaptation occulaire
  • Les God Rays (rayons lumineux à travers les feuillages ou au bord des maisons)
  • Une grande profondeur de champ (réglable, entre 0 et 16Km)
  • Les brouillards bolumétriques et les effets d’eau
  • La tessellation dynamique
  • Les voxels (pour les nuages par exemple)
  • Le flou cinétique (flou de mouvement, de la caméra et des objets mobiles vus par la caméra)

Vous pouvez visualiser le rendu graphique sur la vidéo youtube de démonstration.

Background 3D de montagnes sur CryEngine 3

Le moteur physique

Le moteur physique inclus dans le SDK est propre à Crytek. Il offre de nombreux atouts:

  • Multi-thread
  • Multi-scale (la physique d’applique aussi bien aux stylos billes qu’aux immeubles, en passant par des véhicules)
  • Déformation de surfaces (vêtements, tissus)
  • Water physics (permettant de faire des “ronds dans l’eau”, même si cela parait plus simple que cela n’est)
  • Destruction d’objets et débris
  • Gestion des particules (petits éclats de verre ou de métal qui sont émis par une source comme une lampe à souder)
  • Gestion de plusieurs types de matériaux (bois, métal, pierre, végétaux, corps humains, animaux…)
  • Torsion dynamique (mouvement des feuillages ou des cordes en fonction de la charge appliquée)

Crytek propose une vidéo de démonstration directement sur son site mycryengine.com.

Les rendus sonores

Niveau sonore, Crytek a encore réussi à pousser la technologie dans ses retranchements, en incluant de nombreuses améliorations au système de rendu sonore.

  • La génération de sons en temps réel
  • Des outils de développement pour le profilage de l’ambience sonore
  • Son surround 7.1 (support aussi du 5.1, 2.1, 2.0 et casques)
  • Incorporation de la librarie FMOD Ex(R)
  • La musique interactive, s’adaptant automatiquement aux évènements courants visibles à l’écran
  • Une grande précision dans le déclanchement des sons lors d’animations (démarrage de moteur par exemple)
  • Un système de post-traitement sonore permettant de simuler une ouïe déformée (assourdissement, effet “sous l’eau”…)

La compatiblité réseau

Le CryEngine 3 supporte la gestion du réseau, mais peu d’informations sont fournies sur le site de Crytek (seul le mot ‘network’ apparait pour CryEngine 2).
Le support des consoles de salon (XBox360 et PS3) permet quand même de penser que la prise en charge du réseau se fait à la fois dans le cadre du réseau local (pour le développement multi-plateforme) et internet (Playstation network par exemple).
Néanmoins, l’absence d’accès aux codes sources risque de rendre la partie réseau épineuse.
Le support réseau fournit par CryEngine devrait quand même s’avérer suffisant dans le cadre d’une application localisée de RV, mais elle sera problématique si on envisage un portage direct sur des supports mobiles (qui ne sont d’ailleurs pas pris en charge par CryEngine 3).

Les sorties graphiques (stéréovision)

Crytel ayant développé CryEngine pour les jeux vidéos, la société a su tirer profit de l’engouement actuel pour la 3D.
Ainsi, le support de la 3D est total dans CryEngine:

  • Support de la 3D stéréoscopique
  • Contrôle des paramètres de stéréoscopie (profondeur, distance focale, écart des yeux…)
  • Aucun code requis (support natif total)
  • Prise en charge des standards industriels (HDMI et pre-HDMI 1.4 stéréo, anaglyphe, projection stéréoscopique, lunettes NVidia)

Néanmoins, l’absence d’accès aux codes sources pourrait poser des difficultés si la sortie 3D choisie n’est pas compatible avec les standards industriels du grand public. Par exemple, la prise en charge d’un casque de réalité virtuel qui n’utiliserait pas l’un des standards ci-dessus sera difficile en raison de l’absence d’accès aux sources du moteur de jeu.

L’interface utilisateur (appliquée à la RV)

Aucune information sur les interfaces “exotiques” liées à la RV n’est donnée par Crytek.
L’absence d’accès au code source (sauf après l’achat d’une license commerciale probablement onnéreuse) risque d’être un frein sérieux à l’intégration d’une telle interface utilisateur.
On peut toutefois supposer que les interfaces suivantes sont prises en charge:

  • Joysticks et manettes industrielles (Playstation)
  • Kinect (Xbox)
  • Volants et joystick de simulation de vol

En revanche, il risque d’être difficile d’intégrer un gant de réalité virtuelle, ou une combinaison complète.

L’interface graphique (GUI)

Dans tout jeu vidéo, il existe un HUD (Head Up Display) permettant d’afficher des informations 2D à l’écran. Dans CryEngine, il est donc possible de faire de même.
La création de ces HUDs se fait via un éditeur WYSIWYG (What You See Is What You Get, autrement dit, un cliquez-déposez en temps réel sans compilation).
Les HUDs peuvent inclure des images, du texte, des vidéos ou être dynamiquement gérés par un programme.
Il est également possible de créer des labels, autrement dit, des ‘HUDs’ à l’intérieur du monde 3D (ce qui revient à afficher du texte que l’on attache à un objet du monde virtuel).

Les plateformes supportées (développement et déploiement)

Crytek supporte de nombreuses plateformes pour le développement et le déploiement:

  • PC (Windows XP, Vista, 7)
  • Xbox 360
  • Playstation 3
  • Nintendo Wii U (à confirmer)

A noter que ni Apple (MAC) ni Linux ne sont pris en charge.

Les langages de programmation supportés

Crytek ne diffuse aucune information sur son langage de script interne, ni sur le langage utilisé pour le développement du CryEngine.
On peut toutefois supposer, au vu du portage possible sur les plateformes de salon, que le langage utilisé s’approche du C/C++.
Aucune information n’est disponible quant à un éventuel langage de script interne, similaire aux scripts de NeoAxis, qui n’aurait nécessité aucune recompilation pour être testés.

Synthèse du framework


Nom
Frameworks pour la RV: NeoAxis

Neoaxis

Frameworks pour la RV: Open scene graph

OpenSceneGraph

Frameworks pour la RV: CryEngine 3

Cryengine
Licences Non-commerciale: 0€
Autres: $95 à $295 env.
LGPL, Open source Non-commerciale: 0€*
Commerciale: 20% de royalties
Pas de code source
Moteur 3D Au niveau des jeux videos actuels Bénéficie de la puissance de OpenGL Probablement le plus abouti
Moteur physique PhysX/ODE Modulable (Havok, Bullet, ODE…) Natif
Rendu sonore 2D/3D, format OGG
Création de sons en temps réel
Support des microphones
2D/3D, OpenAL et FMOD 2D/3D, natif
Création de sons en temps réel
Réseau Prise en charge réseau C/S
Rendus graphiques distribués
Pas de prise en charge réseau Prise en charge réseau
Sorties graphiques Ecran stéréoscopiques
Navigateur Web
360 degres
Stéréoscopie, multi-écran
CAVE via VRJuggler
Stéréoscopie
Support des standards industriels
Anaglyphe
E/S utilisateurs Joysticks
Wiimote
Kinect
Autres E/S possibles
Contrôleurs (joysticks, volants…)
Motion Control limité
Joypads (PlayStation)
Joysticks/Volants
Microsoft Kinect (R)
Intégration des entrées non-standards difficile
GUI Customisable
Aisé à créer
In-game 3D GUI (label)
Modulable (toolkits externes: Qt) Aisés à créer
Complets

Plateformes Windows
MAC
A venir:
iOS
Android
Google native client
Windows
GNU/Linux
MacOS/X
Android
Windows
XBox
Playstation 3
Langages C#
Support d’add-ons C/C++
Scripts C# internes
Just-in-time
C++ Probablement C/C++
Pas de script interne

Licence Creative Commons
Cette œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution – Partage dans les Mêmes Conditions 3.0 France.
Auteurs: MONIER Vincent, SFEIR Raphael

OpenSceneGraph, la RV en open source

Après une introduction à un premier framework 3D pour la réalité virtuelle sur le puissant NeoAxis, nous allons aujourd’hui nous intéresser à un outil open source souvent utilisé dans la simulation visuelle ou visualisation géographique : OpenSceneGraph !
Amis du C++, vous allez être gaté par ce framework ! En revanche, si ce langage a tendance à vous donner la nausée, vous feriez mieux de vous préparer à l’indigestion.

L’étude du framework sera effectuée selon les axes suivants :

Logo OpenSceneGraph

Présentation générale et licences d’utilisation

OpenSceneGraph (OGS) est un framework de développement 3D open source initié par Don Burns, qui a débuté le projet sur son temps libre en 1998, avant d’être rejoint en 1999 par Robert Osfield. C’est un outil entièrement écrit en C++ et basé sur l’utilisation d’OpenGL, une API de développement graphique. Couplé avec de nombreuses librairies externes également libres de droits, c’est un framework complet et multiplateforme, souvent utilisé pour de la visualisation pure d’environnement 3D.
L’utilisation d’OGS est gratuite mais impose le respect de la licence LGPL, ce qui offre une grande liberté d’usage tant que l’on reste dans l’utilisation non commerciale. De plus, pour l’utilisation de la RV, il est possible d’utiliser d’autres outils utilisant une licence différente.

Le moteur 3D et son rendu

Le rendu de OpenSceneGraph est réalisé en OpenGL et dispose des fonctionnalités courantes d’un moteur 3D standard. On retrouve ainsi le multi-texturing, des effets de particules, la prise en compte des shaders, le paramétrage des détails et des performances optimisées.
Surtout, OSG est aisément modulable avec les librairies externes comme osgNV permettant d’utiliser pleinement les CPUs nVidias modernes.

Logo OpenGL

Le moteur physique

La physique de OSG est implémentée via la osgPhysics, une librairie C++ multiplateforme. Cette librairie permet l’accès à de nombreux moteurs physiques variés, comme ODE, Bullet, Havok ou encore PhysX. Cette modularité offre ainsi aux utilisateurs de OpenSceneGraph des fonctionnalités très nombreuses en terme de moteur physique.

Les rendus sonores

Encore une fois, le monde serait triste sans le chant des oiseaux.
OpenSceneGraph utilise osgAudio comme moteur sonore. Basé sur OpenAL, une bibliothèque audio 3D multi-plateforme utilisé dans de nombreux jeux vidéo, et FMOD, une librairie permettant de gérer les sons et les différents formats, osgAudio profite de la puissance de ces deux librairies éprouvées et offre en outre les fonctionnalités suivantes :
Streaming audio.

  • Sources sonores et auditeurs positionnables
  • Sons d’ambiance et occlusion sonore
  • Atténuation et effet Doppler

La compatiblité réseau

La documentation ne mentionne pas de librairie réseau sur OpenSceneGraph. A priori, il n’existe aucun outil sur OpenSceneGraph actuellement pour prendre en charge cet aspect du développement.

Les sorties graphiques (stéréovision)

OSG supporte le stéréo anaglyphe (à l’aide de lunettes rouges et vertes), le « Quad Buffering », le découpage stéréo horizontal ou vertical, ainsi que le multi écran. Presque toutes les applications de OpenSceneGraph peuvent utiliser la stéréovision à condition que les variables d’environnement correspondantes soient bien paramétrées. Le support de ces fonctionnalités est assuré par la classe osgUtil::SceneView de façon transparente, il n’est normalement pas nécessaire de changer directement dans le code du framework.

Pour l’utilisation d’une sortie graphique de type CAVE, il est déconseillé d’utiliser uniquement OSG. L’utilisation d’un toolkit supplémentaire, VRJuggler, permet néanmoins d’assurer correctement la gestion des environnements CAVE, et OpenSceneGraph couplé à de tels toolkits est fréquemment utilisé dans ce cas.

L’interface utilisateur (appliquée à la RV)

Pour s’adapter aux contrôles très particuliers de la réalité virtuelle, où bien souvent ce sont les gestes de l’utilisateurs qui permettent de contrôler l’application, la documentation de OpenSceneGraph offre une classe de gestion de Motion Control. Mais la documentation n’est pas très fournie et cette fonctionnalité ne semble pas très élaborée comparée à d’autres frameworks existants.
L’utilisation d’un plugin ou un toolkit comme VRJuggler peuvent éventuellement pallier à ce manque.
En revanche, il est aisé d’utiliser des contrôleurs typiques comme des joysticks ou des volants.

L’interface graphique (GUI)

Encore une fois, ce framework assure la gestion des GUI via de nombreuses librairies et toolkits externes et robustes, comme par exemple :

  • Qt3 & Qt4 (osgviewerQT)
  • SDL (osgviewerSDL)
  • GLUT (osgviewerGLUT)
  • FLTK (osgviewerFLTK)
  • WxWidgets (osgviewerWX)
  • MFC (osgviewerMFC)

Ces nombreux outils disposent eux-mêmes de librairies permettant le support facile d’une GUI.

Les plateformes supportées (développement et déploiement)

Du fait de l’utilisation massive d’outils multiplaformes comme OpenGL ou FMOD, le développement à l’aide de ce Framework couvre la très grande majorité des principales plateformes existantes :

Microsoft Windows (2000, XP, Vista)
GNU/Linux
MacOS/X
Android

Toutefois, le déploiement du framework peut légèrement varier d’une plateforme à une autre. Les instructions des différentes méthodes de déploiement sont précisées ici.

Les langages de programmation supportés

Vive le C++ ! OpenSceneGraph est entièrement développé en C++ et supporte uniquement ce langage.
De ce fait, la documentation d’OpenSceneGraph est très technique et assez difficilement lisible.

Synthèse du framework

Pour un outil libre de droits, OpenSceneGraph est un framework complet. Son caractère modulaire, son code ouvert et son utilisation de librairies comme OpenGL rendent OSG technique à utiliser, assez difficile d’accès, mais puissant.


Nom OpenSceneGraph
Licences LGPL, Open source
Moteur 3D Bénéficie de la puissance de OpenGL
Moteur physique Modulable (Havok, Bullet, ODE…)
Rendu sonore 2D/3D, OpenAL et FMOD
Réseau Pas de prise en charge réseau
Sorties graphiques Stéréoscopie, multi-écran, CAVE via VRJuggler
E/S utilisateurs Contrôleurs (joysticks, volants…) gérés, Motion Control limité
GUI Modulable avec des toolkits externes comme Qt
Plateformes Windows, GNU/Linux, MacOS/X, Android
Langages C++

Licence Creative Commons
Cette œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution – Partage dans les Mêmes Conditions 3.0 France.
Auteurs: MONIER Vincent, SFEIR Raphael

Neoaxis, un SDK pour la RV

Réalité virtuelle et Framework 3D existants

Ce premier billet d’une longue série instructive sur l’application de frameworks 3D existants à la réalité virtuelle s’intéressera au framework NeoAxis.

Le framework sera étudié selon tous les axes relatifs, directement ou indirectement, à la réalité virtuelle. Un tableau récapitulatif figure en fin de ce billet pour résumer les possibilités de ce framework. Au fil des différents billet, ce tableau récapitulatif sera complété, et permettra ainsi une comparaison rapide des différents frameworks. Il faudra toutefois garder à l’idée que les versions des frameworks évoluent avec le temps, et que tous les billets à venir (y compris celui-ci), ne sont que des études ponctuelles dans le temps, alors que les frameworks évoluent avec les mois et les années.

Le framework choisi ici (pour rappel, Neo Axis en version 1.2) sera étudié selon les axes suivants:

Logo Neoaxis

Présentation générale et licences d’utilisation
Neoaxis est un SDK complet pour le développement d’application 3D de type Games / Serious games. Utilisant le moteur Ogre3D couplé à ODE Physics/NVidia PhysX, ce SDK intègre tous les outils nécessaire à un développement et à un déploiement rapide, tels que des éditeurs de maps et de ressources, un langage de script intégré (C#), une gestion des réseaux (client/serveur et rendus distribués), des plugins pour les E/S utilisateur, ou encore, une possibilité d’interconnexion avec Internet.
L’intégralité des fonctionnalités sont décrites dans le document récapitulatif des possibilités offertes par le SDK.

Le SDK est disponible en plusieurs licences adaptées au besoin de chacun:

  • Non-Commercial/Development license, intègre la quasi-totalité* des fonctionnalités du SDK: 0€
  • Indie license, intégrant toutes les fonctionnalités et à destination des petits projets de jeux commerciaux (revenus max: $10.000): $95 (licence pour 1 dev) / $295 (2-5 dev)
  • Commercial license, ajoute l’accès à de nombreux codes sources par rapport à l’Indie, sans limite de CA: $395 (licence 1 dev) / $995 (licence 2-5 dev)
  • Source licence, ajoute l’accès à tous les codes sources par rapport à la licence Commerciale: prix à débattre (précédemment évalué aux environs de $5.000 début 2011)

Toutes les licences sont forfaitaires: il n’y a pas de royalties (redevances) à verser et ce quelque soit le chiffre d’affaire réalisé par l’utilisation commerciale du SDK. Egalement, toutes les licences ne sont pas limité en nombre de projets (la limite de CA s’applique à l’ensemble des projets): il est possible d’utiliser la même licence pour 4 projets par exemple, si le même développeur travaille sur ces projets.
*: Certaines fonctions ne sont toutefois pas disponible, comme les collisions physiques continues pour des formes non-primitives. La très grande majorité des fonctionnalités sont toutefois disponibles, y compris les normal maps, tesslations, parallax mapping, heightmaps, physic breakable joints, particles et bien d’autres.

Récapitulatif des licences

Dans le cas de la RV, on pourra considéré l’utilisation d’une licence non-commerciale. Toutefois, si le projet est utilisé dans une structure commerciale (musée par exemple), il peut être générateur de revenus (la présence dans le musée d’une salle de RV peut inciter les visiteurs à entrer dans ce musée, et donc, à y payer leur place, ce qui génère des revenus). Dans un tel cas, il est conseillé de se rabattre sur la licence commerciale, pouvant généralement être limitée à 1 développeur (notez que plusieurs personnes peuvent travailler sur le projet alors qu’un seul développeur travaille sur les sources du SDK: le nombre de développeur indiqué dans les licences est le nombre de personnes travaillant effectivement sur les codes sources du SDK).

Le moteur 3D et son rendu

Une RV se doit d’être immersive, et l’immersion passe généralement par un bon rendu graphique, mais également par une bonne fluidité d’image. La fluidité d’image est souvent liée à la puissance de la machine, alors que la beauté du rendu graphique est relative au moteur 3D utilisé.

Exemple de rendu du moteur 3D: un village montagnard médiéval
La démo vidéo du moteur

Graphiquement, ce SDK est “beau”, puisqu’il réutilise et implémente une grande partie des possibilités de Ogre3D. On retrouve ainsi:

  • Le per-pixel rendering
  • Ombrages en temps réel (PSSM permettant un ombrage plus précis pour les zones proches de la caméra, et Self-shadowing permettant à l’objet de porter une ombre sur lui-même)
  • 64bits HDR (High Dynamic Range, permettant d’utiliser une palette de couleurs et de luminosités plus étendue)
  • Les HighMaterials (Shaders), statiques (pré-compilés) et dynamiques (permettant d’ajouter des effets en temps réel sur une texture)
  • Normal mapping / Bump mapping, permettant de simuler les petits reliefs d’une surface texturée
  • Le parallax mapping, générant un véritable effet de relief sur une texture, sans modifier le nombre de triangles ni la forme effective de la texture
  • Animations 3D avancées (Skinned mesh, pose animation, morph animation; permettant d’animer des models 3D ou de recréer des expressions de visage ou des mouvements de lèvres)
  • Post-traitements, permettant d’appliquer un traitement personnalisable à l’image calculée avant de l’afficher à l’écran (flou, mise en noir&blanc, corrections gamma/contraste…)
  • Particles, assurant la gestion d’effets comme la fumée, les flammes ou les poussières volant dans l’air
  • LOD customizables, permettant d’afficher un modèle 3D différent en fonction de la distance entre l’objet et la caméra

Le rendu est également optimisé pour de nombreux cartes et chipsets graphiques (ATI, NVidia, chipsets Intel,…). Les cartes et chipsets ne supportant pas certaines fonctionnalités (tesslation et parallax par exemple) ne sont pas en reste: le moteur peut parfaitement fonctionner sur des chipsets un peu anciens ou faibles, au prix de la perte de certaines fonctionnalités (par exemple, certains chipsets Intel n’ayant pas la technologie Shader Model 3 sont quand même supportés, mais ils n’utiliseront pas les bump maps ou le paralax mapping).

Post-traitement de l'image: un flou radial

De nombreux post-traitement sont prédéfinis et cumulables

Ombrages et reflets en temps réel

Le moteur physique

Un moteur 3D seul n’est pas suffisant, que ce soit dans le cadre d’un jeu ou de la RV: il faut le coupler à un moteur physique, ne serait-ce que pour éviter que votre personnage ne traverse le sol ou les murs.
Le SDK NeoAxis peut utiliser, nativement, deux moteurs physiques différents: NVidia PhysX (propriétaire, mais libre d’utilisation sur des projets de moins de $100k) ou ODE (Open Dynamics Engine, open source). Le réglage se fait via l’exécutable “Configurator.exe”. Ces deux moteurs implémentent majoritairement les mêmes fonctions, à savoir:

  • Outil d’édition des modèles physiques (permet de définir la forme physique d’un model 3D graphique soit via des primitives, soit via un mesh physique devant alors être statique pour la version non-commerciale car seule la version commerciale supporte les mesh physiques dynamiques)
  • Joints , permettant d’articuler physiquement des éléments dans un modèle 3D (par exemple, un moulin dont les pales sont articulées en liaison pivot avec le bâtiment du moulin)
  • Breakable joints, identiques aux joints, mais qui seront rompus si le couple/la force/la vitesse relative (de rotation ou de translation) dépasse un seul fixé
  • CCD (Continuous Collision Detection), modèle de calcul physique permettant de gérer la collision de petits objets en mouvement rapide avec des objets plats (cf wiki en fin de liste)
  • Moteurs et rotors, permettant de définir un couple (de valeur fixe ou variable) ou une force sur un joint (et ainsi simuler un moteur qui s’appliquerait à cette liaison entre deux objets physiques, appelés “bodies”)
  • Support de moteurs physiques tiers, ce qui permet à l’utilisateur de choisir un autre moteur physique que ceux utilisés nativement par NeoAxis

Des informations plus complètes sur ODE sont disponibles sur le wiki du SDK.

NVidia PhysX sur NeoAxis

Les rendus sonores

Le monde serait triste sans le chant des oiseaux… Il est donc important d’équiper le framework 3D d’un moteur sonore, non seulement pour le plaisir des utilisateurs, mais aussi pour faciliter l’accès à la ressource de RV pour les malvoyants. Mais le son n’est pas forcément limité à la lecture d’un fichier audio pré-enregistré, de nombreuses autres technologies permettent d’utiliser le son comme un nouveau moyen d’expression pour la RV, via par exemple, la génération en temps réel d’un son (pour la collision d’objets par exemple) ou d’une musique. Ce SDK propose également:

  • 8 canaux audio 2D + 16 canaux audio 3D, permettant donc la lecture simultanée de 32 sons (8 sons en mono/stéréo + 16 sons dans l’environnement 3D,, ces limites peuvent dépendre de la carte son de l’utilisateur)
  • L’enregistrement en temps réel via le microphone (pour des commandes vocales par exemple)
  • La génération de sons en temps réel via un script (comme expliqué avant cette liste)
  • La modification en temps réel du pitch d’un son (fréquence de la lecture, simulant par exemple l’effet Dopler)

NeoAxis utilise OpenAL pour le rendu sonore et supporte le format libre ogg (“domaine publique” d’après le site Vorbis, développeurs de ce format). Le support mp3 n’est pas garanti (pour rappel, le format mp3 n’est pas libre, les outils de créations de fichiers MP3 sont soumis à certaines restrictions que le wiki du format mp3 explicite un peu), le format wav semble être pris en charge, du moins jusqu’à présent.

La compatiblité réseau

Les réseaux peuvent s’avérer très utiles en RV, non seulement car ils permettraient à plusieurs personnes d’être, en même temps, dans le même monde virtuel (et pourquoi pas avoir une conversation dans le monde virtuel, via la prise en charge des microphones comme expliqués précédemment). Les réseaux peuvent aussi permettre la création d’un rendu distribué, qui consiste à avoir N machines, chacun ayant à sa charge d’afficher un morceau de la scène sur 1 ou 2 écrans. Tous les écrans (les N ou 2N écrans) forment alors une grande surface d’affichage qui affiche la même scène. On peut ainsi disposer d’un rendu à 360d en très haute définition, pour peu que les moyens permettent d’utiliser plusieurs machines en parallèle.

Le SDK supporte ainsi les réseaux clients/serveur (jusqu’à 64 clients pour 1 serveur) mais aussi le rendu distribué. Ce support est de type “haut niveau”, ce qui permet de ne pas se préoccuper du réseau lorsqu’on travaille avec ce framework.
Le SDK fournit également un système de chat intégré pour les réseaux, ainsi que la possibilité de créer un serveur dédié (sans rendu graphique: le serveur est donc utilisé uniquement pour gérer les transactions réseaux, et il ne perd pas de ressources car il n’effectue pas d’affichage inutile).

Le multi-affichage distribué

Le multi-écrans est aussi supporté en version classique, sur une seule machine

Les sorties graphiques (stéréovision)

Le multi-écran est donc supporté de deux façons: en rendu distribué, ou en rendu multi-écran classiques. Il est également possible d’employer le multi-écrans pour représenter plusieurs angles de la même scène (c’est à dire la même scène vue par plusieurs caméras), soit pour afficher, sur l’un des écrans, la scène 3D et sur un autre écran, d’autres informations (par exemple, une notice sur un bâtiment que l’on voit dans la scène 3D).
Ce système peut passer par le réseau pour faciliter la gestion des écrans.

Neoaxis supporte aussi la 3D en stéréovision, en utilisant le rendu distribué (un client affiche l’oeil droit, l’autre client affiche l’oeil gauche, et les deux images sont mélangées dans le casque). La 3D via un seul canal d’affichage (3D @ 120Hz) est également supportée, bien que quelques petits défauts persistaient en 2010 (dans les ombrages et les reflets sur l’eau). Peu d’informations à ce sujet sur la version 1.2 (version actuelle), mais ces défauts sont normalement corrigés.

Enfin, il est possible d’afficher le rendu de NeoAxis dans un navigateur web (IE, Firefox, Google Chrome entre autres), permettant ainsi une télé-visite. Certes, cela s’éloigne de la RV, mais cet aspect est tout de même à prendre en compte puisqu’il devient alors possible d’avoir un casque de RV chez soi, sur lequel on afficherait alors l’objet web qui contient le rendu de NeoAxis; on obtient alors une télé-RV via ce SDK.

L’interface utilisateur (appliquée à la RV)

L’interface utilisateur passe habituellement par le couple clavier/souris et par l’agencement des commandes à l’écran. En RV, cela sera différent, puisqu’il faudra permettre à l’utilisateur d’interagir avec le monde 3D via des outils peu communs (gants ou bras de commande, parfois à retour de force) ou des outils plus exotiques sur PC (wiimote, Kinect,…).

Le motion control est pris en charge sur NeoAxis (cf la vidéo en motion gaming), compatible avec le multi-joueur (ce qui permet à plusieurs personnes de manipuler, en même temps, un objet virtuel via deux gants par exemple). Egalement, le système Microsoft Kinect est intégrable à NeoAxis (voir la video).

Enfin, les joystick usuels peuvent être directement pris en charge par le SDK. Il est normalement possible d’utiliser plusieurs joysticks en même temps, sur la même machine (à l’image d’un jeu en mode “écran partagé” sur console, avec 2 joueurs, 2 manettes, 1 console et 1 écran coupé en deux).

L’interface graphique (GUI)

Le SDK permet de créer rapidement une interface graphique complexe et complète, incluant par exemple:

  • L’affichage d’un HUD (texte/images statiques affichées en 2D à l’écran: attention le rendu peut être alors étrange si le HUD est mal utilisé dans un rendu stéréoscopique)

  • Création rapide d’interfaces incluant des boutons, des champs texte, des images, des vidéos, des contrôles “slide”,…
  • Lecture vidéo à l’écran, permettant de lire une vidéo et de l’afficher en 2D à l’écran, ou dans le monde 3D
  • Le support des langes asiatiques et du format UTF8 (ce support n’est pas garanti dans son intégralité)
  • Application de shaders à l’interface utilisateur (permettant l’ajout d’effets aux menus GUI)
  • Affichage d’interfaces in-game
  • Affichage d’une page web dans un GUI (via awesomium), permettant d’intégrer une page web dans une interface graphique pouvant elle-même être in-game (on peut donc croiser le monde virtuel avec une base de données extérieur, via cette page web)

Interfaces GUI in-game

Les plateformes supportées (développement et déploiement)

NeoAxis supporte actuellement les plateformes suivantes:

  • Windows (XP/7)

  • MAC

Les plateformes suivantes seront supportées dans une version ultérieure:

  • iOS

  • Android
  • Google native client

Le développement peut ainsi se faire sur Windows ou sur MAC, et le release n’en sera pas affecté. Les fichiers crées pour ce framework seront identiques, que l’on déploie sur Windows ou sur MAC (ou sur les futures autres plateformes). On a ainsi une totale liberté de choix dans la plateforme de développement et dans la plateforme de release. De plus, les plateformes pourront communiquer entre elles: il devrait ainsi possible d’avoir un serveur Windows, et des clients MAC/Windows ou autres plateformes (cela reste à vérifier en pratique).

Les langages de programmation supportés

NeoAxis supporte les scripts développés en c#. Il est ainsi possible de manipuler les objets du monde virtuel (y compris les shaders, les GUI et les modèles physiques) via ces scripts C#. Ces scripts ne peuvent pas être édités en temps réels: ils requierent de relancer le framework, ou au moins, de recharger la carte de l’environnement virtuel.
Notez que ces scripts peuvent être modifiés sans devoir recompiler le framework, puisqu’il s’agit d’un SDK.
Les scripts peuvent être créés soit via un IDE “classique” (en codant soit-même ligne à ligne), soit via une interface plus intuitive (mais possédant donc moins de libertés) qui permettra aux non-initiés de créer leurs scripts en cas de besoin.
Plusieurs IDE de développement sont supportés pour reconstruire (recompiler) le SDK, tel Microsoft Visual C#/Visual Studio, SharpDevelop ou MonoDevelop.

Le SDK fonctionne sur le principe “compile once, run everywhere”: il est possible d’utiliser le SDK que l’on a recompilé sur n’importe quelle plateforme, sans devoir le re-compiler de nouveau pour chaque plateforme.

Bien que le c# soit le langage principal, il est possible de joindre à Neoaxis des bibliothèques personnalisées, écrites en C/C++.
Des informations complémentaires sont disponibles sur la page de présentation des possibilité de programmation.

La licence commerciale donne accès à une partie des sources du SDK qui peut alors être édité et recompilé

Synthèse du framework

Neoaxis est donc un puissant framework multi-plateforme, parfaitement adapté à la RV puisqu’il en permet l’intégration facilement. De plus, étant un SDK destiné à la base aux jeux vidéos, il offre de bons rendus graphiques et de bonnes performances. Sa prise en charge du web permet de le croiser avec les bases de données et les sources internet pour enrichir le monde virtuel. Le support réseau assure la possibilité de créer des “meetings” virtuels, ou des travaux de groupe dans une salle de RV.
La licence de développement étant gratuite, il peut être essayé pour un projet donné sans devoir toucher au budget de ce projet. Les licences Indie et commerciale étant sans redevance ni limite de projet, le rapport qualité/prix de ce framework est donc excellent.
Ce framework conviendra donc à de nombreuses utilisations, particulièrement la RV, et à de nombreux utilisateurs, novices (qui seront ravis des interfaces graphiques intuitives de ce SDK) ou avancés (qui eux seront ravis de voir l’impressionnant pannel des options pouvant être modifiées, pour la plupart, “à la volée”).


Nom Frameworks pour la RV: NeoAxis
Neoaxis
Licences Non-commerciale: 0€
Autres: $95 à $295 env.
Moteur 3D Au niveau des moteurs de jeu video actuels
Moteur physique PhysX/ODE
Rendu sonore 2D/3D, format OGG
Création de sons en temps réel possible
Support des microphones
Réseau Prise en charge réseau C/S
Rendus graphiques distribués
Sorties graphiques Ecran stéréoscopiques
Navigateur Web
360 degres
E/S utilisateurs Joysticks
Wiimote
Kinect
Interfaçage avec d’autres E/S possibles
GUI Customisable
Aisé à créer
Intégrable au monde 3D
Plateformes Windows
MAC
A venir:
iOS
Android
Google native client
Langages C#
Support de librairies C/C++
Scripts C# sans recompilation
Compile once run everywhere

Démo web

Licence Creative Commons
Cette œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution – Partage dans les Mêmes Conditions 3.0 France.
Auteurs: MONIER Vincent, SFEIR Raphael

Utilisation de moteurs 3D pour la réalité virtuelle

La Réalité Virtuelle

Il n’y a encore pas si longtemps, les auteurs de science fiction imaginaient de voir les hommes évoluer dans un univers virtuel. Un monde artificiel de données où l’utilisateur serait immergé grâce à des interfaces sensorielles pour le son, la vue, et parfois le toucher ou même l’odorat.

Neuromancien de W. Gibson

Neuromancien, de W. Gibson, l'un des premiers romans de SF où le "cyberspace" fait son apparition

Depuis, si la science-fiction n’est pas encore devenue une réalité, la Réalité Virtuelle a grandement profité des progrès technologiques de ces dernières décennies. De nombreuses applications de Réalité Virtuelle ont ainsi pu voir le jour : applications industrielles, simulations, traitement médical, expériences artistiques ou vidéoludiques…

Le Virtual Boy, quand Nintendo s'essaie à la RV et échoue

Seulement, pour fonctionner, une application de Réalité Virtuelle nécessite un important dispositif matériel et logiciel. Nous allons nous intéresser tout au long de cette veille technologique à un élément clé de ce dispositif : le framework de développement 3D.

Un Framework 3D?

En effet, pour modéliser l’univers virtuel, on utilise un framework de développement 3D.
Cet outil propose un large éventail de fonctionnalités que l’on pourra exploiter pour créer l’univers virtuel : un moteur 3D, un moteur physique, un moteur audio, de nombreuses bibliothèques réseau, et bien d’autres choses encore…
De nombreux frameworks existent, notamment dans le cadre du développement de jeux vidéos 3D : Unity, OGRE3D, UDK, UNiGiNE

Un framework 3D comme Unity fournit de nombreux outils pour développer un jeu vidéo.

Utiliser ces frameworks dans la Réalité Virtuelle

Cependant pour permettre à l’utilisateur d’interagir avec la Réalité Virtuelle, il est indispensable d’utiliser un framework 3D disposant de plus de fonctionnalités qu’un framework ordinaire. Certains de ces frameworks sont plus adaptés à la réalité virtuelle que d’autres.
Pour une meilleure application de Réalité Virtuelle, l’outil devrait par exemple prendre en charge les fonctionnalités suivantes…
• La gestion des interactions de l’utilisateur avec la Réalité Virtuelle
• Rendu stéréoscopique
• Rendu multi-écran
• Système de suivi de mouvements de l’utilisateur (ou système de tracking)

Vincent Monier et Raphaël Sfeir, deux élèves de l’École Centrale de Nantes intéressés par un sujet aussi immersif, vont passionnément étudier les frameworks 3D existants pour déterminer lesquels sont les plus adaptés à une application de Réalité Virtuelle et identifier leurs avantages et inconvénients.
Ce projet sera encadré par Jean-Marie Normand, professeur à l’École Centrale de Nantes.