[RESOLU] Question sur les Vertex et les Textures

[bizzigul]

Hello Laurent,
je me demandais pourquoi par exemple dans le tuto sur les Vertex, les coordonnees a l'extremite du quad sont mis a la taille de la tile, plutot que la taille de la tile moins 1 (par exemple si la tile fait 32 pixels et est a (0, 0), on set le vertex en bas a droite a (32, 32) plutot que (31, 31) )
La carte graphique ou SFML fait le (-1, -1) lui-meme? Ca deborde sur la tile a cote sinon (voire en dehors de la texture)...

Aussi, question generale sur les Vertex SFML: si je comprends bien, la texture est mappee avec un algorithme bien particulier. Dans le cas d'un tileset, n'est-il pas moins couteux de mapper directement pixel par pixel (correspondance 1:1), sans passer par l'algo? Par exemple si j'ai un bout de texture 32x32 et un Vertex 32x32.
L'idee que le mapping ne soit pas "direct" me gene un peu dans ce cas... Il n'y a pas un risque de deformation? Si la texture a une taille/forme differente, je veux bien, mais dans le cas d'un tileset...

Merci de m'eclairer!

[Laurent]

Prends une tile de 1x1 : tu ferais quoi pour tes vertex, (0, 0) pour le début et (0, 0) pour la fin ?

Les coordonnées de fin ne sont pas incluses dans le mapping, tout simplement.

si je comprends bien, la texture est mappee avec un algorithme bien particulier

Hum ? Tu fais référence à quoi ? Quel algo ?

[bizzigul]

Ouep, j'aurais mis (0, 0) pour la fin^^ Je me disais que les vertex de fin ne sont pas differents des autres et qu'ils doivent se mettre sur des pixels faisant partie de la zone a mapper :p

Merci pour la clarification.

Pour l'algo du mapping, je pensais a l'algo qui va par exemple piocher un pixel de texture deux fois de suite si la texture est trop petite par rapport au quad (wikipedia me dit "interpolation lineaire" ou "algo de Bresenham").

Par exemple, dans la SFML 1.6, quand on prend un sf::Image, le mapping se fait directement (m'enfin je suppose qu'en interne ca fait quand meme des quads... du coup il est impossible de mapper directement des pixels sans faire une interpolation potentiellement plus couteuse?)

[Laurent]

L'interpolation linéaire ne se fait que si tu appelles texture.setSmooth(true). Par défaut elle est désactivée.

une interpolation potentiellement plus couteuse?

Ca ne coûte rien du tout, les cartes graphiques sont câblées pour gérer ça nativement.

[bizzigul]

Sans l'interpolation, on peut quand meme etirer des textures? Je ne comprends pas trop la difference

Aussi, j'etais tombe sur une histoire de trapeze et de profondeur qui passait pas bien, comme dans cette image (https://en.wikipedia.org/wiki/File:Perspective_correct_texture_mapping.jpg)
Je comprends bien le probleme, mais je me demandais si il etait tout de meme possible de mapper un trapeze mais sans profondeur? Pas comme la texture a droite, mais plutot comme si je decoupais aux ciseaux l'image de gauche (la texture), en faisant un trapeze.

[G.]

Y'a toujours une interpolation.
Avec setSmooth c'est une interpolation linéaire, et sans c'est une interpolation par plus proche voisin (nearest neighbor) qui donne un effet pixelisé non lissé. Si tu veux voir la différence, affiche 2 fois la même image agrandie, une fois avec setSmooth et une fois sans. :p

[bizzigul]

Je vois!
Donc si j'ai bien compris, pour ne pas avoir de mapping "bizarre" comme avec le trapeze, il faut soit mapper une texture qui fait la meme taille, soit etirer la texture mais en gardant les memes proportions (la meme forme).

En gros le probleme de profondeur ne se produit que si l'on etire une texture en changeant sa forme.

Dites-le moi si je me trompe Je cherche a determiner les cas generaux pour bien comprendre le concept de vertex.

[G.]

Je répondais juste pour l'interpolation du setSmooth.
Pour le trapèze tu peux lire ce sujet : http://fr.sfml-dev.org/forums/index.php?topic=11501.0

[bizzigul]

Oui j'ai deja lu le sujet
Ce que je veux savoir c'est la condition precise qui fait qu'un mapping ne se fait "pas bien".

D'ailleurs je viens d'y penser, je me demande pourquoi il n'y a pas moyen de set automatiquement les texCoord en fonction de la position des vertex. Par exemple, si je veux mapper une etoile, je set les vertex en forme d'etoile, mais je suis oblige de set les texCoor aux memes positions relatives, alors qu'en fait c'est la meme chose (il y a une redondance d'informations).

[Laurent]

Il est impossible de mapper un trapèze correctement sans information de profondeur. Prends chaque triangle le composant séparément, et applique intuitivement un mapping : ce ne sera sûrement pas celui qu'il faudrait pour que les deux réunis soient en harmonie. Ce qui te paraît correct ou intuitif pour le trapèze au complet ne l'est pas forcément pour chaque triangle pris séparément. Or la carte graphique traite les triangles séparément.

En ce qui concerne les coordonnées de textures, dans ton cas tu veux qu'elles soient corrélées à la position, mais ce ne sera pas toujours le cas. En plus même si tu suis la position, tu peux tout de même vouloir appliquer un décalage, une rotation ou un facteur d'échelle ; moi je ne peux rien faire au niveau de sf::Vertex, il faut bien que je laisse chacun faire ce qu'il veut. Par contre c'est ce que je fais dans sf::Sprite et sf::Shape, les coordonnées de texture sont calculées en fonction de la position de chaque vertex.

[bizzigul]

Je suis d'accord pour le trapeze, mais si les texCoor ont aussi une forme de trapeze, cela marchera comme toutes les formes, n'est ce pas? Est-ce que tu peux me confirmer qu'un mapping non-intuitif se produit si et seulement si la forme des vertex et des texCoor est differente (d'ou la raison pour laquelle les trucs custom dont tu m'as parle ne vont pas plus loin que "facteur d'echelle")?

[Laurent]

Est-ce que tu peux me confirmer qu'un mapping non-intuitif se produit si et seulement si la forme des vertex et des texCoor est differente

Probablement oui.

(d'ou la raison pour laquelle les trucs custom dont tu m'as parle ne vont pas plus loin que "facteur d'echelle"

Un décalage et une rotation ne changent pas plus la forme qu'un facteur d'échelle.

[bizzigul]

Un décalage et une rotation ne changent pas plus la forme qu'un facteur d'échelle.

Oui enfin je me comprends^^

En tout cas merci. Et chapeau pour cette nouvelle api, c'est grandiose.

[Laurent]

Oui enfin je me comprends^^

Pas moi