Discussion :

[delire8]

Bonjour,

Je suis actuellement en train de faire un petit programme me permettant de tracer des graphes. L'utilisateur peut choisir entre DirectX et OpenGL.

Dans les deux cas, je suis confronté au problème du tracé d'un grand nombre de primitives (des droites). J'ai donc choisi de ne pas pouvoir tracer des lignes à la volée, mais de passer par des VertexBuffer.

Mais voilà, ça ne fonctionne bien que si mes courbes ne changent pas dans le temps. En effet, sinon, je suis amené à régulièrement détruire/créer des vertexbuffer... C'est presque pire que d'appeler directement gLVertex & Cie!

Quelle technique utilise-t-on dans ce cas? Comment rendre rapidement (et génériquement, si possible) un grand nombre de segments quand ces derniers bougent régulièrement?

Merci

Cordialement

[LeGreg]

Les APIs ne sont pas adaptés pour traiter ce genre de problème "rapidement". Ceci dit ce n'est pas vraiment un problème parce que généralement c'est très rapide (comparé au rendu d'un jeu complexe en 3D ou le décodage d'une vidéo compressée) même s'il ne faut bien évidemment pas faire n'importe quoi.

Une solution qui sera peut-etre possible dans ton cas est par exemple de mettre la fonction de tracé dans un pixel shader ou un vertex shader. Exemple : une série de vertex shaders qui tracent des droites qui prennent x en argument et sortent y. Ou un pixel shader qui allume un pixel s'il répond à l'équation f(x,y).

En passant par là, tu n'as à remettre à jour que le pixel ou le vertex shader pour tracer ta fonction.

Créer des vertex buffers à chaque frame est à éviter. Tu l'as bien compris. Mais ce n'est pas parce qu'un vertex buffer a été créé que son contenu ne peut pas changer, on parle de vertex buffer dynamique dans ce cas.
Changer le contenu du vertex buffer implique de réenvoyer le nombre de sommets à chaque changement de fonction, ce qui est certes peut paraître plus lourd que de changer un vertex program, mais parfois plus léger (si on prend en compte la compilation de shader et le fait que la fonction peut tourner sur n'importe quelle carte graphique et pas uniquement celle qui supporte la complexité de la fonction).

LeGreg

[delire8]

Pour le moment, je vais donc me diriger vers les VB dynamiques.

En ce qui concerne les shaders, n'est-ce pas un peu sortir la grosse artillerie? Tu dis que OGL et DX ne sont pas adaptées à ce que je veux faire. Mais alors, quelle technologie utilisent les logiciels de calcul scientifique (matlab, maple, etc. )?

Merci

cordialement

[Mat.M]

Mais encore une fois pourquoi vouloir appeler Open Gl ou Direct X pour tracer des courbes ?
Sous Windows le GDI peut largement suffire si tu sais l'utiliser de manière optimale..et puis le GDI a suffisamment de fonctionnalités pour faire cela.
Direct X c'est plutot mieux adapté pour afficher des objets 3d temps réel .
Avec Direct3D tu as très peu de fonctionnalités de dessin l'API offre même un moyen pour dessiner avec le GDI ce qui peut-être redondant.
Et puis faut pas perdre de vue les petites machines ; si la machine n'est pas très performante notamment du point de vue carte graphique DX fera une émulation de l'accélération graphique..

Pour tracer rapidement avec le GDI il suffit d'utiliser la technique du HDC en mémoire tu crées une HIBTMAP avec CreateCompatibleBitmap tu dessines dedans et tu dessines sur l'écran principal avec StretchBlt

Mais alors, quelle technologie utilisent les logiciels de calcul scientifique (matlab, maple, etc. )?
cordialement

Tout simplement le GDI et win32 ! Des bêtes HDC des HBITMAP
( si ça tourne sous Linux je ne sais pas )
A moins que ces logiciels utilisent leur propre Device Driver mais là dessus j'ai des doutes...


Regarde les specs de Maple il y a pas une ligne sur la nécessité éventuelle de DirectX
http://www.maplesoft.com/products/Ma...uirements.aspx