Discussion :

[JMLLB]

Bonjour,

J'ai un petit soucis dans une appli qui n'est pas un jeu mais dont la problèmatique doit être assez proche de certain jeux 2D.

Je manipule des formes pleines, opaques et plates et je leur applique une texture en utilisant une image.
Jusque là, pas de quoi s'affoler!
Là où ça pinouille c'est que je peux regarder ces formes d'aussi loin/près que je le veux.
Ma première approche naive de ce problème a été d'utiliser une echelle pour mon image échantillon et faire une mise à l'échelle pour créer une nouvelle image que j'applique en tant que texture.
Cette approche est satisfaisante tant que je fais des mise à l'échelle avec des valeurs entières, mais dès que les valeurs ne sont pas entières je me retrouve avec des espèces de quadrillage du plus mauvais effet.
Sachant que je ne peux pas vérouiller les valeurs de zoom (x2,x3, x4...), et que le rendu doit être le plus proche du réel je ne sais pas trop quoi faire.

J'ai un peu compliqué mon approche en utilisant une collection d'échantillon de la même texture mais à des échelles différentes (1m2, 1dm2, 1cm2) pour être plus réaliste, mais ça ne change rien au problème de fond.
Je peux toujours me rabattre sur la valeur entière la plus proche mais c'est pas terrible, à moins d'avoir une grosse batterie d'échantillons différents.

Je suppose que ce problème doit concerner un certain nombre de personnes donc si vous avez des idées je suis preneur.

MERCI!

[Laurent Gomila]

Là où ça pinouille c'est que je peux regarder ces formes d'aussi loin/près que je le veux.
Ma première approche naive de ce problème [...]

J'ai peut-être loupé quelque chose, mais je ne vois pas à quel moment tu expliques ce fameux problème. J'ai bien compris ton post mais je ne sais pas quel problème tu cherches à résoudre.

[JMLLB]

Je vais essayer d'être plus clair.

Pour schématiser au maximum disons que j'ai une image de 2x2 pixels (première miniature) que je vais utiliser comme texture pour une pièce ronde (3ème minitature).
Si je fais un zoomx2 (quatrième miniature) je vais créer une image de 4x4 pixels ou chaque pixel de l'image de départ va être projeté sur 4 pixels de l'image d'arrivée. Pas de soucis!
Par contre si je fais un zoomx1,5 je me retrouve avec une image de 3x3 pixels ou chaque pixel ne sera pas traité équitablement (deuxième miniature) et le résultat final ne correspond pas du tout à ce que l'on veut.

Il va sans dire que j'utilise des images bien plus grosses (100x100 pixels) avec des textures plus réalistes mais la problématique reste la même.

Les idées que j'ai en tête sont de limiter les conversions non entières, donc des images les plus petites possibles par rapport aux surfaces à mapper et avoir différentes images pour trouver le meilleur compromis dynamiquement.

Ceci étant dis mon problème me semble assez commun et je me demande si qq'un connait une solution élégante pour ce problème.
Pour l'instant mon implémentation donne des résultats corrects pour une échelle donnée et il suffit que je change un peu l'échelle pour avoir d'affreux cadrillages.

Pour info, l'appli est codée en Java avec J2D.

[deadalnix]

Si tu as pas peur de la violence de la reponse voici une idéé (qui est pas de moi, elle est mise ne place dans plein de jeux).

1/ creer des niveau de mip/map, c'est a dire des images de taille plus petite. Creer un mip map d'une image de base peut se faire facilement, il te suffit de prendre les points 4 par 4 sur l'image d'origne, de faire la moyenne des 4 points et tu a un point pour ton image plus petite.

2/ Determiner a quelle coordonée dans la texture (en flottant) correspond ton point a l'ecran. puis, a quelle profondeur est ce point.

3/ Grace a la profondeur, il faut que tu determine entres quel mipmaps tu te trouves. par exemple, si tu a decidé qu'a une distance de 1 tu aurais le mipmap d'origine et a deux le mipmap suivant, et enfin que ton point est a 1.7 de profondeur, tu peux associer un coeff sur chacun des deux mipmap : 0.3 pour le grand et 0.7 pour le petit.

4/ tu filtre chacun des deux mipmaps.
Ici, tu determine entre quel 4 point t'ammenent tes corrdonées en flottant sur chacun des mipmap, et tu claucle la couleur de ton point en fonction des 4 pixels les plus proches affecté de coefiscients.

5/ tu mie les deux points obetnus pour chaque mipmap, grace aux coeffs calculés precedement.

Et tu obtient un truc du plus bel effet

Petit plus, si tu est motivé, tu peu creer tes mipmaps toti meme via un logiciel de dessin, le rendu est encore meilleur car tu peux retoucher chacun des niveaux de mipmap.

Cette technique est le filtrage trilineaire.

[JMLLB]

merci pour ta réponse!

J'ai creusé un peu dans cette direction, mais je pense que je vais partir sur qqchose de plus simple étant donné que je travaille en 2D pure et donc que mes transformations de textures se limitent à des mises à l'échelle.
De plus, je n'ai pas de problème de pixélisation mais plutôt de cadrillement de mes nouvelles textures (à cause des jonctions principalement).

Je vais donc prendre mon problème par deux boûts différents:
-Pour les agrandissement de ma texture originale: revoir la méthode d'agrandissement en jouant sur les paramètres de manière à avoir une image propre et conservant la propreté des jonctions.
-Pour les réductions: créer une image de taille superieure en utilisant comme motif mon échantillon initial puis réduire cette image à la taille voulue. De la même manière que pour les agrandissements je vais devoir régler la réduction de manière à ce que les jonctions ne se voient pas trop.

Avec ça je pense régler mes problèmes de cadrillage après mise à l'échelle.

merci pour vos avis et conseils!

[deadalnix]

Si tu redimmentionne ta texture a chaque frame, ton programme risque d'etre lent/de demander beaucoup de resources. C'est aussi l'un interret des mipmaps.

[JMLLB]

Je n'ai pas de problème de perfo étant donné que je ne suis pas d'un environnement "stressant".
Je ne gère qu'une dizaine de textures pour un écran, le facteur de grossissement est le même pour toutes les pieces et c'est l'utilisateur qui effectue les déplacements.
C'est un outil de conception assisté pas un jeu, ce qui est primordial c'est qu'en statique le rendu soit réaliste et si l'utilisateur secoue les objets dans tout les sens et qu'il y des scintillements, retards, clignotements et bien ce n'est pas bien grave (dans mon cas de figure).