Présentation

Le système solaire est un espace immense en comparaison à la taille des objets qui le composent. Si nous l'avions modélisé en utilisant une échelle réelle (c'est-à-dire des proportions linéaires), nous n'aurions vu que du noir, avec peut-être pour seul repère le soleil. Les planètes, quant à elles, seraient réduites -- au mieux -- à de simples pixels.

Aussi avons nous décidé d'utiliser une échelle logarithmique. Les Astres sont ainsi tous bien visibles. Nous avons utilisé la formule :

SPSD = SESD x log (10 x PSD / ESD)

où :

* SPSD = distance planète-Soleil avec un facteur d'échelle

* SESD = distance Terre-Soleil à l'échelle (20)

* PSD = distance planète-Soleil réelle

* ESD = distance Terre-Soleil réelle = 1 Unité Astronomique (UA)

Seulement un problème apparaît alors : les trajectoires des satellites entre les planètes adjacentes se croisent. Nous avons donc dû encore une fois utiliser un facteur d'échelle adaptatif (logarithmique également).

Cependant le fait d'utiliser le même facteur d'échelle pour toutes les planètes est aussi problématique, dans le sens où ce sont parfois les satellites d'une même planète qui se touchent. Le facteur dépend donc des dimensions des planètes, ce qui permet de se rapprocher (très grossièrement) les proportions des satellites.

Au fur et à mesure de la modélisation du système solaire, nous nous sommes rendus compte que l'affichage devenait de plus en plus lent et saccadé. Pour avoir un résultat satisfaisant sur les machines de base, nous avons donc choisi de ne modéliser que les satellites principaux (les plus gros) pour chaque planète. De plus compte tenue de la taille relativement petite des satellites conservés, les satellites supplémentaires auraient été difficilement visibles.

Nous avons quand même essayé de représenter un système assez réaliste. Pour cela nous avons tenu compte d’un certain nombre de paramètres physiques réels :

• inclinaison des orbites par rapport à l'écliptique
• inclinaison des orbites des satellites par rapport au plan équatorial de leur planète
• inclinaison des axes de rotation sur elles mêmes des planètes
• périodes de révolution solaire réelles
• périodes de rotation des satellites autour de leur planète réelles
• périodes de révolution planétaires réelles
• le Soleil parait plus orange quand on s'en approche
• illumination de l'ensemble par le soleil

Nous avons choisi comme unités de référence celles liées à la Terre :

1 UA = 20 unités de distance VRML

1 jour = 1 unité de temps VRML

Les données physiques ont étés trouvées sur le web [2]

Voici une copie du tableau Excel que nous avons utilisé pour faire nos conversions :

Le fichier servant à lancer la scène complète est SOLAIRE.WRL, mais nous avons fait différentes versions. Il est donc plus intéressant d'utiliser le lien en bas de cette page.

Planètes :

Bien que dans la réalité les planètes soient un peu écrasées au pôles, nous avons modélisé tous les astres par les sphères primitives que propose le VRML. Nous leur avons appliqué des textures photographiques, parfois recolorisée et modifiées par nos soins. La plupart ont été trouvées sur Internet [1].

Les planètes sont toutes calquées sur le même modèle définit par un Prototype (fichier Planete.wrl). Il en est de même pour les satellites (fichier satellite.wrl). Nous avons tout de même un fichier par planète car toutes n'ont pas le même nombre de satellites, et il a fallu les attacher "manuellement".

Une planète est particulière : Saturne. Pour modéliser ses anneaux, nous avons plaqué une texture au format GIF au niveau de son équateur, en utilisant un cube très fortement aplatit (un carré donc) perpendiculaire à l’axe de rotation. Ce format de fichier est intéressant car il permet de rendre des zones transparentes. Ainsi les parties de la texture ne correspondant pas aux anneaux ne sont pas visibles, et on ne voit pas le cube écrasé sur lequel est appliquée la texture.

• Textes :

Nous avons affiché son nom au dessus de chaque planète afin que l'on puisse les reconnaître d'assez loin. Le texte reste constamment horizontal face à l'utilisateur. Pour cela, nous avons utilisé un "Billboard" avec un "axisOfRotation" à "0 0 0" . Comme nous ne voulions pas que le texte soit affecté par l'illumination de la scène, nous lui avons donné une émission propre maximale.

Il est possible de désactiver l'affichage du texte indépendamment pour chaque planète. Pour cela, il suffit de cliquer sur la planète ou sur son nom. Un script Vrml est alors invoqué. Ce dernier joue en fait le rôle d'une bascule, et permet de faire réapparaître le nom de la planète lorsqu'on clique à nouveau dessus.

 

• Orbites :

L'une des premières choses que l'on remarque sont les grands cercles concentriques. Ils matérialisent les trajectoires des astres autour du Soleil.

Notre première idée a été de dessiner ces orbites à l'aide de cylindres écrasés dont nous avons ôté les faces supérieures et inférieures. Cependant trois problèmes se sont posés. D'une part le niveau de résolution des primitives VRML est assez faible, et on voyait nettement les droites formant les côtés du cylindre. D'autre part, un cylindre a une hauteur : et on la voit quand on s'approche trop, et si on la choisi très petite, on ne voit plus la trajectoire de loin... Et finalement, le problème le plus grave, c'est que les facettes du cylindre sont orientées, et que seules celles situées vers la caméra sont visibles. Nous avions des "arcs de cylindres".

Nous avons donc décidé de dessiner des cercles avec un "IndexedLineSet". A l'aide d'un tableur, 128 points on étés calculés, correspondant à un cercle de rayon 1. Pour obtenir les différentes orbites, il nous suffit alors de faire un "scale" de la valeur du rayon de cette orbite.

Les orbites des planètes sont tracées d'une couleur plus claire que celle de leur satellites. Le PROTO définissant le cercle (voir fichier cercle.wrl) prend donc en paramètre une couleur.

• Les vues :

Afin de faciliter l'observation, une caméra ("Viewpoint") à été "attachée" à chaque planète. Elle est positionné de la même façon par rapport à chaque planète, et nous avons donc utilisé un PROTO, dont le seul paramètre est le nom de la vue à afficher dans le menu 'view' de la visionneuse VRML. (voir fichier Vue.wrl)

Pour réaliser cela, nous avons utilisé le même "TimeSensor" et le même "OrientationInterpolator" que celui servant à faire orbiter la planète à suivre. Une simple translation et une rotation permettent alors de positionner la caméra par rapport au centre de l'astre à suivre. Les déplacements manuels de l'utilisateur gardent alors le mouvement de la planète, et il faut choisir une vue statique si l'on veut pouvoir explorer à sa guise le reste du système.

Lors des tests de mise en place des caméras, nous avions accéléré l'année pour bien mettre en évidence le déplacement. Là, tout marchait parfaitement. Cependant, lorsque nous avons remis les paramètres de temps réels, nous avons observé un décalage gauche-droite de la caméra par rapport à la planète. Nous supposons que c'est un bug VRML ...

• Le vaisseau et les sons

Si vous regardez bien (ou si vous écoutez bien ...) vous trouverez un vaisseau spatial extraterrestre en perdition dans notre système solaire, qui virevolte autour du soleil tel un insecte fou... Il est énorme car ses occupants viennent d'une planète à très faible gravité, et ils sont de véritables géants ! :o)

Bon, plus sérieusement, si nous l'avions mis à échelle humaine, personne n'aurait pu le voir.

Le modèle du vaisseau a été récupéré sur le web dans une banque de modèles 3D libres de droits [3]. Nous l'avons converti de son format 3DStudio Max original en un modèle VRML avec 3DSmax v3. Il est assez détaillé, aussi ralentit-il la scène globale de façon sensible. Pour éviter cela, nous aurions pu utiliser des niveaux de détails (LOD) qui peuvent être facilement obtenus avec les fonctions de réduction de polygones que l'on trouve dans de nombreux logiciels de modélisation 3D. Cela aurait été une bonne chose, d'autant plus qu'on est souvent très loin du vaisseau. Cependant nous ne l'avons pas fait car nous avons constaté que lorsqu'on éloignait le point de vue de l'engin, l'animation devenait plus fluide. Cela veut dire que OpenGL, ou Direct3D, intègrent certainement une telle fonction de simplification à leur niveau.

Le déplacement du vaisseau est une combinaison de trois interpolateurs d'orientation, et d'un de position. En choisissant bien les cycles de temps pour chacun d'entre eux, on donne l'apparence d'un mouvement chaotique. Si nous avions déterminé des points clefs d'une trajectoire, celle si aurait été trop répétitive, et de plus, on aurait pas eu l'impression que le vaisseau se déplace dans le sens de sa longueur, mais avec des translations latérales étranges (autrement dit, l'avant ne se trouverait pas toujours devant )

Le bruit des réacteurs venant de la navette à été fait à la bouche ! (normalement il n'y a pas de son dans l'espace, mais ce vaisseau extra-terrestre perd une telle quantité de carburant que la densité des particules perdues porte le son autour de l'engin) C'est donc un son échantillonné, au format WAV. Il est assez court, et est joué en boucle. Comme le permet le VRML, il est également "spatialisé", c'est-à-dire qu'il change en intensité en fonction de la distance de l'observateur, et passe de gauche à droite (ou l'inverse) selon le déplacement.

La musique d'ambiance, quant à elle, est au format MIDI, car c'est le format ayant le meilleur rapport taille / durée. Bien que sa qualité dépende directement du périphérique MIDI de l'utilisateur, c'est le format le plus adapté aux contraintes de temps de transmission sur le web.

Nous avons tenté beaucoup de choses, et certaines n'ont pas marché.

Nous avons par exemple essayé de faire que le nom des planètes n'apparaissent que lorsque le pointeur de la souris se trouve sur la planète. Mais il semble que les scripts VRML aient un comportement étrange, et cela n'a pas fonctionné.

Afin de rendre la navigation d'une planète à l'autre plus agréable, nous avons voulu mettre un frame HTML dans lequel des icônes des planètes contenaient des liens vers les différents ViewPoints VRML. La documentation de CosmoPlayer précise qu'il est tout a fait possible de faire ça, en utilisant le système des ancres HTML, et donne même un exemple. Malgré tous nos efforts, cela n'a pas marché ("page introuvable").

Nous avons alors essayé de créer une applet JAVA contenant des boutons avec les dessins des planètes, qui permettraient de se rendre à celle-ci directement (mais sans animation malheureusement). Cela a très bien marché pour une scène simple, mais des bugs sont apparus lorsque nous avons chargé le système solaire dans son intégralité. En fait, la scène semble être trop lourde a charger, et l'applet, qui cherche a établir un lien, n'y parvient pas. Lorsque par la suite nous ouvrons un nouvelle fenêtre contenant cette même applet, il est arrivé que ça soit celle-ci qui prenne le contrôle de la scène VRML...

Nous avons là, sans aucun doute, affaire à un bug de CosmoPlayer.

De plus, notons que les applets JAVA écrites sont spécifiques à CosmoPlayer. Et nous n'avons aucune garantie quant au fait que l'utilisateur utilise ou pas cette visionneuse. Il faudrait donc un script qui teste le modèle de visionneuse présent, et lancer une applet adaptée à celle-ci ! C'est lourd ...

[1] www.nationalgeographic.com (pour les idées générales)

[2] www.seds.org/nineplanets/nineplanets/ (pour les données physiques)

[3] avalon1.viewpoint.com (pour le vaisseau)