 |
Vendredi 19 avril 2024 - 20:33 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Le dernier Tilt testait les principaux logiciels d'animation... que les vrais pros n'utilisent pas. Ils emploient des méthodes très différentes selon les effets recherchés. Tilt a arraché leurs secrets aux programmeurs de Gunship, de Pirates, de Defender Of The Crown, de l'Arche Du Captain Blood. Explosif !
Après avoir bouclé le dossier sur les logiciels d'animation présenté dans le dernier numéro de Tilt, une horrible angoisse nous étreignit : la rédaction n'allait-elle pas sombrer sous les coups de fil de lecteurs déçus de ne pouvoir réaliser, à l'aide des programmes testés, le tournoi de Defender Of The Crown, les défilements véloces de Goldrunner, les acrobaties des Jet, F16 ou Cessna au-dessus de paysages reconstitués sur l'écran des simulateurs de vol ? Nous avons voulu savoir comment se font les meilleures animations des jeux que nous testons. Comprendre pourquoi les résultats sont, sans doute définitivement, hors d'atteinte des programmes disponibles dans votre boutique favorite.
Le Moyen Âge ressuscité
L'écran représente une place de tournoi. Votre adversaire galope vers vous, lance en avant. Vous dirigez la vôtre pour désarçonner le chevalier qui grossit en se rapprochant. Le point d'impact de votre arme, à la base du bouclier de l'autre, va-t-il vous permettre de l'éjecter de sa monture ? Pas le temps de réfléchir : l'angle de vision se modifie, ce qu'on appelle au cinéma un changement de plan : vous voyez maintenant la scène de profil. L'un des combattants a vidé les étriers. Le jeu continue.
Ces quelques secondes durant lesquelles vous galopez par l'intermédiaire d'un écran animé avec une perfection quasi cinématographique produisent une sensation de relief à vous couper le souffle et marquent le sommet, par nature provisoire, de l'art d'animer des personnages, premier aspect principal de l'animation logicielle.
Avez-vous remarqué que dans la plupart des programmes, les héros sont le plus souvent représentés de profil ? Rares sont les sprites, les lutins, c'est-à-dire les personnages mobiles, qui donnent l'illusion du relief, d'exister en trois dimensions. Ce style d'animation repose sur une répartition du travail entre graphistes et programmeurs. Les graphistes mettent au point les lutins, avec toutes leurs positions, en nombre suffisant pour donner une illusion de fluidité. Les programmeurs organisent la succession des positions sur l'écran pour créer le mouvement.
Le nombre de dessins par mouvement dépend du niveau d'ambition des auteurs ainsi que de la vitesse des gestes. En principe, un mouvement très rapide exige peu d'étapes intermédiaires : hache levée, hache baissée. Un mouvement lent consommera plusieurs positions du bras entre le moment où vous levez votre arme au plus haut et celui où elle entaillera le crâne de votre adversaire.
Un test de mouvement : les six étapes du geste
C'est sans doute Coktel Vision, dont les graphistes travaillent à Boulogne et envoient leurs oeuvres aux programmeurs à Bordeaux, qui marque le mieux la différence des fonctions. Décomposer le sprite en plusieurs éléments (dessiner séparément les bras, les jambes, la tête, les yeux) donne plus de travail aux programmeurs mais présente deux avantages principaux : d'abord en combinant les mouvements des différentes parties du corps, d'obtenir un très grand nombre de variantes (certains personnages de Pirates avec 32 images de base par personne pourront prendre une centaine d'attitudes au cours du jeu par suite de ce découpage en éléments, tout en occupant 4 ko de mémoire, ce qui est remarquablement peu). Ensuite, limiter la surface des éléments mobiles fait gagner de la place en mémoire plutôt que de stocker quatre personnages complets mieux vaut stocker quatre expressions du visage et quatre mouvements du bras.
Ce caméléon consommerait beaucoup de mémoire,
certes, le décor est unique mais l'animation oblige à redessiner beaucoup de choses
Le papillon change de forme, la tête aussi tandis que
le coup de langue oblique oblige à redessiner une zone de 1/3 de l'écran
Robert Landero, directeur artistique chez Cinemaware, revient sur l'animation de Defender Of The Crown. Le travail initial a commencé avec Aegis Animator. L'arrivée vers l'écran du chevalier que combat le joueur a demandé une trentaine d'images, de taille croissante. L'impression de mouvement dans le sens de la profondeur est obtenue seulement par la variation de la taille du lutin en cours d'animation.
Les caractéristiques communes des animations de ces aventures : fond statique, changement d'écran par substitution d'images à une autre, sprites de personnages animés se déplaçant "à la surface de l'écran" n'empêchent pas d'aller assez loin dans l'illusion de la 3D.
La variation de la taille des sprites au cours de leurs évolutions simule des déplacements "en profondeur". La représentation de salles en perspective (comme dans Crafton et Xunk) aboutit au même résultat sans changement d'échelle des personnages. Mais ceux-ci, au lieu de se déplacer horizontalement, se meuvent en diagonale sur une grille aux mailles en forme de losanges. Au lieu de les présenter de profil (vers la droite ou vers la gauche), on les voit de trois-quarts. Ils se déplacent en diagonale de l'avant vers le fond de l'écran et inversement.
Quatre attitudes de base sont nécessaires et les programmeurs doivent distinguer les quatre impulsions initiales de la manette. Encore faut-il saisir la nature de l'impact des décisions des joueurs. Si leurs ordres sont de simples déclencheurs d'animations entièrement prédéterminées, le travail des programmeurs s'apparente à de la couture. Le programme aura une structure simple : "coller" la partie d'image n°1 sur tel emplacement de tel fond à l'instant 1, puis "coller" la partie d'image n°2 sur tel emplacement voisin du même fond à l'instant 2, un dixième ou un vingtième de seconde après. L'opération répétée autant qu'il est nécessaire, avec des morceaux d'images représentant des sujets animés donne de bons résultats mais laisse les joueurs spectateurs. L'intervention dans le déroulement de l'histoire passe par les dialogues ou les icônes (Shadowgate, King Of Chicago).
Le programmeur doit gérer les gouttes-luttins, et leurs deux formes,
avant et après le rebond sur le sol qui les fait exploser
Il superpose ensuite plusieurs images du centre de l'écran
dessinées par les graphistes, les stades de croissance de la plante
Si l'on souhaite une animation interactive, il faut prévoir à chaque affichage, une batterie de tests : le sprite est-il sur les parties de l'écran où il peut se trouver, quelle est la dernière impulsion du clavier (ou de la manette, de la souris). Selon les cas le test choisira entre plusieurs possibilités et affichera à l'écran des images variées combinant le déplacement du sprite et un changement de forme.
Les personnages se baladent donc sur une sorte de carte dont les secteurs soumettent au programme des tests particuliers et laissent aux sprites des latitudes de déplacement différentes : on conçoit sans peine que tous les micros n'accepteraient pas 25 fois par seconde d'exécuter des programmes complexes aux multiples branchements logiques avant même de savoir quelle image chercher et où l'afficher. Le Barbarian de Psygnosis, comme celui de Palace Software, fournissent des exemples frappants. On peut, à la limite, les considérer comme curseurs sophistiqués !
La qualité de l'animation, avant même le déploiement de ressources techniques, repose sur le réalisme des mouvements. Les artistes des siècles passés étudiaient l'anatomie et s'entraînaient à dessiner les personnages nus pour obtenir des attitudes naturelles même dans des compositions avec des modèles habillés des pieds à la tête.
Certains graphistes se sentent suffisamment assurés pour créer des animations en s'appuyant sur leurs seules imagination et intuition comme Michael Haire de MicroProse. L'équipe de Coktel Vision, qui travaille sur leur projet Kilombo, un jeu d'aventure/action parmi les esclaves d'une grande plantation, a commencé par animer des silhouettes simplifiées des personnages pour juger du rythme et de la souplesse du résultat. C'est seulement quand les mouvements ont été mis au point que les graphistes ont travaillé à donner leur aspect définitif aux différents protagonistes du logiciel. D'autres encore s'appuient sur des images numérisées, voire des extraits de films vidéo. Cinemaware ou Palace Software avec Barbarian ont ainsi appelé le réel à s'unir aux talents, de leurs programmeurs.
L'outil d'animation de MicroProse au travail
L'animation par les couleurs
Sans développer de programmes spécifiques, les programmeurs peuvent se servir des fonctions de cycle des couleurs des programmes graphiques. En décidant un cycle entre différentes nuances de bleu, faire couler une rivière, animer la surface de la mer, deviennent des jeux d'enfant, si l'on dispose de Deluxe Paint ou de tout autre programme graphique de qualité. Mais le recours trop systématique à ce procédé lasse vite, à moins d'y travailler avec beaucoup d'imagination.
Ces fonctions permettent, en effet, d'animer l'ensemble d'un écran sans consommer trop de ce précieux espace des disquettes. Pour Rocker Ranger, en cours de mise au point, Cinemaware manipule les couleurs afin d'obtenir de très spectaculaires mutations des écrans qui passent de la couleur au noir et blanc en une atténuation très fluide des teintes, sans saut de nuances ou scintillement.
Les beaux défilements ne coulent pas de source ! Un décor multicolore de pyramides, quelques faces grimaçantes en bas-relief. Un ou deux engins sommeillent au bas de l'écran d'un Space Invader. La lumière du lecteur de disquette s'éteint. Effleurez la manette ou la souris. Le décor commence à défiler, insistez, il accélère tandis qu'une pluie d'engins agressifs déboule du haut de l'écran. Le défilement de l'écran devient si rapide que l'oeil saisit mal les décors. Les ennemis saisissent bien l'intérêt pour eux de cette accélération incontrôlée et votre engin explose en une gerbe de feu.
Ici, les engins sont des sprites, tout comme les personnages des aventures/action. Mais avec un changement de priorités : pas de transformation du sprite lui-même (ou peu) mais l'attention se porte sur la gestion de leurs trajectoires, des impulsions envoyées par la souris, la manette ou le clavier, ainsi que par leurs collisions. En revanche, le déroulement des décors, le défilement, pose des problèmes originaux.
Les défilements constituent le deuxième grand volet de l'animation. Les lents posent plus de problèmes que les rapides sur un Atari un écran mobilise 32 ko en mémoire. Déplacer tout l'écran d'une ligne est une lourde opération pour le processeur. Et comme il doit en plus gérer plusieurs sprites, détecter leurs collisions éventuelles voire s'occuper du son, il ne saura pas répéter 25 ou 50 fois par seconde cette opération. Il y aura quelque part sur l'écran un petit problème, on verra une ligne sauter, ou un scintillement. Si l'action se déroule à un sain d'enfer et que les déplacements s'effectuent en décalant l'écran de 8 ou 16 lignes à la fois, les petits problèmes passeront inaperçus puisque l'oeil ne saura pas les fixer. Sur ce plan, l'Amiga dont le processeur 68000 est soulagé par des coprocesseurs, est nettement avantagé par rapport au ST dont le 68000 travaille en solo. Il gère sans problème des défilements horizontaux.
Aucun avion ne vole par saccades
Votre avion perd de l'altitude. Vous commencez à distinguer les détails du sol. La piste grossit, des collines pyramidales bossèlent l'horizon. Les principaux bâtiments deviennent visibles. Mais arrivé au-dessus de la piste, à basse altitude, au niveau de la tour de contrôle, votre vitesse est trop importante. Remettez les gaz. Tournez autour des hangars de l'aéroport que vous voyez sous toutes leurs faces en perspective. Revenez dans l'axe de la piste à petite vitesse. L'avion se pose. Comment l'écran arrive-t-il à animer en trois dimensions un paysage selon une infinité virtuelle de points de vue ? Les simulateurs illustrent au mieux le troisième pan du problème, celui du mouvement dans un univers en 3D.
Nous avons interrogé Sid Meyer qui travaille chez MicroProse à propos de Gunship, un simulateur d'hélicoptère aux paysages particulièrement soignés, en 3D (montagnes, rivières, armées ennemies) tout en restant rapide. Le mouvement s'effectue au rythme de quatre à cinq images par seconde. Les images sont calculées en temps réel. L'action se déroule sur 50 à 100 miles carrés (200 km2). Les plus petits détails représentés sont les chars d'assaut. L'infanterie se manifeste seulement par le nuage de poussière qu'elle soulève.
Il n'existe pas de "maquette" du paysage. Ce sont des banques de données qui en font office. L'une d'entre elles regroupe les positions des éléments du paysage (montagnes, rivières, routes). Une autre précise à quoi ressemble une colline, une route, une rivière. Un troisième élément permet le repérage des éléments mobiles (en particulier de l'hélico). C'est au programme de calculer quatre fois chaque seconde, en combinant ces éléments, ce qui doit s'afficher à l'écran.
Comment avez-vous obtenu un programme si rapide ?Sid Meyer : C'est le résultat de deux ans de travail, de deux ou trois réécritures d'un programme en langage machine. De plus, les éléments contiennent le moins possible de points pour se calculer vite. La partie qui assure l'animation occupe environ 40 ko sur la disquette.
Avez-vous utilisé des programmes graphiques ?Non, les instruments de programmation mis au point par MicroProse doivent être rapides et générer du langage machine. Ils ne sont ni faciles à utiliser, ni très conviviaux.
Les algorithmes ont de jolis reliefs
Commandant du vaisseau Tilt dans Starfligt d'Electronic Arts, je le dirige vers la sixième planète d'une des centaines d'étoiles accessibles. Je me satellise. J'ordonne au navigateur d'entamer les manoeuvres d'atterrissage. La planète tourne sur l'écran du PC. J'ordonne l'atterrissage. Je choisis sur une carte la destination du vaisseau. Puis la planète grossit sur l'écran, le PC entame un zoom vertigineux qui me fera apercevoir sans cesse plus de détails jusqu'à l'atterrissage sur un terrain ondulé et multicolore. D'aussi spectaculaires atterrissages me sont réservés sur chacune des centaines de planètes, chaque animation me fait découvrir des paysages différents.
Je dirige l'Arche Du Captain Blood, le vaisseau fonce au ras des collines représentées en silhouettes bleues. Je ralentis ou accélère, monte où descend à volonté. Malgré la ressemblance des résultats avec les simulateurs, ces animations forment un quatrième type, soumis à un bel avenir. Comment, en effet, les malheureuses disquettes peuvent-elles aller générer des reliefs différents sur plusieurs centaines de planètes sachant que l'on peut les observer selon une infinité d'angles différents et qu'un écran "mange" plusieurs milliers d'octets ?
La ruse vient de ce que les coordonnées des surfaces des planètes si nombreuses sont calculées au moment d'être affichées, et non pas stockées en mémoire. Didier Bouchon a programmé l'Arche Du Captain Blood :
Comment as-tu dessiné les reliefs des planètes
que l'on survole. As-tu préalablement dessiné un plan ?Il n'y a pas de carte, c'est un algorithme de calcul qui décide de l'aspect des surfaces. Si l'on voulait stocker la géographie de chaque planète, cela prendrait beaucoup trop de place.
La partie du programme gérant
l'animation des surfaces est-elle importante ?Non, mais elle est difficile à donner avec précision puisqu'elle est répartie en plusieurs sous-programmes disséminés. Disons à peu près 20 ko. En revanche, en mémoire centrale, le programme utilise un gros tampon mémoire d'images (un tampon mémoire est une "salle d'attente" des données, permettant de stocker les coordonnées calculées aussi vite que la machine en est capable et affichées sur l'écran au rythme exigé par l'action).
Les planètes diffèrent-elles chaque fois
qu'on va les voir ?Non, parce que le générateur de nombres et de coordonnées utilisé part de la "graine" de la planète, constituée par ses coordonnées dans l'espace. A partir de ce petit nombre de données, le programme calcule une surface irrégulière dont des profils sont représentés par des lignes bleues à l'écran.
C'est-à-dire que la surface de la planète
pourrait être calculée et représentée avec une trame plus serrée ?Oui, elle est calculable, à partir des données de la "graine" pour tous les points. Dons certains pics ont un sommet entre deux dus lignes affichées et n'apparaissent pas à l'écran. Mais si l'on voulait calculer plus de points, le vaisseau ne pourrait pas voler aussi vite, la machine ne suivrait pas.
C'est la même méthode de calcul
pour toutes les planètes ?Dans son principe oui, mais certaines variables changent pour éviter que les planètes aient la même allure. On pourrait, à l'avenir, essayer de mélanger ces méthodes de calcul avec les techniques des simulateurs de vol. Mais on risque de buter sur des questions de rapidité. C'est la représentation du relief qui provoque les problèmes : dans un simulateur de vol, l'horizon est plat. Quand l'avion évolue, la ligne d'horizon reste une ligne, les détails du paysage apparaissent quand ils sont assez proches. Si le paysage est en relief, cette ligne est calculée, ainsi que tous les reliefs sur une très grande surface. Il faut alors un trop long temps de calcul...
Au-delà des aspects propres à chaque grand type d'animation, les programmeurs chargés de l'animation des jeux rencontrent des problèmes communs.
Les animations ne se déménagent pas
Les graphismes passent d'une machine à l'autre, mais les animations s'accrochent ! Lors de l'adaptation d'un jeu d'une machine à une autre, le transfert des graphismes ne pose pas de problèmes insurmontables. A condition de développer sur des PC assez puissants ou sur l'Amiga, aux meilleures capacités graphiques, le transcodage des images est effectué par un programme qui simplifie l'image et l'adapte aux capacités des ST, PC, CPC ou Thomson. En revanche, les animations exigent une reprogrammation complète. Ceci explique pourquoi MicroProse met son point d'honneur à ne pas transcoder bêtement les programmes, mais le plus souvent à reprogrammer les versions d'un logiciel qui tournent sur des machines différentes. Ce luxe s'appuie donc sur une nécessité.
Plus près de toi machine !
Les animations des programmes de jeu exigent beaucoup de compétence de la part des programmeurs, qui ne peuvent pas s'aider des logiciels disponibles. Leur objectif est en effet de résoudre un problème spécifique, car les méthodes diffèrent du tout au tout selon qu'on programme une aventure, un Space Invader ou un simulateur de vol. Ils doivent tenir compte des limitations propres à chaque machine (par exemple tenir compte de la variété des vitesses des PC dont la fréquence d'horloge interne rendra le même jeu désespérément lent ou injouable de rapidité). Ils sont contraints de programmer au plus près de la machine, en langage machine, pour gagner du temps d'exécution. Ils doivent jouer de toutes les particularités des processeurs, y compris celles qui n'avaient pas été prévues par les concepteurs des circuits.
Ainsi, les processeurs vidéo de l'Amstrad CPC se trafiquent plus facilement que ceux de l'Atari ST. Ainsi, l'Amiga fait des défilements verticaux et horizontaux superbes, mais l'Atari ST renacle à déplacer horizontalement les 32 000 octets de ses écrans graphiques. Au contraire, les progiciels d'animation doivent savoir faire le plus de choses différentes possibles et une lenteur raisonnable leur est facilement pardonnée.
En revanche, les acheteurs exigent une simplicité absolue d'utilisation, des manipulations minimums et un affichage immédiat des décisions prises par les utilisateurs. Les programmes peuvent occuper toute la disquette et monopoliser le processeur principal du micro. Son et animation posent des problèmes aigus de compatibilité, qu'une programmation ne résout pas. L'évolution du matériel risque-t-elle de bouleverser les méthodes d'animation de jeu ?
L'avenir s'écrira sur les CD-i
Tous les éditeurs, tous les programmeurs sont d'accord : il y aura des jeux étonnants sur CD-i. Le CD-i c'est le "Disque Compact Interactif". A peu près l'équivalent de mille disquettes, 600 mégaoctets d'information. Pas tout de suite bien sûr. Première, excellente et unique raison pour écrire des jeux sur CD-i, il faut que des lecteurs enregistreurs de CD-i soient disponibles. Rendez-vous dans deux ans pour assister au démarrage explosif du nombre de logiciels sur ces supports. A moins que, comme souvent en matière de micro, le processus ne prenne un peu de retard.
Tous les problèmes techniques du matériel ne sont pas réglés. Atari, Philips, Sony n'en collaborent pas moins avec des éditeurs de jeux, notamment français, pour que la sortie en masse de ce support coïncide avec la sortie de jeux de qualité. Car les principaux éditeurs affirment qu'ils sont prêts à sauter le pas. Les programmeurs voient la diffusion du CD-i comme une libération. En effet, la taille limitée des mémoires de masse, des disquettes, les ennuient énormément. Ils ont l'impression de travailler à créer une minorité de leur temps et de passer le plus clair de leur énergie et d'utiliser leurs qualifications les plus pointues à grignoter des octets pour faire tenir les programmes et les données sur les disquettes trop exiguës.
Dès qu'ils parlent concrètement, leur point de vue se comprend animer un sprite à 25 ou 50 images par seconde se pratique aujourd'hui avec des objets ou personnages en translation simple, qui se déplacent sur l'écran mais changent peu de forme. Si l'ordinateur lit sur le CD-i et stocke en mémoire centrale plusieurs dizaines de mouvements, on peut espérer des animations fluides sans saccades, proches de la qualité des mouvements du cinéma. Aux programmeurs de se débrouiller pour "cacher" dans les temps morts de l'action ou du scénario les moments des accès aux données. Non seulement les animations deviendront quasiment parfaites, mais encore on pourra en multiplier le nombre et la durée. L'appel aux animations obtenues par des caméra-vidéo, plus ou moins retravaillées donnera lieu, pour leur production, à d'intéressants tournages des acteurs joueront plusieurs variantes d'un scénario, pour que leurs gestes, retravaillés par des logiciels graphiques, servent de support à des animations au réalisme inégalé. Ces territoires des fictions interactives resteront longtemps un terrain d'aventures incomparables.
Le problème sera de programmer assez astucieusement pour précalculer et stocker sur disque le maximum d'images. Ainsi pour les simulateurs de vol : les bases de données de paysages qui font l'objet de la douzaine de disquettes de Flight Simulator les "scenery disk" passeront sur le disque, Et les avions rencontrés, qui occasionnent les mouvements les plus rapides, pourront être stockés à différentes échelles et presque sous tous les angles en couleur et non plus calculés en représentation filaire. Car le temps de calcul d'objets complexes et en couleur par les micros interdit absolument qu'ils participent à des animations calculées en temps réel. Reste, comme le remarque Sid Meyer, que "si le CD-i offre beaucoup de possibilités, on ne mesure pas la qualité d'un jeu au nombre d'images et à la durée des animations. On jugera toujours si un jeu est bon ou non. Le CD-i ne garantira pas automatiquement de bons résultats !".
Entretien avec Michael Haire
Vous êtes graphiste chez MicroProse. Lors
de la phase de conception des animations, recevez-vous des directives précises ou êtes-vous
libre de créer selon votre inspiration ?Tout dépend du jeu, des créateurs, et des contraintes techniques. Les simulations par exemple ne laissent pratiquement aucune marge de liberté. Mettre au point un jeu est un travail d'équipe.
Une séquence d'animation type demande
beaucoup de temps de travail ?Nous commençons par dessiner les images de base, ce qui prend en gros trois jours. Ensuite interviennent les problèmes liés à la complexité de la situation, problèmes qui peuvent nous retenir plus longtemps.
Comment procédez-vous pour obtenir
l'animation d'un mouvement ? Vous travaillez sur des modèles ?L'artiste se base essentiellement sur son jugement, voire sur son intuition. Par exemple, un de mes collègues est un passionné de voiliers. Il a donc réalisé l'animation des séquences dans lesquelles apparaissent les bateaux et l'océan dans Pirates. Nous avons testé plusieurs maquettes avant d'obtenir la version finale.
Combien d'images utilisez-vous pour
un mouvement donné ? Par exemple un personnage qui voudrait fendre du bois à la hache ?Nous le ferions en six ou huit images. Bien entendu, on pourrait obtenir une meilleure fluidité du mouvement, il suffit d'augmenter le nombre d'images. Mais il faut constamment se préoccuper de l'espace mémoire occupé par le programme.
Les techniques d'animations diffèrent-elles
sur un 8 bits ou sur un 16 bits ?Si nous travaillons sur C64, les limites de la machine concernant les couleurs et la résolution nous simplifient le travail. Pour obtenir une animation convenable sur cette machine, il faut que les dessins soient relativement petits. Ainsi, nous ne sommes pas obligés de faire une animation complexe et trop précise des mouvements. En revanche, les problèmes sont différents sur un 16 bits : les possibilités sont plus grandes, l'animation gagnera en souplesse à condition que le travail soit plus fin, donc plus complexe et plus difficile à réaliser.
Le décor de pratiquement tous les
jeux d'aventure sont statiques. Peut-on imaginer un décor où l'on verrait les herbes hautes ondoyer
sous la brise et les reflets du soleil changer selon l'heure du jour ?Nous voulons y arriver, mais les possibilités des machines ne suffisent pas encore...
|
