Discussion :

[deadalnix]

Est-il realiste/raisonable d'integrer du motion blur a un moteur 3d temp reel. Si oui, comment faire, j'ai pas pu trouver de solutions la dessus :S

[Kujara]

Solution simple et facile : un post effect via un shader.
Copier l'image d'avant dans un buffer quelque part.
Mixer l'image actuelle avec l'image d'avant.

[LapinGarou]

Ca dépend comment tu comptes procéder : shader comme proposé par Kujara, ou en le faisant toi-même ? (Ou même du genre sous OpenGL : glAccum...)

[deadalnix]

Le probleme de la proposition de Kujara, c'est qyue l'effet depend fortement du framerate. N'y a-t-il aps de solution, via calcul des vitesse des vertex par exemple (ceci est simple dans mon cas, le moteur physique est couplé au moteur 3d) ?

[smashy]

Une solution existante est de deforme les mesh en mouvement.

L idee est la suivante :

Si la normale pour un vertex est front facing, on garde la position du vertex standard

Si elle est back facing, on utilise plutot la position du vertex au frame precedent.

Avec cette methode (mathematiquement fausse), le mesh semble etre deforme par sa vitesse

[deadalnix]

Ca n'est pas tout a fait du motion blur (qui serait un effet type pixel, effet de flou), mais c'est tres interessant.

Qui plus, est, couplé a un moteur physique, on est pas dépendant du frame rate (suffit de deplacer le vertex collineairement a sa vitesse, et non de le prendre a la frame precedente).

Par contre, le coup de la normale, back face ou front face, c'est par rapport au vecteur vitesse ? etudier le signe du produit scalaire normale/vitesse peut donc etre gerable.

PS: a bien y reflechir, on peut meme faire quelque chose de plus correct en etudiant le vecteur vertex/centre de l'objet.

C'est pas mal tout ca, mais aps de flou independant du frame rate, dommage . . .

Bon, de toute facon, ca n'est pas vraiment le point super important d'un moteur, meme si le mieun est beaucoup b'asé sur ce genre de choses (effet d'ombre/lumiere, adaptation a la luminosité non immediate, tout ce qu'il faut pour flipper au tournant d'un couloir sombre avec sa lampe torche), un motion blur de facon a ne pas bien voir ce qui vous saute a la tronche sans prevenir aurait ete du plus bel effet ^^.

[smashy]

un motion blur de facon a ne pas bien voir ce qui vous saute a la tronche sans prevenir aurait ete du plus bel effet ^^.

Dans ce cas, on utilise principalement un effet de post rendu (qui ne coute pas tant que ca au final ...)

[smashy]

Par contre, le coup de la normale, back face ou front face, c'est par rapport au vecteur vitesse ?

C'est la normale du vertex que l on utilise ... donc a gros c'est ua niveau de chaques triangles

[bob25]

[edit] je simplifie

il faut pas nettoyer au retracage des pixels il faut redessiner par dessus avec un leger effet de transparence

ça peut se décomposer sur plusieurs plans (ex ciel-decor-objets mouvants)

[deadalnix]

Tu em donne une idée bob, pourquoi ne pas gere le taux de transparence en fonction du framerate, pour avoir un effet "framerate-safe", et eviter l'effet bug graphique du faible framerate ?

smashy > je sais bien ce qu'est une normale, mais il faut bien la comparer a quelque chose, sinon ca veux rien dire . . .

[smashy]

tu rends ton décor transparent à 80%-90% et tu ne fais pas de clear entre deux images (chaque image est retracée par dessus le reste)

c'est pas mal comme idee, mais ca te prive du buffer ALPHA pour d autres effets....

mais si tu fais rendus sur textures avec quelquechoses comme


buffer(frame x) = (1 - t) .image_courante + t . buffer(frame x - 1)

ou t est un facteur de fondu entre les images

image_courante est l image que tu obtient en rendant la scene sur texture


Ca doit faire des effets sympas (en +, tu peux commuler plusieurs frames dans le meme rendu ... i.e plusieurs frame (pas seulement t et t-1) affectent le rendu final de l image

[bob25]

deadlanix> tres bonne idée je vais men resservir, merci

smashy> ouais interessant ta technique me fait penser au ombres temps reel directement rendus dans le zbuffer, mais c'est plus gourmand en calcul c'est pour les grosse machines

[smashy]

smashy> ouais interessant ta technique me fait penser au ombres temps reel directement rendus dans le zbuffer, mais c'est plus gourmand en calcul c'est pour les grosse machines

Je connais pas technique "directement dans le zbuffer", mais la technique que je propose avec rendu dans une texture n'est pas extremement gourmande (et son cout en temps a l'avantage d etre constant quelque soit la com:plexite de la scene).

De surcroit, quitte faire une passe de POST-PROCESSING, on peut en profiter pour faire d'autres chose que le motion-blur

[bafman]

Solution simple et facile : un post effect via un shader.
Copier l'image d'avant dans un buffer quelque part.
Mixer l'image actuelle avec l'image d'avant.

Le problème, c'est que cette technique ne simule pas du motion blur, mais de la remanence.

Pour faire un beau motion blur des familles, il faut faire un rendu de la scène dans une texture, avec, à la place des couleurs, les vecteur vitesse de chaque pixel. ensuite, on rend la scène normale dans une autre texture, puis, dans une dernière passe, on floute la scène en fonction de la vitesse de chaque pixel.

[deadalnix]

Le problème, c'est que cette technique ne simule pas du motion blur, mais de la remanence.

Pour faire un beau motion blur des familles, il faut faire un rendu de la scène dans une texture, avec, à la place des couleurs, les vecteur vitesse de chaque pixel. ensuite, on rend la scène normale dans une autre texture, puis, dans une dernière passe, on floute la scène en fonction de la vitesse de chaque pixel.

Et c'est gourmand ?

[bafman]

pas tellement plus que de l'addition de buffer... les deux solution pompe beaucoup de fill rate, mais celle à base de shader impose un rendu en plus et demande un shader, mais le resultat est nettement meilleur

[Kujara]

Et c'est gourmand ?

Sachant qu'il faut calculer la vitesse de chaque pixel, oui, excessivement.

Bafman : "Solution simple et facile", comme je disais.Y'a plein d'autres techniques plus complexes, et generalement d'ailleurs trop complexes par rapport au resultat recherché.

[deadalnix]

Sachant qu'il faut calculer la vitesse de chaque pixel, oui, excessivement.

Bafman : "Solution simple et facile", comme je disais.Y'a plein d'autres techniques plus complexes, et generalement d'ailleurs trop complexes par rapport au resultat recherché.

Non, ca me parrait pas le plus gros probleme : on peut calculer la vitesse de chaque sommet, et interpoler pour avoir la vitsesse de chaque pixel, c'est quelque chose qu'un carte 3d sait tres bien faire, et c'est une information que j'ai a disposition car le moteur physique est couplé au moteur 3d.

EDIT : L'avantage, c'est qu'on peut mixer avec d'autres effets facilement comme la netteté des elements trop pres/loin, ce qui donne bien avec des lentilles pour les zooms.