Version imprimable
Peut être hors sujet :
1. pourquoi ne pas passer par OpenCL, tu n'aurais plus de problème d'arrondis lors du passage des données entre les shaders (et garder OpenGL que pour l'affichage, pas la simulation des fluides)
2. passer en fp64 ? L'erreur avec les doubles ne sera peut être plus problématique
1) L'algorithme de simulation que je veux implémenter utilise le rasterizer et le pipeline graphique via opengl
2) J'ai essayé mais en fait mes calculs sont déjà précis, ce sont ceux du rasterizer qui ne le sont pas (optimisations j'imagine), ça ne me gênerais pas si je savais comment faire exactement le même calcul avec la même précision, hors ce n'est pas le cas pour le moment :(
Pour moi c'est normal qu'il puisse se tromper d'un pouillème. Et comme ATI et NVidia utilisent des algo différents, NVidia se trompe d'un pouillème à gauche et ATI d'un pouillème à droite en caricaturant. Il y a d'autres cas de figure ou ça marche sur NVidia et pas sur ATI.
De plus, avant les float étaient codé sur 12 bits sur GPU. Il était alors impossible d'avoir la même précision en entrée et en sortie.
Si tu cherche "OpenGL center pixel", ou "OpenGL pixel aligment" sur google, tu tombe sur pas mal de gens qui ont ce problème. C'était d'ailleurs spécifié dans un article sur le wiki d'OpenGL mais pas moyen de le retrouver :(.
Au final, la règle de base est: Si tu veux taper exactement sur un pixel, tape au milieu.
Je veux bien taper au milieu mais pour cela il faut que je sache sur quel pixel taper :mouarf: Parce que moi quand je calcul sur lequel je dois taper je trouve justement une solution qui n'est pas toujours correcte (ou plutôt qui l'est quand le rasterizer ne l'est pas) ! Donc même si je vais taper à 0.5 ; 0.5 si c'est sûr le pixel d'à côté ça ne m'arrange pas :/
Même en réalignant juste après vec4 pos = vec4(gl_ProjectionMatrix * vec4(VertexPosition, 1.0)); tu as encore le problème ?!
Bah... essaye de réaligner le plus tôt possible, coté CPU donc...
Si ça ne marche toujours pas, je ne vois vraiment plus quoi faire...Code:
2
3
De mémoire, il y a une commande pour choisir le type d'interpolation utilisée pour le passage des données entre les shaders... il faudrait que je retrouveCitation:
Envoyé par oxyde356
Non si, si je réaligne à la main dans le vertex shader c'est bon sauf que je fait du calcul en plus pour casser une optimisation ( :s ) que je n'arrive pas à reproduire et je dois dévier de l'utilisation naturelle du rasterizer (ce qui ne me plait pas du tout :( )
Non côté CPU je peux pas vu que ma grille doit bouger selon des paramètres totalement indépendant de moi et les points doivent pouvoir avoir n'importe quels valeurs.
Mais mon problème depuis le début et bien que je n'arrive pas à reproduire le comportement exacte du rasterizer, niveau workaround oui il y a mais je trouve ça fou de devoir passer par là pour un truc aussi basique.
Etant donné que j'utilise un matrice de projection ortho et que je ne dessine qu'un pixel par point ça ne change rien car il n'y a rien à interpoler et de toute façon ce n'est pas le passage de valeur entre shaders qui pose problème. Merci quand même.
Pour moi ce n'est pas un workaround. Si tu veux taper sur une grille discrétisée, il faut que tu t'aligne dessus. Et faire un floor d'un float quelconque, c'est la porte ouverte ce genre de problème, raterizer ou pas.
Si coté CPU tes points doivent avoir n'importe quelle valeur, à un moment ou l'autre il seront aligner sur une grille. Donc je ne vois pas le problème qu'il y a à les aligner dès le début :)
Dans mon exemple j'utilise une grille parce que c'est un exemple simple. Chaque point représente une particule indépendante qui peut aller n'importe où au final, se déplacer lentement ou rapidement, etc. Le rasterizer fait bien un floor lui, il induit une erreur ok ça c'est pas un problème à la limite mais ce que je veux c'est avoir la même erreur, le même comportement :/
Tu peux peut être essayer de mettre une gl_ProjectionMatrix à l'identité et faire les changements de repère à la main coté CPU... Ca limiterait les imprécisions coté GPU.
Mais ce que je ne comprend toujours pas, c'est que OK tes particule peuvent aller n'importe où. J'imagine que à un instant t, tes particules sont quelque-part. Tu "allume" des pixels pour montrer leur position, et tu met ça dans une texture. A un instant t+1, tu te sert de la position de l'instant t pour déplacer tes particules et "allumer" d'autre pixels, que tu remet dans la texture, etc...
Mais dans ce cas, à partir du moment où tu stock tes particules dans une texture, elles sont forcement aligné sur la grille de pixel de la texture.
Oui elles s'alignent sur la grille de pixel (mais leur position qui est stocké dans un VBO n'en est pas affecté), mais sans le workaround, le pixel où une particule se dessine n'est pas forcément le pixel sur lequel je pense qu'il va se dessiner (et là mon algo craque) car le rasterizer fait une erreur à un pixel près dans certains cas. Je ne suis pas sûr de comprendre à quoi tu veux en venir.
En fait, je ne comprend pas comment tu utilise le GPU dans ton algo (dsl de te faire perdre du temps avec ça :)).
Dans toutes les simulations de fluide sur GPU que j'ai vue, l'espace est discrétisé en une grille (pixels ou voxels), et les particules vont de pixel en pixel. Chaque pixel pouvant interagir avec un voisinage plus ou moins proche. Comme l'espace est discrétisé, on s'arrange pour aligner dès le départ les point sur la grille.
Ou alors, les particules n'interagissent pas entre elles (on ne s'occupe pas de leur voisinage), et dans ce cas on stock la position (vitesse, énergie ou autre paramètre susceptible d'évoluer) dans les composantes rgb du pixel, et on met les particules en vrac dans une texture RGBA32F. (si on a 100 particules, on fait une texture de 10x10). Mais dans ce cas, la position du pixel n'a aucun rapport avec la position de la particule.
Ah ok je vois de quoi tu parle. Non mon algorithme n'utilise pas l'approche Eulerian grid-based mais Smoothed Particle Hydrodynamics (SPH) et elles n'ont pas beaucoup de points commun :P Il n'y a pas vraiment de grille à proprement dit si j'ai besoin d'une texture c'est pour distribuer des attributs (densité, pression, etc.) entre les particules d'une façon gpu-friendly. T'inquiète tu ne me fais pas perdre mon temps et puis je te dois bien ça tu m'as bien aidé ^^