Problème d'affichage perso-objets (moteur isométrique)

**swain.dakota** · 13/07/2009, 15h34

Salut à tous, je suis actuellement entrain de programmer un petit moteur isométrique en opengl, mais je rencontre un ptit problème, je vous montre ça en image, ça sera plus simple ^^ :

Première image, j'ai un personnage qui est placé devant un rocher, l'affichage est correct(le rocher est dessiné après le perso)

Deuxième image, le personnage est placé derrière le rocher, il doit donc être caché par celui-ci...

...eh bha non !
voilà, le problème, c'est que je ne sais pas comment gérer la profondeur correctement !

Pour l'instant, je gère ça avec un système de calques :

- calque 0 -> tuiles
- calque 1 -> objets(les morceaux qui sont derrières le personnage) = screen 1
- calque 2 -> persos
- calque 3 -> objets(les morceaux qui sont devants le personnage) = screen 2

pour ceux qui n'ont pas comprit, en fait mes objets sont coupés en tuiles carrés 32x32, et donc je peux gérer chaque morceau de l'objet, sa position, son calque etc...donc le vrai problème c'est que je me fais chier à passer les morceaux qui sont censés cacher le personnage en calque 3, à passer ceux qui sont censés être devant le personnage en calque 1 etc...et tout ça je dois le tester avec un personnage IG et ça me prend énormément de temps, j'aimerai donc savoir s'il n'y a pas un moyen simple pour gérer tout ça ?

merci d'avance

.

**Mat.M** · 13/07/2009, 16h01

Salut j'ai le même problème que toi pour mon jeu.
Il faut que tu effectues un tri de tes objets graphiques.
Pour mon jeu je mets cela dans une pile temporaire les objets sont triès selon les ordonnées Y.
Il y a peut-être des méthodes plus sophistiquées à l'aide d'arbres binaires.

pour ceux qui n'ont pas comprit, en fait mes objets sont coupés en tuiles carrés 32x32, et donc je peux gérer chaque morceau de l'objet, sa position, son calque etc...donc le vrai problème c'est que je me fais chier à passer les morceaux qui sont censés cacher le personnage en calque 3

non on a parfaitement compris j'ai le même problème que toi.
Sinon tu peux déterminer entre 2 objets qui se confondent quel est celui à afficher en premier.
Mais cela risque de pénaliser les performances d'affichage

Première image, j'ai un personnage qui est placé devant un rocher, l'affichage est correct(le rocher est dessiné après le perso)

Deuxième image, le personnage est placé derrière le rocher, il doit donc être caché par celui-ci...

Pour que le personnage s'affiche avant ou après le rocher il faut trier la cordonnée Y du rocher et du personnage.
Si Y_rocher < Y_perso alors afficher rocher d'abord puis perso ensuite

**swain.dakota** · 13/07/2009, 16h12

Oki, merci Mat. M, je vais essayer de faire ça, je reviens en cas de problème !

**nouknouk** · 13/07/2009, 17h12

J'ai moi-même eu l'occasion de me pencher sur les problématique de moteur 2D isométrique (cf. ceci).

A noter qu'on avait commencé un thread avec Yordarus, mais je n'ai pas encore pris le temps de le compléter au délà de l'introduction.

Une chose à noter:

- personellement, j'utilise des sprites de n'importe quelle taille.
Je me base par ailleurs sur le même système de coordonnées que celui exposé dans le lien ci-dessus (x croissants => vers le "bas-droite" ; y croissants => vers le "bas-gauche") et équivalent à l'image ci-dessus:

Il faut ordonner les sprites à partir d'une valeur (qu'on va appeler 'zOrder') qui est égale à (X+Y), X et Y étant les coordonnées du point d'attache du sprite.

En 2D isométrique, il existe des cas de sprite insolubles (ie. on pourra trouver des configuration avec un problème de rendu).
Ce sont les sprites qui ont des pixels non transparents dans le 'cône' (cf. partie bleue ci-dessous) situé en dessous du point de référence (en rouge dans les exemples ci-dessous, point qui représente les valeurs X et Y). Il faut donc bien veiller à utiliser des sprites 'bien formés':

Exemple1: un sprite 'bien formé' : tous les pixels du sprite sont hors du cône bleu:

Exemple2: un sprite problématique: des pixels sont situés dans le cône bleu:

Les lignes formant la limite du cône sont les lignes parallèles aux axes d'abcisse et d'ordonnée et passant par le point de référence du sprite (point rouge).

Il y a peut-être des méthodes plus sophistiquées à l'aide d'arbres binaires.

Perso, j'ai une liste globale de tous les objets de la map dans laquelle les objets sont triés (et retriés en permanence quand un objet se déplace - et donc que son zOrder évolue - et qu'il doit changer de place relative dans la liste).

A partir de cette liste globale, j'extrais à chaque fois que la 'caméra' bouge une sous liste "de rendu" ne contenant que les objets réellement affichés dans la vue courante.

Et tant que la caméra ne bouge pas (pas de scrolling), je n'utilise que la sous-liste de rendu pour recalculer les objets à afficher ou mettre à jour (cas d'objets qui bougent, ou avec des images animées). J'y ai seulement à ajouter de temps en temps les objets qui 'rentrent' dans la vue et je retire ceux qui en 'sortent'.

Le gros problème de cette solution est qu'elle est dépendante du nombre total d'objets de la carte (plus il y en a, plus c'est lent à regénérer la sous-liste de rendu). La solution envisagée (mais pas encore finie d'être implémentée chez moi) est de partitionner la carte en un damier de plus petites partitions de la map (chacune de la taille d'une 'demi vue' chez moi). Je n'itère alors que sur les partitions proche de ma 'vue' quand je dois extraire à nouveau la sous-liste de rendu. C'est un peu l'équivalent (très) basique d'utilisation d'un Quadtree ultra simplifié.

**Mat.M** · 13/07/2009, 20h13

Salut Nouknouk merci pour les explications que tu te donnes la peine de fournir

mais je n'arrive pas à comprendre ce que tu veux dire par "sprite formé"
Et puis tu ne nous dit pas me semble-t-il comment afficher par devant ou par derrière un personnage par rapport à un rocher par exemple ( ou bien je suis neuneu et je n'ai pas compris

)
Pourquoi ne pas employer un simple arbre binaire au lieu d'un quadtree ?

**nouknouk** · 13/07/2009, 22h19

Envoyé par Mat.M

mais je n'arrive pas à comprendre ce que tu veux dire par "sprite formé"

C'est comme dans l'exemple 1, avec la maison: un sprite est une image rectangulaire ; or pour ne pas avoir de soucis de chevauchement 'merdique' (ie. une partie d'une image qui est affichée devant une autre alors que ça devrait être l'inverse), il faut s'imposer des règles de dessin:

- faire que l'algo d'affichage prendra comme coordonnée de référence le point marqué en rouge dans mon exemple, c'est typiquement le point tout en bas au milieu de l'image. C'est ce point là qui servira de référence pour les coordonnées (x,y) de l'objet représenté par le sprite.

- à partir de ce point, la règle pour éviter au maximum les problèmes d'affichage 'merdiques' est de ne jamais avoir du contenu (ie. des pixels non totalement transparents) dans la zone indiquée en bleu (qui bien sûr ne sera pas là dans le sprite, c'est juste pour la visualiser dans l'exemple). Cette zonne correspond à ce qui se trouve en dessous des lignes qui partent du point 'référence' (le point rouge) et qui continuent le long des axes des abscisses et des ordonnées.

L'idée est que quand on va choisir/dessiner les sprites pour notre jeu, on va se débrouiller pour systématiquement respecter cette règle du cône bleu.

Et puis tu ne nous dit pas me semble-t-il comment afficher par devant ou par derrière un personnage par rapport à un rocher par exemple ( ou bien je suis neuneu et je n'ai pas compris

)

T'inquiètes, je comprends bien que mon message est super flou (écrit un peu trop à l'arrache)

L'idée est que comme pour chaque sprite on a calculé sa valeur 'zOrder', il suffit d'afficher les sprites dans l'ordre de leur zOrder croissant.
Par exemple, si j'ai 3 sprites dans ma scène qui ont respectivement des zOrders de (10.27, 47.23 et 5.19), et ben il faudra les dessiner dans l'ordre: celui à 5.19, puis celui à 10.27 puis celui à 47.23

Dans l'exemple du rocher: le rocher va avoir un zOrder fixe puisqu'il ne bouge pas.
Par contre, ton personnage va lui se déplacer. Comme sa position (x,y) variera, son zOrder va varier également.

- lorsque le perso sera à certains endroits son zOrder sera inférieur à celui du rocher, c'est quand il sera situé derrière. Notre algo le dessinera alors en premier et le rocher par dessus

- à d'autres endroits, son zOrder sera supérieur à celui du rocher, c'est quand le perso sera situé devant lui. Notre algo le dessinera alors par dessus le rocher.

Euh, suis toujours pas sûr d'avoir été super clair. N'hésitez pas à me redemander si c'est toujours aussi flou

Pourquoi ne pas employer un simple arbre binaire au lieu d'un quadtree ?

Hmmm... bonne question. Je t'avoue que je n'ai jamais utilisé d'arbre binaire, donc je suis assez mal placé pour dire si ça conviendrait ou pas. Docn ce qui suit est à prendre avec des pincettes.

J'imagine que le principal souci est qu'avec la méthode des zOrders, deux objets ayant le même zOrder peuvent être très éloignés l'un de l'autre sur la carte. Par exemple les deux extrémités gauche et droite du damier présenté dans mon post précédent ont le même zOrder (zOrder = 3 <=> 0+3 = 3+0). Même principe pour les extrémités gauche et droite d'une immanse carte.

Or pour les perfs de rendu, un des besoins primordiaux est d'être capable d'isoler très rapidement les objets candidats à l'affichage parmi les milliers d'autres objets de la carte. D'où un partitionnement plus 'spatial' et mon idée initiale d'utiliser les structures qui s'y rapportent (oc-tree, quad-tree, ...).