Reprise du message précédent :

 
 
Je n'étais peut etre pas clair.
 
Je Disais Que NV30 et R300 seront à prioris 100% DX9 et donc offrirons plus de 'fonctions' 3D et // et  vraisemblablement plus de  performance (en FPS) ( sous certaine conditions)
 
j'équilbrai cela avec des fonctions de la parhelia dont je Doute ( ceci basé sur le passé de ces compagnies et leur target) que  NVIDIA et ATI integre a leur puce.  
 
 
1) le triple head (c'est une fonction qui a bien plus d'interet pour les financiers que pour les joueurs en fait, je pense les chances faible pour que nvidia et ati s'allignent pour le moment)
 
2) la qualité des RAMDAC et des filtres de coupure (ca coute chere, nvidiati ne fabrique pas leur carte les cartes actuelles sont pas si mal et conviennent a la majorité, les specs DX9 impose je crois le codage en 10 bit  , d'un point de vue marketing dire J'ai 10 bit c'est plus vendeur que j'ai un filtre de 4ime ordre avec une pente de x mv/sec
 
 
3) le suport des ecrans TFT jusqu'en 1920x1200 c'est a dire au dela de la norme DVI (un oublie mark ?) ( la je n'imagine meme pas NVIDIA penser au utilisateur de TFT , pour info le Gforce meme le 4 a toujours son tdms interne toujours buggé et doit  utiliser un silicon image externe...)
 
4) le FAA , la je pense qu'il y a des chance  pour que Nvidia et ATI ai quelque chose pour entrer en concurence
 
 
Moralité Je me repete sur le papier et a terme (moyen) NV30 et R300 seront surement plus rapide et plus fournit ( ce qui est logique) cependant je ne pense pas (cf cidessus) que toutes les fonction du pharelia seront egalisé (pas forcement parceque la concurence ne sais pas faire, mais parceque cela n'est pas leur but. Par ailleurs Je pense aussi que les NV30 et R300 ne montrerons leur dominations reel par rapport aux parhelia que lorsque les jeux tirerons majoritaierement partie de l'ensemble de DX9 ce qui comme l'experience montre n'arrivera que lorsque le NV35 et le R350 seront annoncé... ( et peut etre mais la c'est moins sur le Parhelia 1024).
 
Je conclue donc par saluer le fait que le parhelia sort au bon moment... et je salut matrox pour cela.
 
Enfin si effectivement on trouve des parhelias avans noel...
 
 
 
Quant a Nvidia / Ati / Matrox lobbying
 
J'ai eut une ati, rage128 et je me suis jurer de ne plus jammais  acheter ATI . j'ai eut une Voodoo 3000, et 3DFX a fait faillite, j'ai acheter une Gforce2, pour m'appercevoir que meme le ref design etait buggé (sortie de cela je n'est suis pas mecontant), La Radeon 8500 me paraissait une bonne carte avans que je ne lise les forum d'end user sous les kilos de probleme.
et je risque de m'acheter un Gforce 4 4200 (comme tout le monde ?)
 
Cela ne m'enpeche pas de reconnaitre l'interet de Matrox
 
sur ce je pense que comme bcp de lecteur du forum nous avons tous (toi compris) depassés les querelles sterilles et Machistes entre Nvidiot, Atidiot , et Matridiot
 
 

Ok, je vois.
1- Il me semble que des produits pro existe chez NVIDIA faisait cela plus que cela (comme ATI je suppose). Mais il est vrai que pour le joueur cela a moins d'interet. Mais comme Matrox avait déjà l'avantage en 2D, ce n'est pas etonnant.
 
2- Je ne sais pas ce que feront ATI/NVIDIA, donc je ne peux me prononcer, mais Matrox a toujours etait à la pointe de la 2D
 
3- Idem 2
 
4- Vu les défauts possibles (en terme de qualité et de perte de perf), j'attendrai les tests. Mais comme dit plus haut, on ne sait pas ce que nous réserve ATI/Nvidia.
 
Maintenant, Matrox à fait une bonne carte, à la pointe de la technique aujourd'hui (enfin si on laisse de coté 3DLabs), mais surtout sur ces points forts (la 2D, et le multi-écran), et pour la 3D, on verra.
 
Le problème est que les personnes qui tirent parti de ces qualités (indéniables) ne sont qu'une infime partie de la population des acheteurs.

Dr Worm surtout quavec les gf il n'y a pas de pb....fo pas deconner j'en ai eu depuis que les 1eres sont sorties ,mais je ne me tiendrais pas a mon experience,il suffit de lire le forum et taper "n'vidia pb" tu verras ,tu risques d'etre surpris!!!
heu pareil pour ATI ,mais bon j'en ai une elle fonctionne pas trop mal disons!!!

That's true. When stencil buffers are used in the game, faa will give you this artifact. That's why we will give the user the option to switch to fsaa or disable faa, their choice.  
http://forum.matrox.com/mgaforum/F [...] 138-3.html

et il faut citer ce qu'il y a au dessus :
 

 
Donc, le FAA marche sur 85% des jeux actuels
Pour les autres, le FSAA prends la relève.

 
 
 
 
Pour Nvidia c'est vrai qu'il n'y a pas vraiment de probleme de drivers, il ont mis un peu de temps a pondre un nview/twinview qui fonctionne bien mais ils y sont arrivés,  je pinaille  
Par contre ATI ... ; cf http://www.rage3d.com/board/  les "heureux" pocesseurs de Radeon 8500 ils m'on l'air d'avoir essuyé pas mal de platres. enfin c'est de l'histoire ancienne maintenant.
 
 
 
=> evil,, tout à  fais d'accord
 
 
 
Ps: ni nvidia ni ati n'offrent de solution (pro ) a plus 2 moniteurs à ce jour
 
NB: Appian est une compagnie qui fabrique des cartes à 4 moniteurs sur des chips proprietaires AppianX,  Appian a vendue/licence a ATI la technologie logiciel multi ecran. Maintenant Appian a creer (deseign) une carte l' Appian rushmore basée sur 2 chip Radeon Ve qui replace la X.
 
Donc si on veux ATI "a" une solution 4 moniteurs,au detail pres que  Appian n'appartient pas a à ATI enfin bref.
 
 
 
pour le FAA il semble qu'il y ai plusieur cas ou il ne fonctionnent pas. la parhelia offre aussi un FSAA, limité à 4X seulement ?!

info incroyable
   
 
Bon, je suis HS, mais c'était plus fort que moi

quoi g dit une connerie ?

 
non

Pour ATI je ne sais pas, mais NVIDIA depuis peu si
 

http://www.hardware.fr/html/news/?date=19-02-2002#4521
 
@chr_79    

Evildeus a écrit a écrit : Pour ATI je ne sais pas, mais NVIDIA depuis peu si   Citation : NVIDIA a également annoncé deux solutions destinés au multi écran professionnel : le Quadro4 200 NVS et 400 NVS. Le Quadro4 200 NVS, basé sur le NV17, est une solution bi-écran low-profile (un seul connecteur pour les deux sorties) alors que le Quadro4 400 NVS est une carte pouvant gérer jusqu'à 4 écrans via deux NV17. Compaq, HP et IBM devraient intégrer ces produits dans leurs stations de travail. http://www.hardware.fr/html/news/?date=19-02-2002#4521   @chr_79

 
 
 
 
 
 
tout a fait, et bien vue
http://www.nvidia.com/docs/lo/1625 [...] .20.02.pdf
 
 
j'ajouterai que les solutions nvidia et appian utilisent chaqune 2 chip radeon ve ou Gforce comme la matrox M200mms
( ex parhelia poison d'avril made by marc)

Je viens encore de lire des trucs intéressants sur le net.
 
Par exemple, le FAA de Matrox qui a l'air trés bien par ailleurs ne marcherait pas, notamment dans les jeux utilisant le stencil buffer. Ce buffer est notamment utilisé pour faire des ombres dites "réalistes". C'est cette méthode qui est ainsi utilisée dans Medal of Honor quand on active les ombres complexes.
 
La ou ca devient intéressant, c'est quand on se rappelle quel prochain jeu va utiliser MASSIVEMENT le stencil buffer, et qui sera aussi MASSIVEMENT médiatisé.
 
Oui, c'est Doom 3
 
Bon, là encore, faut attendre d'avoir la carte pour juger. Mais je m'interroge, je m'interroge !
 
Pour tous les nvidiots du forum, qu'ils se rassurent. Anandtech a un article sur la parhelia, et Anand, que je considère comme plutôt sérieux, a eu des infos, qu'il garde pour lui pour le moment (NDA), sur le nv30. Et avoue à moitié que Matrox ne sera champion en performances qu' à court terme. On sait aussi qu'il n'a encore rien vu de la R300 donc pour la prochaine ATI, il ne se prononce pas encore ! mais il va "savoir" la semaine prochaine puisqu'il passe chez ATI pour ca !
 
Matrox, si tu nous entends sors VITE tes cartes !

Je me posais une Question à propose du Displacement Mapping:
Un des exemple donné par Matrox est la displacement Map du Grand Canyon. Imaginons que le Grand Canyon est modelisé grace au DM dans Combat Flight sim 35. Lors de la mission où le héros à bord de son F-18 est poursuivi par une soucoupe volante et doit faire en sorte que le méchant E.T. s'écrase sur une paroie du canyon pour s'en débarasser (toute ressemblance avec des personnages ou des évenements connus est purement volontaire   ), comment le processeur sait-il que l'affreux s'est bien pris une falaise dans la gueule alors que pour lui (le proc), le Grand Canyon n'est qu'une plaine à perte de vue (étant donné que tous les reliefs ont été généré par le parhelia grace au DM) ?

mareek a écrit a écrit : Je me posais une Question à propose du Displacement Mapping: Un des exemple donné par Matrox est la displacement Map du Grand Canyon. Imaginons que le Grand Canyon est modelisé grace au DM dans Combat Flight sim 35. Lors de la mission où le héros à bord de son F-18 est poursuivi par une soucoupe volante et doit faire en sorte que le méchant E.T. s'écrase sur une paroie du canyon pour s'en débarasser (toute ressemblance avec des personnages ou des évenements connus est purement volontaire   ), comment le processeur sait-il que l'affreux s'est bien pris une falaise dans la gueule alors que pour lui (le proc), le Grand Canyon n'est qu'une plaine à perte de vue (étant donné que tous les reliefs ont été généré par le parhelia grace au DM) ?

La question a déjà été posé, mais je n'ai pas trouvé de réponses interessantes

 
c'est quoi déjà le stencil buffer ?

http://rvirtual.free.fr/programmation/OpenGl/Tests.htm
http://w3imagis.imag.fr/Membres/Gi [...] Avance.pdf
http://www.matrox.com/mga/francais [...] buffer.pdf

 
merci  

mareek a écrit a écrit : Je me posais une Question à propose du Displacement Mapping: Un des exemple donné par Matrox est la displacement Map du Grand Canyon. Imaginons que le Grand Canyon est modelisé grace au DM dans Combat Flight sim 35. Lors de la mission où le héros à bord de son F-18 est poursuivi par une soucoupe volante et doit faire en sorte que le méchant E.T. s'écrase sur une paroie du canyon pour s'en débarasser (toute ressemblance avec des personnages ou des évenements connus est purement volontaire   ), comment le processeur sait-il que l'affreux s'est bien pris une falaise dans la gueule alors que pour lui (le proc), le Grand Canyon n'est qu'une plaine à perte de vue (étant donné que tous les reliefs ont été généré par le parhelia grace au DM) ?

 
Exactement de la même manière qu'aujourd'hui : les reliefs sont entrés grossièrement, et le proc fait ses calculs de collision dessus.
Imagine le temps processeur que ça boufferait si le cpu était obligé de travailler avec des objets très complexe. Rassure toi, la détection de collision est un problème qui date, et qui peut être résolu par de nombreuses méthodes mathématiques, plus ou moins complexes et consomatrice de cpu.
Regarde l'exemple de l'extra-terrestre da matrox : une gestion de collision sur le modèle avant le dm est largement suffisante non ?

 
non,
 
il existe une tesselation de base qui ne se résume pas a 1 polygone définissant le terrain. le DM ajoute du détails il n'a pas pour but de définir toute la géométrie. Il suffit de faire en sorte que les min et max soient définie par la géométrie de base en plus d'autres point. A ce moment un calcul de la pente par la géométrie de base permet de savoir ou t'en es.
 
y aura pas plus de prob, sauf si on fait n'importe quoi, mais là pas besoin du DM, les dev savent deja très bien mettre les cadavre dans les marche d'escalier, faire traverser les bras dans les portes, etc ...

 
OK, donc ceux qui nous annonçaient que le DM sevirait à faire des décors hyper réalistes rien qu'en utilisant les cartes IGN comme displacement map se sont fourré le doigt dans l'oeil jusqu'à l'épaule (n'est-ce pas marc ) ou nous on plus ou moins menti (c'est pas beau ça Mr Matrox).
 
Au final, si je comprends bien, le DM ne sera qu'un HOS qui regroupes les avantages de RT-patches de nvidia (grande flexibilité) et du truform d'ati (facile à programmer).
 

 
Moi j'aime bien les cadavres qui lévitent au dessus du vide quand ils ont juste un pied sur la terre ferme   . Je trouve que les developpeurs de quake-like sont un peu feignant sur le coup puisque ce problème est réglé dans pas mal de beat em all sur console (Virtua Fighter par exemple).

 
Le reflief peut tout a fait être dessiné de A à Z via une displacement map.
 
Par contre pour le problème de la gestion des impacts c'est une *très* bonne question, et a mon avis le seul moyen c'est d'utiliser le displacement map avec des modélisations peu complexes mais non planes tout de même.

mareek a écrit a écrit :     OK, donc ceux qui nous annonçaient que le DM sevirait à faire des décors hyper réalistes rien qu'en utilisant les cartes IGN comme displacement map se sont fourré le doigt dans l'oeil jusqu'à l'épaule (n'est-ce pas marc ) ou nous on plus ou moins menti (c'est pas beau ça Mr Matrox).   Au final, si je comprends bien, le DM ne sera qu'un HOS qui regroupes les avantages de RT-patches de nvidia (grande flexibilité) et du truform d'ati (facile à programmer).

 
heu .. t'y est pas du tout. ni pour l'application des du dm, ni pour ce qu'est un hos. le DM s'appuye sur le truform pour augmenter la tesselation, ce n'est pas une tehcnique de hos et ça n'a rien avoir avec les rt-patch.

Marc a écrit a écrit :   Le reflief peut tout a fait être dessiné de A à Z via une displacement map.   Par contre pour le problème de la gestion des impacts c'est une *très* bonne question, et a mon avis le seul moyen c'est d'utiliser le displacement map avec des modélisations peu complexes mais non planes tout de même.

 
voila il y a une géométrie de base. le DM ne se substitue pas a la géométrie des paysages, elle en ajoute pour avoir du détails, c'est pas le DM qui va définir les grandes lignes
 
je crois avoir vu ça dans la démo flash de matrox sur leur site.

Non tu peut également utilisé le DM pour définir toute la géométrie. Mais dans ce cas pour la gestion des colisions & co ben euh =)

 
ça bien sur, mais c'est ridicule ... tu peux aussi rouler a 200 Km en prenant ton virage au feurouge, enfin tu peux essayer
 
je ne pense pas qu'un seul programmeur ait pensé a l'utiliser de cette manière en tout cas pour les grand terrain.
 
Il faut bien distinguer ce qui sera du domaine des petits détails sur une texture de mur par exemple et sur un terrain complet.
 
l'objectif du dm n''est pas de se substituer a la géométrie, mais de la complété, l'envisager autrement est suicidaire. sinon dans ce cas on défini une map Q3 avec 4 vertex et le dm fait tout le reste ? mon dieu j'ose même pas penser au résultat

Une simple illusion

Evildeus a écrit a écrit : Une simple illusion

 
Si tu penses au BM pour l'illusion, alors ce n'est pas comparable non plus car a partir du DM ont peut générer des ombres portées (par exemple) ce que le BM ne permet pas faire.

[jfdsdjhfuetppo]--Message édité par barbarella le 16-05-2002 à 13:00:07--[/jfdsdjhfuetppo]

ok,
 
le DM comme de très nombreuse tehcnologie, s'utilise dans un cadre définissant son utilisation. vouloir l'utiliser en dehors de son cadre amène a des aberrations.  
 
y a un parallèle en math avec l'analyse de fonction. bcp de fonction dans la pratique on un intervalle de validité. vouloir les utiliser en dehors de cette intervalle produit généralmeent des résultats débile et ridicule.
 
C'est pour ça qu'on fait tellement chier les lycéens et étudiant a bien précisier l'intervalle de définition . Le dm c'est la même chose, en dehors de son intervalle de fonctionnement, on ne sait pas trop ou on va et en général droit dans le mur

Il est intéressant de voir les deux possibilités du DM
 
La première pour créer des macro-détails. C'est à dire l'exemple du canyon de flight simulator, l' exemple de Matrox avec le modele générique de personnage qui grâce au DM permet de le diversifier en plusieurs modèles
 
La deuxième pour créer des micro-détails. Relief de la brique sur un mur. Bref redonner le relief des textures qui n'étaient juste là que illusoires.
 
Je pensais au début que le DM avait plutôt été crée pour la deuxième possiblité. Mais il y en a vraiment beaucoup plus !

barba-> je viens de relire ta def des HOS, j'avais effectivement mal compris, je croyais que ça regrouppait toutes les techniques qui permettaient d'augmenter la tesselation d'un modeèle 3D simple. Toutes mes excuses pour avoir dit n'importe quoi. J'attends ton futur article pour comprendre le fonctionnement du DM   .
 
Marc->Je trouvais bizarre que tu sois passé à coté du problème, donc je suis rassuré. Mais ton article ne parle pas de ce problème et c'est assez trompeur parce que l'intéret du DM est moindre qu'il n'y parrait au premier abord (même si ça reste tres novateur).

barbarella a écrit a écrit : ok,   le DM comme de très nombreuse tehcnologie, s'utilise dans un cadre définissant son utilisation. vouloir l'utiliser en dehors de son cadre amène a des aberrations.     y a un parallèle en math avec l'analyse de fonction. bcp de fonction dans la pratique on un intervalle de validité. vouloir les utiliser en dehors de cette intervalle produit généralmeent des résultats débile et ridicule.   C'est pour ça qu'on fait tellement chier les lycéens et étudiant a bien précisier l'intervalle de définition . Le dm c'est la même chose, en dehors de son intervalle de fonctionnement, on ne sait pas trop ou on va et en général droit dans le mur

Dans le Cadre du DM, l'intervalle de fonctionnement est tres limité, sous peine de problèmes.
 
Par exemple, si tu prends un plan et que y appliques le DM des Alpes, et que ton avis fonce dedans...ben en toute logique il ne devrait pas avoir de collision (d'ou illusion)

Le volume utilisé lors des calculs de collision n'est pas forcement celui occupé par les polygones qui sont affichés à l'écran, evildeus.

 
mon diablotin t'es en train de remettre en cause une fonction qui est utilisé sur les très gros logiciel 3D. Matrox n'a pas inventé le DM, mais la méthode permettant d'exploiter le DM dans des processeur grand public pour du calcul tps réel.
 
ben je te souhaite bien du plaisir dans ta croisade

barbarella a écrit a écrit :     mon diablotin t'es en train de remettre en cause une fonction qui est utilisé sur les très gros logiciel 3D. Matrox n'a pas inventé le DM, mais la méthode permettant d'exploiter le DM dans des processeur grand public pour du calcul tps réel.   ben je te souhaite bien du plaisir dans ta croisade

Je pars pas en croisade, mais je fais juste remarquer un point qui est valide. C'est d'ailleurs ce que fait remarquer Marc, et les différents fora que j'ai pu lire.

Faut aussi savoir que le DM nécessite un grand nombre de polygones. C'est un prb connu dans les moteurs de rendu 3D : appliquer une displacement map sur un objet peu détaillé donne un résultat aberrant. Or, les objets 3D peu détaillés, c'est le propre même des jeux video... J'ajoute qu'on peut effectivement obtenir une montagne à partir d'un plan, mais ce plan devra être constitué d'un gd nombre de polygones. Enfin, pour ce qui est des ajouts de détails comme pour une brique par exemple, c'est le rôle du bump mapping. Quel est donc l'intérêt du DM pour les jeux video dans l'immédiat?

Je tiens à contredire Xin. NON, le bump-mapping est une mauvaise technique qui ne donne que l'illusion du relief, et encore pas tout le temps.
 
Le displacement mapping, lui crée ce relief au lieu de le simuler. Il est évident que c'est mieux d'un point de vue visuel.
Dans le cas du mur de brique. Celui ou l'on applique le DM sera beaucoup mieux que celui ou l'on applique un simple BM.

 
Disons que le bump mapping est très suffisant dans le cas d'un mur de briques... En tout cas, c'est l'avis de pas mal d'infographistes, mais chacun son truc. Le plus gros prb dans ce que tu proposes c'est le coût en ressources systèmes (nb de poly élevé + DM) pour une différence quasi invisible. On n'a pas besoin de véritables ombres portées qd il s'agit de porosité de briques! Enfin, on s'éloigne un peu du sujet. Moi je pense qu'il est encore un peu tôt pour se lancer dans le DM dans les jeux (ou alors pour des cas très précis).

Xin a écrit a écrit :     Disons que le bump mapping est très suffisant dans le cas d'un mur de briques... En tout cas, c'est l'avis de pas mal d'infographistes, mais chacun son truc.

 
   
Le bump mapping n'est valable que si on regarde le mur de face ou avec un angle pas trop important, d'où l'intéret du DM.
 

 
T'as pas compris l'intéret du DM puisque dans le cas d'un mur de briques, où la gestion des colisions ne pose pas de problème, tu n'as besoins d'aucun poly supplémentaires, un plan tout bète suffit, donc aucune surcharge pour le proc vu que c'est le GPU qui se charge de tout.

Maintenant que j'y pense, est-ce que c'est inutile de cumuler Bump-mapping et DM ? Le bump-mapping servant à rajouter des micro-micro détails.
 
Par exemple, la balle de Golf, dont on rajoute le relief grâce au DM puis du bump-mapping léger pour simuler l'état de surface de la balle

 
ben elle est bien la balle de golf que montre matrox . tu voudrais voir les traces d'usure sur la balle ? heu ... faudra attendre un peu avant de gérer ça .
 
le plus gros problème c'est l'éclairage. plus tu veux du détails plus la méthode d'éclairage doit être sophistiqué, or sur ce sujet on est en retard.

La boule de golf a une surface lisse. Mais remplace le plastique par du liège par exemple, et garde le même relief qu'une boule de golf normale. C'est peut-être moins intensif niveau calculs de cumuler DM+BM que de tout faire avec du DM. Et le résultat pourrait être bon