Reprise du message précédent :

 
Dans half life 2 multijoueur,la majorité des  calculs physiques/Graphiques est effectué en local(SAUF certains cas : je balance une caisse ou un baril ou autre chose sur un joueur, dans ce cas c'est le serveur qui en calcule une partie mais ça n'empêche pas d'y jouer sur une connection ADSL classique ou même numéris !) et pourtant le moteur physique de HL2 tout comme Doom 3 est très avancé.
 
De plus,contrairement à Doom3 , le serveur central est toujours là !
En bref,pas de problèmes d'attente de joueurs,aucun problèmes pour re-rentrer dans la partie après un plantage...Bref encore un choix bizarre de la part d'ID Software...Des explications plus techniques seraient les bienvenues.

 
Faut croire qu'il y aura beaucoup plus de caisses et de barils dans Doom3 que dans HL2
 
Sinon, je ne savais pas que tu avais participé au developement du moteur réseau de HL2 pour être si bien au courant. Ou alors le code source est dispo quelque part ?

 
 
Bah nan suffit de s'informer  
y a une grosse faq disponible faite à partir de plusieurs réponses réçues de la part d'un des developpeurs de HL2
 
Juste un petit extrait  

 
j'ai un 56k faut que je tape vite!

 
tout est en temp réel, que ce soit doom3 ou HF2! d'ailleurs Carmack a développpé les physiques pour les vehicules dans quake4!

 
t'as qu'a lire le prmier post!
"Si cette méthode pouvait supporter jusqu'à 1024 entités, Doom III en gère un nombre beaucoup plus élevé, avec l'introduction de nouveaux effets visuels comme les fameuses animations "Blended Skeletal" !  "
 
et si t'as souvent des problèmes de plantage on peut rien y faire!

 
le bump animé peu jouer sur le code réseau s'il est lié a une animation ou une action par exemple! nan?
 
il y a aussi quand tu shoot un enemi, c'est pas une simple texture blessure qui s'affiche, c'est carrement une deformation de polygon, un vrai trou modélisé quoi!!! gérer de manière réaliste et là on rajoute encore par dessus une texture en bump!plus la gestion du sang qui tombe par terre... et si le monstre marche deand il fait des traces!
 
et en plus la blessure agit sur les bones de l'ennemi qui se déplace en fonction de sa blessure!!!
 

Toutes les actions que tu es en train de décrire sont effectuées en local !! Quand tu shoot un gars ,le trou est modelisé en temps-réel et c'est pareil que si tu affichais simplement une tâche de sang ,c'est l'ordi qui calcule quoi En gros,on envoit simplement aux autres ordis une information qui dit "je tire sur machin , afficher la blessure" et ce genre d'infos ça prends rien du tout en bande passante,peut être une vingtaine d'octets/s
 
Ce nouveau mode réseau c'est sûrement pas pour une histoire d'effets visuels,c'est quelque chose d'autre qu'on ne sait pas pour le moment ...

 
Parfaitement d'accord... Webdwarf, je me demande d'où tu sors toutes ces informations sur le déplacement des "bones" sur les impacts et le rapport que cela devrait avoir sur le net code...
 
J'ai vraiment l'impression qu'ici il y a des gens qui affabulent un max.

 
C'es bien ce que je pensais : tous les calculs de physique qui influent sur le gameplay seront fait au niveau serveur. Il faut croire qu'ils sont beaucoup plus nombreux dans Doom 3 que dans HL2.
 
En prenant exemple sur la déformation des monstres sous les balles. Cela n'a peut-être pas trop d'influence sur le gameplay, mais on n'aimerais bien que tous les joueurs voient les déformations et non pas seulement le joueur qui a tiré. Cela suppose donc que tous les joueurs dans tout le niveau calculent en même temps ces déformations, ou alors que le serveur les calcule puis les transmet aux joueurs au moment ou ces informations sont importantes pour lui. Cependant, le deuxième cas n'est pas vraiment possible à cause de la masse d'information à transmettre. Vous imaginez pas un moteur réseau dans lequel le serveur doit envoyer 100 ko de données à un joueur à chaque fois qu'il rentre dans une zone avec un monstre criblé de balles.
 
Ce problème est exactement le même pour les calculs de physique complexes qui influent sur le gameplay. Imaginez un joueur qui explose un mur avec une centaine de débris qui volent, chacun pouvant potentiellement aller influer sur d'autres objets derrière le mur. Ce genre de chose n'est tout simplement pas fesable en réseau avec une archi client/serveur.

yaura un mod Multi Coop ou pas ?

prkoi y en a qui parle de H F 2
je connais HL2 et Doom3 mais HF 2 c quoi ?

 
ya des dyslexiques ici ?!?

 
un multi c'est sûr et plus de 4 joueurs, c'est juste la map de demo qui était limité à 4, coop c'est pas sûr!

en principe, pas de coop
mais on pourra peut-être voir un mod coop amateur

UN truc que je comprend pas chez les developeurs c'est qu'ils font JAMAIS de modes coopératifs, et pourtant c'est le genre de trucs qui me feraient trop plaisir, imaginez un mod coopératif à MEdal of Honor, à 3  ca serait vraiment trop bon, pareil pour HL2, Doom 3, mais non ils pensent qu'à faire des trucs multis qui se jouent à minimum 10 , mais bon moa j'ai pas svt l'occaz de faire des gros rézo , moa c maxi 4 , et du deathmatch à 4 c'est bof bof

ce que je dis sur les tirs c'est l'interview des joueurs ayant testé lemode multi jouers à la quakecon
 
ce que j'ai lu sur la supériorité technique du moteur de doom3:
 
 
"Que peut on retenir de cette première présentation de la technologie de Doom III ? Essentiellement le travail impressionnant effectué au niveau de l'éclairage : d'un point de vue local tout d'abord avec enfin une utilisation sérieuse de l'éclairage au pixel près (per pixel lighting), enfin d'un point de vue global avec des ombres impressionnantes. Tout ceci résulte en fait d'une nouvelle approche de John Carmack dans la conception de son moteur : l'unification du modèle d'éclairage. Qu'est ce qu'on entend par ce terme un peu pompeux ? Pour bien comprendre la différence de Doom III à ce niveau il faut tout d'abord s'intéresser au fonctionnement de l'éclairage dans les précédents moteurs 3D.
 
 
 
Jusqu'à présent les moteurs 3D faisaient une distinction entre deux types d'éclairage : l'éclairage statique des décors et l'éclairage "dynamique" des modèles. L'éclairage statique est constitué de lightmaps, de simples textures en niveaux de gris permettant de spécifier les régions lumineuses (blanc) des régions sombres (noire), ces lightmaps sont générées par un outil (utilisant l'algorithme de radiosité pour Quake 2 et 3) puis stockées dans la définition du niveau. Cette technique permet d'avoir un éclairage extrêmement réaliste (car précalculé, le temps de génération des lightmaps n'étant donc pas un problème) et peu coûteux car il ne s'agit que d'une combinaison de textures à l'exécution. En revanche elle a un gros défaut : son inflexibilité : les informations d'éclairage étant stockées dans la définition du niveau elles en sont indissociables, l'éclairage est fixé une fois pour toute lors de la création de la map et ne peut plus ensuite être modifié à l'exécution. Les modèles pour leur part utilisent un simple Gouraud Shading calculé par vertex. Ce genre de distinction génère plusieurs problèmes : tout d'abord une différence évidente de qualité entre les deux types d'éclairage, d'autre part l'éclairage statique repose sur des calculs de visibilité pour savoir quelles régions vont être influencées, et ces calculs peuvent être pris à défaut par les éléments amovibles du décor générant des problèmes d'éclairage au niveau des portes notamment. Bref tout ceci reposait sur des astuces pour tromper l'oeil et demandait à être très finement défini pour obtenir de bons résultats.  
 
 
 
Avec Doom3 désormais toutes les lumières sont traitées de la même façon, la calcul de l'éclairage a été entièrement supprimé de l'éditeur de niveaux et sera effectué en temps réel et le décor tout comme les modèles seront éclairés au pixel près, ajoutez à cela une gestion des ombres dynamiques et vous comprendrez l'étendu du travail réalisé par John Carmack. Après cette présentation ID Software se remit en mode black out pendant un certain temps, ne distribuant qu'au compte gouttes quelques screenshots savamment choisis. Il faudra attendre l'E3 2002 pour revoir Doom III, et encore il ne sera présenté que dans une pièce privée avec interdiction de prendre des photos ou de filmer l'écran"
 
 
 
Cette méthode de calcul des ombres est certes très impressionnante mais elle présente quand même plusieurs défauts que certains jugent particulièrement gênants. D?une part elle ne permet pas de produire ce que l?on appelle des ombres douces c'est-à-dire des ombres dont le contour est diffus. Les ombres de Doom III sont très nettes et accentuent en partie le deuxième défaut : un nombre de polygones utilisés pour les personnages relativement peu élevé, défaut qui n?a de cesse d?être pointé du doigt à chaque nouvelle fournée de screenshots.  
Il faut savoir à ce propos que les personnages utilisent entre 2000 et 6000 polygones ce qui reste très raisonnable, augmenter le nombre de polygones de nos jours n?est plus vraiment un problème : les processeurs graphiques disposent de suffisamment de ressources au niveau de la partie T&L pour traiter un très grand nombre de sommet alors pourquoi un programmeur de génie comme John Carmack est-il obligé de se limiter à ce niveau ? Tout simplement à cause de l?algorithme expliqué ci-dessus : augmenter le nombre de polygones du modèle n?est certes pas un problème mais ce n?est que la face cachée de l?iceberg : une telle augmentation complexifiera énormément la calcul de la silhouette en augmentant le nombre d?arêtes à examiner pour la déterminer et il ne faut pas perdre de vue que ce calcul est effectué par le CPU ! Et qui dit plus d?arêtes dans la silhouette dit aussi plus de fill rate consommé lors du rendu des volumes d?ombre. Bref cette amélioration a priori triviale a des conséquences bien plus importantes qu?il n?y paraît au premier abord sur les performances et il est évident que Carmack a étudié tout ça de près pour trouver le meilleur compromis.  
 
 
 
Une fois que la normal map est appliquée à un objet ces vecteurs sont "collés" sur l'objet texturé mais à ce moment à chaque sommet les vecteurs u,v et w pointent dans des directions complètement différentes. Pour pouvoir effectuer des calculs au pixel près il faut donc transformer l'inverse du vecteur lumière dans cet espace tangent (qui je le répète est propre à chaque sommet !). La technique consiste donc à calculer pour chaque sommet l'espace tangent puis à y exprimer l'inverse du vecteur lumière (ceci peut être effectuée dans un vertex program pour décharger le CPU) puis à appliquer pour chaque fragment le calcul d'éclairage souhaité (en utilisant les Registers Combiners ou un fragment program).  
 
 
 
A propos de la normal map, Doom III utilise une nouvelle technique de génération qui va sans aucun doute se démocratiser (déjà le moteur de Halo 2 sur Xbox, et le Crytek Engine présente des techniques similaires). Initialement les normal map étaient créées par les graphistes à l?aide d?outils spécifiques (généralement un plug-in Photoshop qui permettait de convertir l?image crée par le graphiste au format convenable). Doom III pour sa part exporte les normales directement depuis l?outil de modélisation. En clair les graphistes réalisent une version extrêmement détaillée du modèle (entre 800 000 et 1 millions de polygones) à partir de laquelle sera générée la normal map. Cette normal map appliquée sur un modèle simplifié permettra de faire illusion, exceptés sur les contours bien sûr qui par conséquents conservent leur aspect anguleux.  
L?image suivante montre cette technique en action :  
 

 
 
En haut le modèle utilise une normal map, en bas il se contente d?une normale par sommet. Si lorsque le nombre de triangles est extrêmement élevé la différence est invisible elle saute aux yeux dés que la tesselation diminue. Même lorsqu?on descend en dessous des mille triangles, le modèle utilisant la normal map continue de faire illusion. ATI offre sur son site un plug-in Maya permettant d?exporter les normales d?un modèle dans une normal map ce qui devrait accélérer l?adoption de cette technique.  
 
 
... S'il est une partie de ce nouveau moteur 3D à avoir bénéficié de toutes les attentions de la part de John Carmack c'est le Renderer. Qu'est ce que le Renderer ? Expliqué simplement le Renderer contrôle tout ce qui est affiché à l'écran, en fait plus exactement le Renderer contrôle tout ce qui a une influence sur le rendu à l'écran : une lumière par exemple n'est pas affichée directement mais va influencer la façon dont sont rendus les autres éléments. Le Renderer de Doom III est codé en OpenGL et il en existe différentes versions adaptées aux capacitées des diverses cartes 3D.  
 
 
 
ces screen date de plus d'an et demi, sur les toutes premières
 version du moteur
 

tu vois chagarou sur la petite vignette que les extérieur sont bien gérer, c'est normal puisqu'il y a aucune différence technique entre un extérieur et un intérieur, ce sont des extérieurs qui se passe sur mars.
 
Edit de Prodigy : j'ai viré les images, passke la lourdeur pour charger la page, même sur une 1mb, merci bien. Les images on les connaît, et y'a un topic officiel sinon

le pauvre gars
il a un gros pif
tellement gros qu'il projette une stencil shadow
 

Moi je dis, si tout ce qui était transmis au serveur c'était simplement les pressions sur les touches haut, bas, gauche, droite, tir et saut, y'aurait plus de pb de saturation . A partir de là, chaque client peut recalculer localement les effets de chacune de ces actions. T con John Carmack, t con

 
je pense qu'il y a pensé, sisi je t'assure  

 
Maintenant il va mettre en application . Plus que six mois John

 
C'est marrant, c'est exactement le principe du moteur réseau de Doom 3 ça. Comment tu as fait pour trouver ?
 
PS : cette techno permet justement d'avoir un monde très très complexe sans saturer le serveur, mais comme le monde est si complèxe, il n'est pas possible de permetre à un joueur de se connecter en cours de partie car il aurait sans doute plusieurs Mo de données à télécharger du serveur pour obtenir l'état courrant du jeu.

 
Il n'était pas seul
 
Et sans Carmack (Adrian) ou McGee ou Tom Hall ou Romero, ou Sandy Peterson, qui sont loins d'êtres des lopettes, on se demande ce que Doom aurait pu donner, hein
 
Cette idôlatrie du père Carmack, c sympa, mais ça lourde. Il était pas seul sur Doom & Quake, et la preuve qu'un bon moteur ne fait pas tout, personne n'ira dire que leurs récents jeux sont à la hauteur de ces deux "légendes". Donc bon
 
Prodigy

 
Ca a été annoncé par id. Bref, de toutes façons, comme 99% de ce que tu racontes c'est du n'importe quoi matiné d'approximations, je m'énerve même plus
 
Prodigy

 
  Erreur, c'est effectivement le cas des moteurs 3d actuels, mais celui de doom3. Sinon, on ne viendrait pas me parler de probleme de saturation du serveur causés par le système de squelette ou de je ne sais quoi venant du moteur physique. C'est bien la preuve que le netcode de Doom3 gère des données superflues. Je ne dis pas que j'ai la solution à ces problèmes, je dis que Carmack aurait pu réfléchir avant de se lancer dans la conception d'un moteur de jeu si complexe .

 
Bah, tu as un cadavre par terre. Celui-ci est composé de 200 bones. Il faut bien que le serveur envoye aux clients la position de ce corps. A raison de 4 paquets de 3 flottant pour décrire chaque bone, cela nous donne 48 octet par bone soit un total de plus de 9ko de données. Ceci pour chaque cadavre qui traine par terre. Cela fait beaucoup quand même.

 
A cette allure, ma TNT suffit pour jouer sur un serveur qui me serrvira de carte graphique

 
Combien de bande passante consomme un jeu réseau recent ? Dans les 8-9 ko/s on va dire. Donc il faudra 1 seconde pour que le serveur transmette les info. C'est énorme surtout en considerant qu'il ne peut rien transmettre d'autre pendant ce temps.

 
Tu peux traduire stp, je ne comprends pas .

 
On va dire qu'un jeu réseau actuel coute au serveur dans les 8-9 ko/s de bande passante en upload pour chaque client.
 
On part du principe que les clients n'ont pas besoin de connaitre parfaitement l'ensemble du terrain de jeu au cours de la partie. Le contraire nous donne le code réseau de Doom 3. Cela veux donc dire que quand un cadavre devient pertinent pour le joueur A, le serveur doit lu envoyer les info correspondantes. Chose qui lui prendra 1 seconde et qui paralysera tout autre transfert vers ce joueur.

 
tu as du mal traduire en français l'article " c'est clairement dis que le nombre de quatre joueurs a été définie par rapport à la complexité de la map de demo. mais le moteur de doom n'est pas limité à 4. c'est d'ailleurs le moteur du prochain quake4 donc réflechit 2s.
et je ne raconte pas n'importe quoi j'essaye même d'expliquer au maximum les trucs en utilisant pas de terme trop technique, si tu comprend pas un point de ce que je dis tu demande et j'essaye de mieux epliquer.

un copier-coller de l'annonce de iD sur la limite de joueurs?
 
 
ils ont toujours dit "number of players is scalable"

 
 
et quake IV sera 1 jeu solo... donc rien a voir

 
Sur quoi tu te bases pour sortir un temps, comme ca? Et je ne vois toujours pas où tu veux en venir. "Oui, et alors?" si tu préfères.

 
Je me base sur la division euclidienne. On la voit encore a l'école primaire non ?
 
Alors attention : "9 ko" de données pour décrire un cadavre. "9 ko/s" de bande passante. "9 / 9 = 1 s" de tranfert ! Magique

En quoi supprimer le serveur central diminuera les échanges réseaux?
Concrètement , sur une partie 4 joueurs, chaque joueur devra envoyer ses informations aux trois autres joueurs(y a plus aucun serveur central non?)et si par exemple il doit envoyer la position des bones de son personnage, il devra l'envoyer 3 fois par seconde , donc 3*9=27 ko/s ... il échangera donc encore plus d'infos qu'avec un serveur central...y a un hic où alors j'ai rien capté au principe.

 
C'est parceque chaque ordi simule les opérations des autres joueurs. En gros les joueurs envoyent aux autres joueurs leur evenements claviers/souris et rien d'autre. Libre à chaque ordi de calculer les déformations des bones des autres joueurs.

 
Donc en bref ,la chute d'un personnage dans un escalier ne sera pas du tout pareille sur les 4 ordinateurs ,de même pour tout autres simulations physiques, ok ?
Alors il est évident que ca diminue fortement le traffic réseau ! Mais à ce moment là , POURQUOI NE PLUS UTILISER UN SERVEUR CENTRAL?

 
      c'est lié à des règles mathématiques trés précise! c'est exactement pareil sur n'importe quel pc!

c'est incroyable le nombre de connerie qu'on peut lire ici!

 
bah si, c'est un jeu solo