Bonjour.
 
je ne savais pas dans quel rubrique mettre ce nouvelle "extra-terrestre".
 
Pensez vous que les cartes physiques seront l'avenir du jeux vidéo ?
 
- Soulagez le CPU central
- Meilleur expérience de jeux (réalisme d'interaction et de contrainte dans une scéne 3d).
- tout simplement une révolution comme l'a fait 3dfx dans son temps avec le hardware 3d.
 
les ptit gars de ageia, il ont pas fait les choses à moitié !
 
www.ageia.com/novodex.html
 
 
bon d'accord, on va peut être voir la mort de havok...mais bon.

la carte de ageia : PhysX
 
"la voodoo façon newton"

Ca sera implémenté dans les cpu ou chipsets, en attendant c'est gadget. (ni cg ni carte son car les 2 sont susceptibles de s'en servir)

la carte physique est censé soulagé le CPU dans des tâches de colision et autre contrainte de corps souple, corps rigide, interactions d'objets dans un jeux ou app 3d.
 
en gros quand vous voyez le réalisme des interactions dans half-life 2 (havok2), ben c'est de la nioniote à côté de novodex, qui sera utilisé dans certains jeux exploitant l'Unreal engine V.3

toute à fait d'accord Nvidia et ageia pourrait implementer cela dans les CG à venir.
 
pour Ati ??? je ne sias pas, y aura peut être de la concurence dans l'air encore une fois.
 
imaginez : "ouais je vais m'acheter une nouvelle carte 3d physique avec 1go de ram demain".
va t'on entendre ce genre de chose dans 2 ans?  possible?

oui c'est assez prometteur, donc ce n'est franchement pas à considérer comme du gadget, d'autant plus que bien l'IA et la logique de jeu ne soient pas accélérable par chip dédié, celles-ci se reposent énorment sur les requêtes de collision effectuées par le moteur physique.

 
possible.
 
il est probable que les chips d'accélération physique deviennent même plus prépondérant que les bonnes cartes son.
en effet une bonne carte son est un bonus agréable pour qui sait faire la différence, mais les chips de physique peuvent avoir une bonne répercussion sur le gameplay et l'interaction avec le monde. (les mondes 3D sont toujours hautement statiques et peu destructibles.)

les collision seront bien plus précises qu'avec un havok qui fait baver le CPU.
 
on aura peut être plus du proxy mesh pour les collisions, peut être que les collisions seront effectué sur les meshs originals sans saccade.
 
impossible à faire avec havok en temps réel dans une scéne 3d (à moins que vous aimer jouer à 5fps)

je vais faire les course a+

bin pour les détections de collisions mesh/mesh, leur système de PMap utilisant des meshs voxelisés, devrait être un poil plus approximatif que du triangle/triangle, mais ça n'empêche d'utiliser des heuristiques pour passer du PMap au modèle triangle/triangle.
 
bref c'est à suivre enfin je pense qu'on reparlera de ça plus intensément à la sortie d'Unreal 3, qui devrait motiver  les foules.

c'est vrai, il est encore trop tôt pour parler d'une technologie qui n'a pas encore fait ses preuves au grand public.
 
j'attend quand même vos commentaires si vous en savez plus.

Quand on voit qu'aujourd'hui les CPU limitent le potentiel des cartes graphiques haut de gamme dans les hautes résolutions, les puces physiques pour soulager le cpu seront je pense les bienvenues. Et ce d'autant plus qu'elles apporteront un plus indéniable.

Salut a tous,
 
Ce sujet m'interesse beaucoup mais j'ai aucune idée de ce qu'est une carte "physique"?
 
Si quelqu'un pouvait m'expliquer vite fait ca serait sympa !
 
 
Merki d'avance !

en fait il faut déjà expliquer ce qu'est la physique d'un jeu.
 
donc grosso merdo:
 
bon ton jeu il manipule des objets 3D: véhicules: avions, voiture, vaisseaux & objets statiques: arbres, décors (ruines, pièces, meubles), terrain.
 
la partie physique actualise la position & autres états physique de tout ce qui est dynamique, en fonction du reste et de ce qu'on impute aux objets comme forces.
 
en gros la boucle générale d'un jeu (moderne) est: (un peu dans le désordre)
 
1) prise en compte des actions du joueur (clavier/souris)
 
2) prises de décision de l'IA
 
3) gestion de la logique de jeu (bouton pressé->pont qui s'abaisse, niveau de dégats de véhicules trop haut => explosion du véhicule)
 
4) imputation d'actions physiques aux objets 3D en fonction de 1/2/3, et évolution de l'ensemble du monde
 
5) rendu du monde en 3D, actualisation audio
 
=> retour au 1) pour l'image suivante
 
le 5), soit le rendu 3D prends actuellement, et généralement au moins 50% du temps par image.
 
le 4), c'est ce dont on parles, l'accélération du moteur physique par un chip dédié.
 
donc comment ça marche ?
 
grosse modo un moteur physique, tu lui donne la géométrie de ton objet (carosserie, fuselage), ainsi que ses propriétées physiques newtoniennes:
 
- masse
- centre de gravité
- moment d'inertie
 
(nota que pour les objets définis comme statiques, pas besoin de ces infos, juste la géométrie suffit.)
 
aussi un objet peut être une arborescence d'objets indépendants liées....
tu définis donc chaque objet, et la liaison mécanique entre chaque. (degrés de liberté en mécanique).  
 
après une fois ça connu, du 1),2),3) viennent les actions sur tes objets:  
- force + point d'application de la force
- ou directement couples
- ou directement nouvelle position forcée
 
/cours de physique/méca express:
 
grosso merdo, d'après newton, le principe d'inertie c'est quand un objet a une certaine vitesse, il la garde pour l'eternité tant que rien n'agit sur l'objet (valable aussi pour la rotation).
 
ensuite ce qui est contant sans actions extérieures sur le l'objet c'est la vitesse linéaire et angulaire.
 
ce qui va faire varier la vitesse de ton objet, c'est les forces donc:
alors en fait, l'accélération d'un objet c'est a=f/m (f=ma), c'est dire c'est la force appliqué qui fait accélérer l'objet, mais plus il est lourd plus il accélera doucement. (le freinage = accélération négative).
 
donc quand tu as pour chaque objet:
- son centre de gravité
- sa masse
- son moment d'inertie
 
et que tu appliques:
- une force a "un point donné"
 
l'ensemble te permet de calculer:
- l'accélération linéaire de ton objet, impliquant:
  a) la force  
  b) son point donné
  c) le centre de gravité de l'objet (si la force ne passe pas par lui, elle fera moins accélérer)  
  d) la masse (qui est la résistance au mouvement)
 
si tu repiques sur l'electricité: (anlogie à l'arrache)
a=f/m (accélération = force / masse)
et bin ça donne:
i=u/r (courant = tension / résistance)
 
- et de nouveau l'ensemble te permet de calculer l'accélération angulaire, en fonction de:
a) la force
b) son point donné  
c) le centre de gravité
d) le moment d'inertie (qui décrit la résistance angulaire)
 
/cours de physique express terminé
 
donc une fois que tous les objets ont leur vitesse d'actualisée dû aux accélérations (positives ou négatives) provoquées par les forces appliqués,
 
il faut actualiser la position et savoir si où on est c'est confortable.
 
donc le moteur actualise les positions/orientation des objets, en fonction du temps passé lors de l'image précédente.  
 
ie si le jeu est 100fps, alors par image le moteur physique doit l'évolution des objets pour 1/100ième de seconde.
 
... puis testes les objets les uns contre les autres pour savoir si ils se sont cognés.
 
si ils se sont cognés il faut répondre à ce choc de manière censée.
 
hors là des problèmes peuvent aparaitres: si le temps d'évolution du monde est trop grand, et/ou les vitesses d'évolution des objets sont aussi trop grandes, les objets peuvent se pénéter de plusieurs mètres, voir se croiser sans avoir de collision de détectée !!!!  
 
image deux avions de chasse à mach 1 => 330m/s
donc la distance entre les deux avions se réduit à 660m/s
si on est à 100fps, soit 1/100s, l'écart entre les deux objets se réduit par tranche de 6.6m.  
 
ce qui peut causer des sacrées blagues de gameplay.
 
pour ça, on appliques des techniques, dont l'une d'elle et de tout simplement réduire le "pas" de simulation, ce qui fait que par exemple, pour toujours 100fps, soit 1/100s, donc 10ms, le moteur au lieu de faire ces 10ms d'un coup, va faire 10 étapes de 1ms.
ce qui fait que l'ecart entre nos deux avions passe à 0.66m, ce qui est déjà mieux.  
 
problèmes => le temps de calcul est potentiellement multiplié par 10.
 
---
 
ensuite, façe aux collisions, il faut ensuite savoir "comment" répondre, et ce en accord avec la logique de jeu.
 
est-ce que tu faire exploser l'objet ?
 
est-ce que l'ensemble du moteur du jeu est capable de gérer les démenbrements/éclatements localisés des modèles ?
 
est-ce que tes objets sont élastiques, va-t-il y avoir un rebond (rebond qui va générer une force et agir sur les objets impliqués) ?
 
est-ce que les objets qui se rentrent dedans le fond à basse vitesse et raclent alors l'un sur l'autre (en générant une friction qui étant une force, va a son tour agir sur les objets) ?
 
est-ce qu'en fait on est dans un cas d'adhérence, et le objets vont rester collés de manière statiques l'un à l'autre ?
(ndlr: dans les attributs de la simulation, il a aussi l'accélération gravitionnelle commune à tout le monde qui est définie par la logique de jeu)
 
---
 
valà en gros a quoi aide la carte physique.
 
en fait c'est plustôt la réponse à "c'est quoi une moteur physique ?".
la carte d'accélération physique prenant à sa charge tout ou partie de ce que le moteur physique fait. (en tant que portion de logiciel)
 
je sais pas si ça t'a aidé ou si ça t'a perdu...

Ok merci beaucoup pour cette explication beaucoup plus que détaillée.
 
En fait j'avais pas compris "physique" dans le sens du moteur physique, mais dans le sens "pas intégrée" (dsl j'sais pas trop comment dire ^^) et donc j'comprennais pas la différence avec les cartes graphiques.
 
 
Donc si j'ais bien compris, là ou les cartes graphiques se contentent d'afficher ce que leur dit le moteur physique du jeu, la carte physique quant à elle se permet d'assister directement le moteur physique dans ses taches, et donc d'alléger la tache du processeur entre autres.
 
Corrigez moi si j'me trompe    
 
 
Merci encore!

Ouais ce sera pô mal comme truc ça, surtout avec les gros jeux qui arrivent bientôt la.
 
J'ai testé le Novodex Rocket et ben sur les scènes d'explosions avec tous les blocs qui voltigent partout ben mon CPU demandait pardon...
 
J'ai lu kek'part comme quoi ils vont l'intégrer direct au mobos, y'aura les cartes apparts aussi alors ?
 
Sinon c'est clair que c'est pas pour tout de suite mais la sortie d'UT 2007 l'année prochaine pourrait accélérer les choses...

 
xactement, elle s'immice dans la boucle de simulation en s'occupant très certainment des calculs de collisions entre objets 3d, et probablement de la physique/mécanique faisant évoluer les dits objets 3D (ce sont deux étapes distinctes mais inter-dépendantes puisque une collision entrainera de nouveau des calculs de physique/méca).
les tests de collisions étant encore plus couteux que la physique/mécanique utilisée en amont. (et aussi générés en cascade)

et il servira a faire quoi le processeur central pendant ce temps ? il va tourner a 10% d'usage si ca continu...
on est en train de recommencer l'époque Amiga 500 avec 40 chips spécialisés.
 
moi je suis totalement anti carte PCI pour la physique des réactions.
d'abord parce que on ne controle plus les routines qu'on utilise (bien que dans le monde professionnel le jeux vidéo ressemble plus a un assemblage de middlewares qu'a un vrai coding, excpeté les jeux john carmack..) mais aussi parce que ca va recommencer l'époque zone de non normalisation où chaque société tente d'imposer son standard.
rappellons nous matrox diamond nvidia rendition verite et 3dfx à l'epoque de la 3D, mais le besoin etait réel a l'époque, de nos jours les procs deviennent muticores alors autant utiliser ca que de nous faire payer encore des $$$.
et si jamais ca s'impose finalement, eh bien je préfererais que les chips physiques soient intégrés à la carte graphique !
et que si on en a pas, et ben ca marche quand meme en émulation software.
 
edit:
bjone si tu veux savoir précisément ce que ca fait, voila:

toutes les routines classiques qu'on doit coder quand on fait un jeu digne de ce nom quoi...

Les collisions seront toujours gérées par le cpu je pense, par contre le PPU se chargera de générer la modélisation physique de la collision (mur capitonné != mur de briques != cloison en placo)

Moi j'attend de voir concrètement la différence...

Franchement une bonne CG et un bon pross c est deja pas donné , sans compté le reste alors si on doit encore rajouter ce genre de truc je prefere passe a la console ce sera moins cher.
 
De plus je vois pas l interet de ce truc avec les prochains quad core on saura pas quoi faire des CPU en trop alors dans ce cas ils peuvent bien se farsir seul le moteur physique d un jeu au lieu de rien faire.
 
Sincerement j espere que ces trucs passeront vite par la case poubelle, au pire on pourrait les integerer dans la CG, mais j espere alors que la facture n eclatera pas.

 
 
On ne peut PAS les intégrer à un GPU, c'est un co-processeur tout comme l'était la FPU à l'époque des 386/486.
 
En fait, le comportement est très différent d'un gpu ou d'une carte son, puisque c'est comparable à un DSP:
 
- le cpu détecte une collision, il passe la main au ppu
- le ppu "calcule" le résultat en fonction des paramètres (temps de calcul << cpu, car on utilise des fonctions "cablées", paramétrées via une tâble définie pour chaque élément) et renvoie le résultat au cpu
- le cpu détermine le type de résultat (si on reprend l'exemple capitonnage/briques/placo, c'est une accélération quasi linéaire/exponentielle/exponentielle brisée) et fait appel au ppu une seconde fois si nécessaire pour calculer les trajectoires des débris.
- le gpu affiche
- la carte son fait son son, elle aussi peut utiliser le ppu si il permet de calculer les dispersions d'ondes (actuellement, c'est géré par l'EAX)

 
oui je sais je fais mumuse avec les examples du SDK (j'ai pas encore codé vis à vis de novodex pour le moment)
 
mais:
 
- ouais y'a pas mal de middlewares dans les jeux vidéo et alors ? tu crois qu'un dev tout seul en 1 an pourra abattre autant de boulot que 10 (et encore je suis gentil) mecs plus calés qui font ça depuis des années. après c'est une question de résultat désiré aussi, on est d'accord.
 
- à l'époque de 3Dfx et de la rendition vérité, y'avais pas de besoin, le besoin il a été crée en présentant ce que ça permettait de faire par rapport à une solution logicielle.
là c'est pareil y'a absolument pas de besoin, sauf que quand les jeux monteront la charge au niveau objets par simulé par un moteur physique, bin l'écart de perfs effective créera l'envie de l'acheter...
à l'époque de la 3Dfx y'avait ceux qui avait jamais vu de 3Dfx tourner et qui achetait de l'Ati suite aux conseils de PC Malin Hebdo, et qui en voyant une tourner savaient qu'ils auront à investir.
 
- oué je suis aussi contre les cartes PCI et pour les PCI Express (avec un contrôleur faible latence intégré au cpu pour les cartes 3D et cartes physiques, et les autres périph PCI-Ex via un southbridge).
 
sur la carte mère non, puisque l'interêt d'une carte dédiée, c'est que la mémoire embarqué sur la carte peut être cablée avec un bus très large et haute-fréquence. alors que ça, ça n'a -jamais- été fait pour un chip graphique intégré (ou alors avec 3 ans de retard par rapport aux cartes 3d en cartes d'extension).
 
idem sur la carte graphique, les données manipulées le sont dans une contexte sensible différent, et tu obtiendra toujours plus de performances à avoir deux blocs distincs avec leur propre mémoire locale.
enfin ça pourrait être un frein à l'intégration sur mobo ou sur carte 3d.
 
de plus les cartes d'accélération physique, auront certainement un cycle technologique plus lent qu'une carte 3D, d'une  part c'est le rendu qui bouffe essentiellement le temps par frame donc il aura toujours une course frénétique aux perfs pour le rendu, en tous cas certainement plus que pour les chips de physique. donc pareil pour un joueur, si tu change de carte 3D tous les ans, m'est avis que les cartes de physique, ce sera tous les 2-3 ans. (moins fréquemment qu'une carte 3D, mais certainement plus fréquemment qu'une carte son).
 
enfin on verra comment ça se confirmera...

 
justement, le problème et l'avantage, c'est que c'est ptet parti pour avoir plus de perfs avec un monocore+chips dédiés qu'avec un quad-core.
 
que tu ayes un quad-core ou un monocore, la bande-passante mémoire risque d'être la même.
là la carte d'accélération physique c'est le même combat que la carte 3D: faire du 20-30Go/s là où on a que 6Go/s max pour les cpus, que l'on soit en mono ou bicore.....

 
pour moi le PPU fait les collisions. (cf les PMaps)

La détection étant binaire, je pense pas...
 
Dans tous les cas, le PPU est bien ce qui fera passer les FPS et autres jeux du "je tire, ça fait un trou dans le plus proche objet sur la trajectoire" au "je tire sur un montant métallique, la balle ricoche".

 
Je vois pas le rapport.  

Si ce genre de truc est intégré au GPU pourquoi pas sinon ben ça fera trop de carte dans le pc

D'ailleurs question conne, ca se présente sous quelle forme une carte physique?

 
Celle d'Asus :

Donc c'est une carte pci comme une autre.
 
Merki!

 
enfin celle-là c'est un exemplaire d'ingénérie.

la bande passante du pci suffit pour une carte physique ? O_o

apparrement mais ss dout pas l'alim, on voit une molex dessus.

 
bin idéalement pour ce genre de trucs, il vaudrait mieux du PCI-Ex.

Après une lecture attentive de vos commentaires, on voit tout de suite les connaisseurs, n'est ce pas bjone..
 
merci à tous pour vos avis et vos explication qui metteront un peu de lumiére pour ceux qui se posaient des questions, ou carrément pur ceux qui découvrait l'existance d'une telle puce.

+1 ce sera une révolution.
 
et je ne crois pas à la solution annoncée ces jours -ci qui est de passer par le GPU. déjà que ça rame rien que pour le rendu, alors ça ne sert à rien de bouffer des ressources GPU pour faire la physique.
 
en plus les GPU ne sont pas câblés pour ça à l'origine donc les perfs seront forcément moins bonnes.
 
quant à se contenter du CPU pour ça, on peut mais les perfs ne seront jamais comparables à un PPU dédié. le CPU est une unité généraliste (et en plus il a largement autre chose à faire).

c'est du pci-e

 
     Moi zé rien compris!!  

 ça y est je vient de comprendre U=R*I !! ....merci Bjone              (larmes de reconnaissance!!)
 c'est vrais sans rigoler !!!