PLAN D'EAU [OPENGL] [VISUAL C++]

Commentaire de zeratul67 le 25/08/2005 21:29:22

Je t'avoue que je ne connais quasiement pas OpenGL, j'ai juste fais un peu de DirectX. Vu le screenshot, je ne peux que dire une chose : la solution qui me semble être la plus rapide et la plus efficace est basée sur les vertex shaders. (car ils évitent les transferts de vertex vers la carte graphique à chaque rendu

Mais c'est déjà pas mal ce que t'as fait ! :)

Commentaire de ewik le 26/08/2005 10:24:20

zeratul67 >> Faux ! Les vertex shaders permettent simplement de spécifier quelles opérations effectuer sur chaque vertex plutôt que d'utiliser les fonctionnalités fixes. Ce qui permet de faire plein de choses sympas. Et les fragment shaders, pareil, mais au niveau des fragments. Pour ce qui est d'éviter les transferts de données, il faut utiliser les VBOs (Vertex Buffer Object, c'est du GL, sous DX je ne connais pas le nom, mais en gros c'est pareil).

mat74 >> Si tu veux des infos sur les shaders, va sur opengl.org, et télécharge les specs de GLSL (OpenGL Shading Language). Sinon si tu cherches des tutoriaux, jettes un oeil sur gpgpu.com, developer.nvidia.com, developer.3dlabs.com, 3dshaders.com et bien sur google. Il y a des tonnes d'exemples de code sur le net. Mais si tu veux vraiment comprendre comment ca marche regarde le pipeline de la carte graphique, ca donne une bonne idée de ce qui est fait et ou se trouvent ces fameux shaders (et c'est même indispensable de le connaître pour faire de la 3D). Il y a des .ppt sur developer.3dlabs.com qui expliquent ca, je crois.
Bon courage.

Commentaire de ewik le 26/08/2005 13:56:33

zeratul67 >> C'est donc bien l'utilisation du vertex buffer qui permet de ne charger qu'une fois les données. Mais le fait d'utiliser les vertex shaders n'a strictement rien à voir avec cela. Les shaders sont juste des programmes où l'on redéfini nous même les traitements sur les données (vertex ou fragment). Ils n'influent en aucun cas sur la gestion des données en mémoire de la carte graphique. Par contre, le fait d'utiliser les shaders permet dans certains cas d'accélérer le rendu parce que les opérations sont plus simples qu'avec des techniques de rendu en plusieurs passes, nécessaires quand on n'a pas les shaders, par exemple. Et aussi c'est fait au niveau du GPU, où les opérations sont dédiées pour ca, donc c'est plus rapide.
Les programmes sur les vertex shaders reçoivent en entrée des sommets (i.e: coordonnées dans l'espace, coordonnées de texture, normale, couleur...) et les traitent. On ne fait rien d'autre. Au niveau du pipeline on a (très simplifié) :

APPLICATION -- vertex data --> VERTEX PROGRAM -- valeurs interpolées --> FRAGMENT PROGRAM -- fragments --> FRAMEBUFFER

La gestion mémoire se trouve avant le vertex program. C'est au niveau de l'application quand on construit le VBO qu'on détermine que nos données sont dans la mémoire de la carte graphique. On peut très bien utiliser les shaders sans VBO, et donc à chaque frame rebalancer toutes les données de la mémoire centrale vers la carte graphique.

Pour résumer : vertex shaders et vertex buffer ne sont pas liés et sont totalement indépendant.

Commentaire de zeratul67 le 26/08/2005 20:28:14

Biensûr qu'ils sont indépendant, mais il y a deux façons de faire :
- recalculer les vertex avec le CPU à chaque rendu, et donc on a un rempissage de evrtex buffer à chaque fois
- mettre en place le vertex buffer une seule fois (par exemple vertex pour une eau plane) et utiliserl essaders pour l'annimation, donc plus aucune modif du vertex buffer, moins de transferts

Commentaire de mat74 le 27/08/2005 16:25:44

ewik : j'ai regardé tes liens. j'ai trouver pamal de truc et j'ai téléchargé qq programme. mais j'arrive pas à faire marcher se que j'ai téléchargé. il me met "GL_NV_vertex_program not supported". ne serai-ce pas ma carte qui ne supporte pas les shader ?
pourtant je l'ai acheter il y a 2-3 ans seulement

Zazour :
- pour ce qui est de la flêche j'avais même pas penser que sa serait un peu chiant si jamais on tournait la camera parce que moi pour mes teste je ne m'en servais pas
- sinon pour l'explication
en fait je fixe un point au lancement de l'effet, le centre. puis ensuite je scan le tableau d'angle. si un point est à une certaine longeur du centre (sur le plan XZ) je met l'angle à PI ( et attenuation à 1 ). sinon j'augmente l'angle et je descend la valeur d'attenuation que je multiplierai par le sinus de l'angle avant l'affichage pour qu'il ni est pas qu'une seule vague mais plusieurs éco. il suffit ensuite d'augmenter la distance recherché entre le centre et le point en court pour que l'on est l'impression que la vague se propage.
voila j'espère avoir été clair, en tout cas j'aurais essayer.

Commentaire de mat74 le 29/08/2005 17:10:33

j'ai remis à jours les drivers il y a un programme qui passe mais le reste marche tjs pas .
mais j'ai une ati 4200 sa doit être pour sa .

donc en gros je peux pas faire de shader avec une ati ?

Commentaire de blotfib le 05/09/2005 11:44:42

salut

je voulais compiler ça sur du VC++6 mais il me manque le glut.h
j'ai besoin de quoi pour que ça marche ? (et où ?
merci

PS
si j'ai bien compris, cela veut ddire que c'est une win32 appli et pas une fenetre et que c'est glut qui gere les fenetres et le clavier ???

Commentaire de ewik le 06/09/2005 10:03:30

blotfib >> GLUT (OpenGL Utility Toolkit) est une (vieille) librairie gérant le fenêtrage, le contexte d'affichage, le clavier, la souris... Les avantages sont la portabilité et la grande simplicité d'utilisation. En gros pour faire une fenêtre sous windows faut un gros paté tout moche d'une centaine de ligne de code, avec glut faut juste 3 lignes. Tu peux le télécharger sur le site http://www.opengl.org ou sur http://www.xmission.com/~nate/glut.html
Il existe d'autres librairies gratuites comme freeglut qui sont des mises à jour de glut, cependant la plupart des gens se contentent de glut qui fonctionne très bien.

Commentaire de ymerej le 11/05/2006 20:20:09

Y'aurait-il moyen que tu mettes l'executable car quand on télécharge le ZIP, il n'y est pas.
Faut que tu le renommes en .exe.cutable par exemple ;-)
N'arrivant pas à le compiler sous Visual C++ (.NET 2005), j'aimerais bien voir ce que ca donne.

Pour infos, voici mes erreurs de compilation :

    Compiling...
Camera.cpp
camera.cpp(46) : error C2666: 'fmod' : 3 overloads have similar conversions
        math.h(561): could be 'long double fmod(long double,long double)'
        math.h(513): or 'float fmod(float,float)'
        math.h(120): or 'double fmod(double,double)'
        while trying to match the argument list '(float, double)'
camera.cpp(47) : error C2666: 'fmod' : 3 overloads have similar conversions
        math.h(561): could be 'long double fmod(long double,long double)'
        math.h(513): or 'float fmod(float,float)'
        math.h(120): or 'double fmod(double,double)'
        while trying to match the argument list '(float, double)'
Effet.cpp
main.cpp
ecriture.h(30) : error C2664: 'CreateFontW' : cannot convert parameter 14 from 'LPSTR' to 'LPCWSTR'
        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
ecriture.h(81) : warning C4267: 'argument' : conversion from 'size_t' to 'GLsizei', possible loss of data
main.cpp(60) : error C2664: 'auxDIBImageLoadW' : cannot convert parameter 1 from 'char []' to 'LPCWSTR'
        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
main.cpp(452) : error C2440: '=' : cannot convert from 'const char [7]' to 'LPCWSTR'
        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
main.cpp(479) : error C2664: 'CreateWindowExW' : cannot convert parameter 2 from 'const char [7]' to 'LPCWSTR'
        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
Plan_deau.cpp
Vecteur.cpp
Generating Code...