[Image] Flou de vitesse

Bonjour,

J'essaie de faire un effet de flou de vitesse, qui va vers l'image, pour mettre dans un jeu. J'ai un algo qui fonctionne mais que je trouve un peu longuet :

On donne en entrée l'image, le centre C du flou et la force de l'effet . J'utilise deux images, une copie de l'originale pour lire les pixels, et l'image originale qui est modifiée. Puis l'algo est :

Code:

---

1 2 3 4 5 6 7

Pour chacune des parties de l'image (en haut à gauche du centre, en haut à droite, en bas à gauche et en bas à droite) faire pour chacun des pixels p1 de cette partie faire soit p2 = p1 + dist(p1, C) * force / 100 calculer la moyenne m des pixels de p1 à p2 résultat(p1) = m fin-faire fin-faire

---

(en fait je cherche pour tout pixel le pixel qui aurait servi de référence si le filtre était déjà appliqué)

Le calcul de la moyenne des pixels est faite avec l'algo de Bresenham. Voici un exemple de résultat

Mon problème est que l'algo est un peu trop lent. Sur une image de 640 * 480 avec une force de 3, je ne suis pas descendu au dessous de 100 millisecondes. Ce qui est un peu beaucoup pour un jeu à 60 images secondes (une image toutes les 160 millisecondes ).

Je cherche donc un algo plus efficace. Par exemple dans Burnout 3 il y a un effet de ce genre, et un bon framerate.

Toutes les idées sont les bienvenues.

Pour les détails du test, c'est du C++, option de compil O3 et exécuté sur un processeur à 1,3 Ghz, 256 Mo de RAM.

Salut !

Je balance ça à tout hasard, je ne sais pas si ça peut marcher, mais pourquoi ne pas sommer 3 images : celle de l'instant d'avant, l'actuelle et celle qui devrait suivre (ce qui fait que tu as toujours une image d'avance) ? Ou plus (genre 5) si tu veux augmenter le flou ?

L'avantage est que de cette manière tu n'as que très peu de calculs à mettre en jeu : pas de calculs de distance, même si tu dois conserver en mémoire les images du jeu...

Et pour conserver le fait qu'il y ait un centre de flou, tu fais une sommation pondérée : genre au centre :

Code:

---

I_result = 0.1*I_avant + 0.8*I_actu + 0.1*I_apres

---

et sur les bords

Code:

---

I_result = 0.4*I_avant + 0.2*I_actu + 0.4*I_apres

---

...

Pour les coeff de l'image actu, je verrais bien un truc genre gaussienne 2D (forts coeff au centre et qui décroissent rapidement sur les bords)...

A+

L'idée me plait bien. Je n'ai pas trop le temps de l'implémenter pour l'instant mais à l'occasion je pourrais l'appeler "l'effet mathieu_t"...

merci

A part ça il y a des méthodes pour faire faire ce genre de boulot à ta carte 3D. Le faire en software tuera de toute façon tes performances.

Avec "blur" + le nom de l'API graphique que tu utilises, je pense que tu trouveras des pistes avec Google. Personnellement je pense que la meilleure méthode est à base de pixel shader. Avec OpenGL tu as aussi à disposition un accumulation buffer, il me semble.

Citation:

---

Envoyé par YéTeeh

L'idée me plait bien. Je n'ai pas trop le temps de l'implémenter pour l'instant mais à l'occasion je pourrais l'appeler "l'effet mathieu_t"...

merci

---

Tu ne peux pas obtenir de bonnes performances en faisant ce traitement en C sur le CPU. Ce n'est pas uniquement un problème de puissance de CPU (avec un peu d'optimisation il doit être possible de faire ça en plein écran à 60fps) mais un problème de couplage GPU/CPU et de bande passante entre les deux.

Tu peux faire quelque chose d'approchant sur ta carte graphique directement. L'approche de Burnout et de la plupart des jeux du genre c'est de rendre non pas dans le backbuffer principal mais dans une texture intermédiaire. Et d'ensuite d'utiliser cette texture et éventuellement une autre comme un "accumulateur". (1-k) * Image n + k * image n-1 -> Image n. Tu n'as pas besoin de pixels shaders pour faire ça, une simple TNT est capable de faire du blending ou de faire du multitexturing pour obtenir ce résultat Et non seulement la carte graphique est toujours plus rapide que le CPU pour ça (à part sur certaines puces graphiques Intel). Mais en plus tu ne perds pas le parallélisme CPU/GPU et la communication entre les deux est réduite au minimum.

Ca devient un peu moins algorithmique...

Merci à tous.