[Antialiasing][Wu][poids]

Bonjour à tous,
J'ai réalisé mon propre moteur 3D, mais j'ai quelques problémes d'aliasing, en fait j'ai un effet d'escalier.
Je me suis renseigner sur les solutions existantes, et l'algorithme de Wu, me semble me convenir. Le problème est que cet algo utilise un système de poids pour l'influence d'un pixel sur les autres. Et c'est là que le bas blaisse, comment je détermine c'est fameux poids ?
Il y a des tas d'algo pour les lignes, et on dit qu'on peut aussi l'appliquer pour les texture, sans plus d'explication, et là j'en ai besoin.

Si vous avez un lien, une idée, merci d'avance.

JHelp

A vrai dire je n'ai jamais vu cet algo, mais on parle souvent d'antialiasing 0.3, 0.4 (dans POVRay par exemple), c'est peut être la valeur de ce coef ?

Ce que je ferais pour tester sur une texture :
[valeur d'un pixel] = ([valeur d'origine] + [somme des valeurs des pixels voisins] * k ) / (1+8*k)
k = 0.3 par exemple

C'est probablement naïf, mais tu as demandé des idées alors ... ;o)

vic

Ca me semble pas aussi naïf que cela, merci je vais essayer. Si ça ne marche pas, je verrais en changeant k.
J'appliquais une autre formule, mais celle-là semble plus proche de l'algo de Wu pour les lignes.
En tous cas merci pour ta réponse.
JHelp

salut,

Je ne connait pas l'algo de wu mais ça me semble ressembler à ça...
en fait le système de poids s'applique à partir d'une matrice. Si tu veux par exemple utiliser une matrice 3*3:

Code:

---

1 2 3 4 5 6

------- |1|3|1| |3|8|3| |1|3|1| -------

---

Tu additionne les valeurs de couleurs des pixels en mutipliant par la matrice, tu divise le tout par la somme des coef de la matrice et tu
affectes ça au pixel central. T'auras alors une moyenne des pixels environnant tout en conservant la dominante centrale.

En fait ce genre de formule donne un effet de brouilage, qui cache l'effet d'escalier. Celle que j'utilise en ce moment est un mélange de vos deux sugestions. Pour info :
La matrice est :

Code:

---

1 2 3 4 5 6

0 | 1 | 0 ---------- 1 | 4 | 1 ---------- 0 | 1 | 0

---

et le k = 0.75/4.
Cela donne un résultat convenable.
JHelp

ce que tu fais n'est donc pas un moteur 3D mais un rasteriseur software (ou je me trompe ?)

Ce que tu pratiques en faisant le 1 2 1
c'est effectivement un flou gaussien ce qui elimine
l'effet d'escalier en reduisant la qualite de l'image.

L'aliasing est relie au probleme plus general des interferences.
(ton effet de flou ne reglera pas le flickering lie aux textures et de plus entrainera la disparition de details). Le flou meme si c'est un element realiste qui peut apparaitre sur nombre de support (photo, camera, vision humaine) doit pouvoir etre controle.

Les hardware 3d actuels traitent le probleme de flickering des textures en utilisant ce qu'on appelle des niveaux de mipmaps ou des textures prefiltrees pour etre affichees a differentes resolutions.
Une texture affichee sur l'ecran avec un rapport oscillant entre 2:1 et 1:1 ne provoquera donc pas de flickering. On pourrait theoriquement faire le filtrage en temps reel mais cela implique de lire une quantite trop importante de samples de texture par pixel affiche.. bref irrealisable en pratique (meme si l'anisotropic filtering s'en approche).

Reste l'aliasing sur les bords des polygones et le flcikering lie au probleme d'echantillonage des polygones. La le mipmapping ne peut rien faire puisqu'il agit au milieu du polygone sur sa surface. L'une des solutions preconisee et supportee par certains hardware c'est d'appliquer une fonction de flou uniquement sur les bords des polygones. Ainsi on trace le monde normalement avec du mipmapping au milieu des polygones et l'on floute le bord.
Cela presente l'inconvenient de devoir determiner les bords des polygones affiches a l'ecran (et leurs intersections) et ne regle pas le flickering.

La solution supportee par la plupart des hardware actuels est de rendre dans un viewport beaucoup plus grand que necessaire (4 fois). Chaque pixel supplementaire etant une vue legerement decalee d'un pixel normal.
Ensuite la contribution de chaque pixel est calculee pour avoir un pixel final qui correspond a un sous-echantillonnage avec filtre passe-bas d'une image dans une resolution superieure.
On peut utiliser une formule telle que celle que tu utilises comme filtre passe bas. C'est rapide en temps reel meme si ce n'est pas un "bon filtre" en terme de traitement d'image (risque de creation d'artefacts ou de moire dans des cas pathologiques).
Evidemment on ne fait que repousser le probleme de flickering a un niveau superieur, et on ne peut pas tout baser notre strategie sur cette unique technique (en plus avec ca et le mipmapping et l'anisotropic filtering on a tendance a antialiaser inefficacement).

LeGreg

Il s'agit d'un moteur 3D, car j'ai une scéne 3D, que j'affiche.
Oui en effet, la détection des bords n'est pas simple, et l'algo serait plus éficace, mais plus lent.
J'essaie en ce moment de changer de techni<que, en fait, l'idée serait, si le pixel réel doit se placer en (6.3,8.6), au pixel (6,8) àavec une intensité de (0.7+0.4)/2 le pixel(7,8) avec (0.3+0.4)/2, le pixel (6,9) avec (0.7+0.6)/2 et (7,9) avec (0.3+0.6)/2. (Lintensite variant de 0 à 1)
Ce qui donne de trés bon résultat pour les lignes, les courbes, et les textures. Le seul inconvienent est que pour le moment, ça ralentit trop mon moteur, et mon animation n'est plus fluide mais légérement sacadée.
Mais, en optimisant mon code, j'ai bon espoir.

Merci pour cette explication fort intéressante.

JHelp

Citation:

---

Envoyé par JHelp

Il s'agit d'un moteur 3D, car j'ai une scéne 3D, que j'affiche.

---

oui mais ce que j'essayais de savoir c'est si tu ecrivais
ton propre rasteriseur (traduction francaise approximative)..

Vu la teneur de tes questions c'est ce qu'il me semble
puisque personnellement si je voulais ecrire un moteur 3D from scratch
je m'appuierais sur le hardware.

LeGreg

Celà m'est malheureusement impossible, car il s'agit d'une appli-web, qui doit tourner sans aucun plug, ce qui exclu la possibilitée de se rataché au hardware via directX, OpenGL ou autre.
JHelp