Seul gros défaut de notre animation : les facettes sont
toutes visibles ! Nous n'avons jusqu'à présent pas
pris en compte le fait que des faces était cachées
par d'autres et avons repoussé à plus tard ce problème
en utilisant une opacité réduite. Mais outre que cette
solution rend illisible les volumes complexes elle a aussi pour
inconvénient majeur de ralentir gravement les animations.
Nous devons déterminer celles des facettes qui sont le plus
avant et modifier l'affichage en conséquence.
On aborde ici avec la gestion des faces cachées un problème
bien réel et qui n'a pas encore - qu'on se le dise - trouvé
de solution imparable... Encore une fois plusieurs procédés
sont envisageables. Certains fort complexes sont utilisés
par les logiciels de 3D avec de bons résultat. Les procédés
plus simple montrent eux, très vite, leur limite. Voyons
ce que nous pouvons faire simplement. Nous pourrions par exemple
- mais nous ne ferons que le suggérer - tenter de déterminer
celles de facettes qui nous tournent le dos en analysant leurs quads.
Nous pouvons aussi - c'est notre choix - mesurer une distance moyenne
de chaque facette à l'observateur ou plutôt (car nous
avons arbitrairement confondu le point de vue de l'observateur avec
l'extrémité de l'axe Z) une position moyenne de chaque
sprite facette sur l'axe Z.
Cette position moyenne nous est donnée par la troisième
coordonnée de chacun des 4 coins d'une facette (PC1, pC2,
pC3, pC4) , soit pour chaque sprite :
C'est en utilisant cette valeur que nous pourrons redéfinir
pour chaque facette la propriété the LocZ of sprite.
Évidemment cette moyenne risque fort d'être une valeur
décimale ou encore d'être une valeur négative.
On ne pourra donc l'utiliser immédiatement pour la convertir
en LocZ. Nous allons plutôt l'utiliser pour en déduire
un classement des sprites en profondeur.
On utilise un gestionnaire appelé à chaque transformation.
Ce gestionnaire ("faitLeTri") récupère pour
chaque sprite la moyenne des positions des coins sur l'axe Z (via
une liste gLaListeDesSprites renseignée à chaque transformation).
En plaçant ces moyennes dans une liste triée d'avance
(lesMoyennes) on peut connaître leur position dans cette liste
et affecter à chaque sprite sur la scène un locZ fonction
de ce classement.
On ajoute au script d'animation le code suivant :
on faitLeTri
lesMoyennes = []
sort(lesMoyennes)
repeat with n in gLaListeDesSprites
add lesMoyennes, the maMoyenne of n
end repeat
repeat with n in gLaListeDesSprites
the locZ of sprite n.spriteNum = getPos(lesMoyennes,
n.maMoyenne)
-- l'ordre de superposition
sur la scène reprend le classement des moyennes dans la liste
end repeat
gLaListeDesSprites = []
end
Bien sûr, on renseigne la liste globale gLaListeDesSprites
à chaque nouvelle transformation. On obtient cela par cet
ajout que l'on fait à la fin du gestionnaire "transformation"
(script "facette" voir plus haut)
maMoyenne = - ( (pC1[3] + pc2[3] + pC3[3]
+ pC4[3]) /4 )
global gLaListeDesSprites
add gLaListeDesSprites, me
end
Enfin on appelle le gestionnaire faitLeTri après chaque
modification. Exemple ici avec le script associé au bouton
de rotation selon Y:
global angleY
on mouseDown
repeat while the mousedown
angleY = 0.01
nouveauSysteme = rotationSelonAxeYDe (angleY)
sendAllSprites(#transformation, nouveauSysteme)
faitLeTri
go the frame
end repeat
end
Notre procédé est-il acceptable ? Peut-être
pour un univers simplifié mais regardons plutôt le
schéma suivant. Il s'agit tout simplement d'un timbre collé
sur une enveloppe.
Il est évident que la lettre est plus proche que le timbre
et pourtant... c'est lui qui est dessus ! Dans un tel cas notre
gestion des profondeur montrera ses limites...
