En ce moment commencent a sortir les premieres cartes physiques (avec PPU : Physical Processor Unit).
Je me dis que pour sortir un tel matériel, il faut avoir défini des normes, des axes, des façons de procéder
(un peu comme un GPU ne fonctionne que sur les Meshs triangulé, sait gérer les interpollations de couleurs, les textures, etc etc : toutes une "Norme" )

J´aimerais savoir si quelqu´un connait un peu les normes utilisées pour piloter les PPU.
Quelles librairies seront utilisées ? Que savent elles faire ? Quelles formules théoriques utilisent t elles ?

Bref, comment va fonctionner un moteur physique qui pourra etre pris en charge par un PPU ?

J´ai lu que les PPU auront une architecture très proche de celle des cartes graphique car la physique demande le même genre de calculs.
D´ailleurs nVidia et ATI pensent utiliser dans le futur une des cartes en SLI (pour nvidia) et en Crossfire (ati) pour gérer exclusivement la physique.

PS : SLI et Crossfire signifie faire fonctionner deux cartes graphiques en même temps.

Merci pour la réponse.
je recherche davantage la théorie qui sera utilisée.
Je sais que dans les cartes graphique est utilisé un Pipeline graphique, qui comporte une séquence de choses a faire entre le meching et le rendu.

Aurais tu le pipeline d´une carte physique ?
Ou bien tout simplement l´algorithme (le pipeline) qu´une carte physique saura faire ?

Quelle est la nature des données qui entre dedans, la nature des données en sortie ?
(par analogie : pour une carte graphique :
- en entrée : des vertex, des coordonnées de textures, des bitmap de texture, une ou plusieurs matrices, ....
- et en sortie : un bitmap de rendu)

Bah je pense qu´on entre des objets avec leur position dans l´espace et leurs propriété (masse etc.) et qu´il nous ressort de nouvelles position pour ces objets, car ils auront bougé. Mais je m´y connais pas trop en PPU

Oui, ça c´est une certitude, mais c´est le détail que je voudrais
Mais merci quand meme pour ta réponse

je ne sais pas qui fabrique ça (mais si il en sort, il doit bien y avoir des constructeurs).

Peut-être que dans la doc de référence du constructeur (genre celle de intel pour les pentium) il y a les information qui t´interesse.

Mais je ne suis pas sûr que ces papiers soient toijours accessible gratuitement comme c´est le cas pour intel.

J´en ai vu une dans JeuxVideo Magazine : marrant, une carte sans aucune prise derriere

Bon, apres, elle se faisait un peu casser parce que c´était pas si bien que ça pour le prix, mais bon, c´est une des premieres...

Oulà, tu demande des trucs super pointu là.

"Quelle est la nature des données qui entre dedans, la nature des données en sortie ?"

Celles qui rentrent, à priori ce ne sont que des vertex (la cage de collision déjà calculé) et ses paramètres de masse, élasticité, friction, groupe physique, etc ... (je résume, je ne vais pas rentrer dans les détails)

M´enfin ça dépend de la carte physique ça, vu que le moteur différe d´une carte à l´autre.

pasdebol37 >
"(je résume, je ne vais pas rentrer dans les détails)"

Goto "mon 3e post sur ce topic";

Mais merci quand meme.

Je parlais pas de ces détails là
Les truc de pipeline, API et autres, ça je connais pas et j´y connais rien d´ailleur. Contrairement à toi je ne suis pas programmeur.

Les seuls trucs qui me sont familiers c´est par exemple la génération des cages et leurs propriétés, comment on peut les faire intéragir, etc... mais sans rentrer dans des algo de physique ou formules mathématiques complexes (bien qu´on en voit déjà en terminale)
Donc comme je suis pas sur que c´était pas le but de ta question (tu parlais de trucs qui me sont inconnus), j´ai pas voulu développer dans le vide

Peux être que tu trouvera ton bonheur ici :
http://www.ageia.com/developers/index.html

Je t´avoue que j´ai pas eu le temps de fouiller (et ho je dois aller à l´école moi ), mais ça ressemble méchament à un support pour développeurs donc...
Il y a même un SDK pour les curieux.

Merci

J´ai épluché ce site, hélas, visiblement (ou alors je n´ai pas regardé assez longtemps), je ne peux pas télécharger cette API (ni sa documentation) sans etre client.

En épluchant la documentation, je saurais comment sont mis en place les moteurs physiques qui exploiteront le matos.
J´avais vu sur le net quelques moteurs physiques amateurs plutot bien fait, mais peut etre incompatibles avec les normes qui se mettent en place.

Bref, il faut croire que cela est encore trop récent pour etre bien normalisé.

D´après ce que j´ai compris et lu, ce sont des cartes pour exploiter des moteurs physiques existant, pas l´inverse.

Ageia fait ses cartes pour son moteur propre PhyX (son API physique), et Havok prépare sa propre carte pour son moteur du même nom.

"D´après ce que j´ai compris et lu, ce sont des cartes pour exploiter des moteurs physiques existant, pas l´inverse. "

--> Oui, et non.
J´explique ce qui me gene dans ta phrase. Peut etre que les moteurs physiques existants présentent une structure bien définie, et bien normée, a ce moment la, les cartes s´appuient dessus. Mais une fois la carte faite, il n´est plus possible de changer vraiment le moteur physique, car il n´y a rien de plus rigide que de l´electronique qui fait un algo rapide sur une carte.
Quoiqu´il en soit, je te crois, pour faire la carte, on s´est appuyé sur les lib physique les plus souples. D´ou ma question principale, comment fonctionnent ces libs ? quelles structures utilisent elles ? Que peuvent elles faire ? quelles sont leurs limites...

"Ageia fait ses cartes pour son moteur propre PhyX (son API physique), et Havok prépare sa propre carte pour son moteur du même nom. "
Ta 2e phrase me fait également comprendre que la "norme" que je recherche n´est pas encore faite. En effet, si chaque constructeur de lib fait sa propre carte, c´est qu´on ne s´est pas mis au point sur une norme.

Un peu comme les cartes graphiques il y a quelques années : au début, 3DFX était une carte qui supportait Glide, qui maintenant n´existe plus. On s´est mis d´accord sur les normes DirectX et OpenGL, qui sont basées sur une représentation triangulée, et on y a ajouté des options avec le temps (filtre de texture de plus en plus évolués, mipmapping, pixel/vertex shading...)
La "norme" pour le graphique, c´est le triangulé. En effet, il existe plein d´autres moyens de représenter de la 3D (les triangles, le B-REP, les équations pures, le BlobTree), et plein de moyen de la rendre (les scanlines, le Z-buffer, le raytracing et ses évolutions, etc...)

Mais pour les cartes graphiques, on a choisi la réprésentation en triangles, rendue avec un Z-buffer.

J´attends de voir l´évolution des moteurs physiques, en espérant qu´il vont tendre vers des techniques normalisées souples et puissantes, cablables dans des cartes, et normalisées (bien qu´évolutives avec les générations des cartes).
Et toute la partie théorique et pratique de cela m´intéressera

Je pense que les moteurs les plus puissants ne seront pas basé sur une "soupe de triangles" telle qu´on l´envoie dans la carte graphique.

En effet, la soupe de triangle, c´est bien pour le rendu, mais pour la physique, c´est un cauchemar :
Impossible de savoir si, pour un point P(x,y,z) donné, on est dans un objet ou non.
Pas de notion de topologie
les modeles sont finalement creux...

Et au niveau physique, c´est ultra artificiel...

"Ta 2e phrase me fait également comprendre que la "norme" que je recherche n´est pas encore faite. En effet, si chaque constructeur de lib fait sa propre carte, c´est qu´on ne s´est pas mis au point sur une norme."

Voilà, c´est ce que je voulais souligner.

"Impossible de savoir si, pour un point P(x,y,z) donné, on est dans un objet ou non."

En effet, ce travail se fait dans la phase préparatoire lorqu´on génère les cages physiques, donc finallement on en a plus besoin par la suite. Une fois fini, le moteur ne s´occupe plus que de gérer les collisions en cas d´intersection de 2 cages. Celles ci étant forcement extérieures les unes par rapport aux autres, si il y a intersection c´est qu´il y a collision entre 2 objets (sauf cas particulier pour des objets non statiques, comme le personnage du joueur par exemple)

Les cages peuvent être creuses ou pas ?

Qu´est-ce que tu appel creuse? Concave?
Si c´est le cas, alors oui.