Futur de LOckON ?

[drafak]

Ne raconte pas non plus n'importe quoi

Les pixel shader et vertex shader c'est introduit à partir de DX 8, oui.

DX 9 apporte plus d'instructions, oui, mais c'est pas dX9 lui même qui a amené le parallax mapping. Ya pas une fonction toute faite "ajouter du parallax mapping".

nan ,c est pas DX9 qui apporte ca. DX9 n'est la que pour faire le liens soft > hard. le fait que le GPU puisse tenir 4 texture par passe permet de supperposé toussa . mais faut bien une API pour appelé cette gestion.

la tu racontes encore plus n'importe quoi ]

connaissant un peu major , je pense qu'il le sait mais il l'a mal exprimé.
la qualité visuelle finale "equivaut" au meme perso composé de 200K polygons.

Le moteur de lockon a tout pour mettre du bump et du normal mapping, la preuve la plus simple c'est la flotte: elle est bump mappée.

clair. mais bon , a la limite, le bumpmap on s'en tappe <_<.
plutot faire de l'instancing geometrique pour pas qu'on rame horriblement aus dessus des villes (meme avec un CPU overclocké comme pas possible .)

Les nuages 3D (autant les simples, que les overcasts) sont une autre preuve que le moteur est bien DX9.

bien la preuve qu'ils n'en ont rien a fouttre de l'avis des joueurs.

Confonds pas tout. la question du graphisme, ca fait depuis belle lurette que c'est plus le CPU qui s'en charge, et c'est comme ça dans lockon.
Le problème c'est surtout leurs modèles de vols, leur IA, leur code de l'electronique, qui sont beaucoup trop gourmands en resources.

moi je dis foutaise :-O

ctrl + delete et tu matte les stat de rendering. quand tu saccade , c est pas ca la cause.

c est les objets terrestre affiché qui fouttent tout en l'air. des que tu depasse 5K object , t'es deja dans le rouge.

le geometry instancing permettrait de remedier a ca il me semble non ?
j'avais une demo DX9 demontrant l 'interet de l 'instancing.

tu pouvait multiplier par 3 le nombre d'object pour un meme framerate.
5K -> 15k , putain , ce serais vraiment joussif pour tout le monde

[eutoposWildcat]

C'est quoi le geometry instancing?:)

[Azrayen]

Ben alors Cartman, tu as mal dormi ? J e te trouve un poil sec avec Major.

Pour info :

Confonds pas tout. la question du graphisme, ca fait depuis belle lurette que c'est plus le CPU qui s'en charge, et c'est comme ça dans lockon.
Le problème c'est surtout leurs modèles de vols, leur IA, leur code de l'electronique, qui sont beaucoup trop gourmands en resources.

On a (moi en tout cas) toujours entendu dire que LO tirait plus sur le CPU que sur la CG à cause de son moteur graphique old fashion.
Or c'est un fait que la toute dernière CG ne transcende pas LO, alors qu'un bon gros CPU permet d'améliorer pas mal de choses...
D'où je pense les infos de MB

Az'

[drafak]

C'est quoi le geometry instancing?:)

ca permet d'utiliser un meme model geometrique , et d'en faire plusieur object distinct. plutot que de geré autant de model que d'object.

certes, yaurait besoin d'avoir plusieur model (maison, entrepot, grue toutssa) mais on aurait quant meme un gain appreicable je pense

[eutoposWildcat]

Ca pourrait vouloir dire, en quelque sorte, utiliser des modèles géométriques un peu comme des briques de lego pour construire des objets, de sorte qu'on a quantité d'objets avec un nombre réduit de briques?

[Cartman]

edit: désolé pour major, me suis emporté, je vais editer mes messages precedents.

Le geometry instancing ca permet de résoudre ca oui, je le sais , je suis en train d'implementer du geometry instancing dans un moteur open source ( http://www.ogre3d.org/phpBB2/viewtopic.php?t=20193
crashy c'est moi, screenshots plus loin dans le topic).
Ca permet de foutre toute la geometrie dans un buffer qui est dans la ram graphique, plutot qu'en memoire centrale et d'eviter des transferts entre ram et vram.
Mais attention, c'est à utiliser avec parcimonie, a plus de 1.2 millions de polys c'est meme pas la peine d'y songer

nan ,c est pas DX9 qui apporte ca. DX9 n'est la que pour faire le liens soft > hard. le fait que le GPU puisse tenir 4 texture par passe permet de supperposé toussa . mais faut bien une API pour appelé cette gestion.

DX permet un standard. L'API dispose de fonctions, necessitant certaines capacités hardware. Quand je dis que DX9 impose un plus grand nombre d'instructions, c'est pas moi qui le dit, c'est la msdn microsoft dans les specifications HLSL.
Les vertex Shader HLSL 2.0, c'est 256 float4, je sais plus combien d'instructions, etc.

Donc c'est bien l'api qui fixe des standars auxquels doivent répondre les cartes graphiques .

(Ce qui n'est pas le cas pour le HDR parcequ'il n'est pas standardisé)

ctrl + delete et tu matte les stat de rendering. quand tu saccade , c est pas ca la cause.

Je dirais qu'il ya des 2. Le cpu rame parceque les modeles de vol et tout ca sont mal optimisés, et la partie graphique rame aussi, parceque voila, il ya beaucoup trop de choses.

[drafak]

[quote="Azrayen"]Ben alors Cartman, tu as mal dormi ? J e te trouve un poil sec avec Major.

Pour info :



On a (moi en tout cas) toujours entendu dire que LO tirait plus sur le CPU que sur la CG à cause de son moteur graphique old fashion.
Or c'est un fait que la toute dernière CG ne transcende pas LO, alors qu'un bon gros CPU permet d'améliorer pas mal de choses...
D'où je pense les infos de MB ]

il suffit qu'UN SEUL FACTEUR DEPENDANT DU CPU ne soit pas traité assez rapidement pour que les FPS s'effondre.

ce facteur peux ne representé que 1/1000eme du code , il n'empeche qu'il peut s'averer etre a lui tout seul LE GOULO d'etranglement.

[Cartman]

Voila, pour ceux que ca interesse:
http://developer.nvidia.com/object/perf ... _date.html
pleins de papiers sur l'optimisation d'un moteur graphique, méthodes de dénichage des goulots d'etranglement.
Faudrait l'envoyer à ED, c'est tout

[drafak]

Je dirais qu'il ya des 2. Le cpu rame parceque les modeles de vol et tout ca sont mal optimisés, et la partie graphique rame aussi, parceque voila, il ya beaucoup trop de choses.

et bien perso , j'ai un avis different. car mon jeux de rame pas si je suis en scene "medium" . sauf peut etre avec 8 su25T au taxiway. (faudrais LODé mieux que ca :p)

si je pense en scene high , tout s'effondre pour rester jouable 70% du temps , et injouable (10 13fps ) les 30% du temps restant. lors des attaques de villes surtout.

pour moi c est clair: c est la gestion des object terrestre qui nous met dedans

[Cartman]

(faudrais LODé mieux que ca :p)

OUlah malheureux! Le LOD c'est presque has been. Avec un modèle a 50 000 polys , faire des lods c'est catastrophique pour l'espace occupé en mémoire! Le gain est largement inférieur aux pertes.

Moi je pense qu'il ya combinaison des deux: code pas propre et pas optimisé du tout, et gestion des objets à l'ancienne, pas cool non plus vu le nombre de polygones mis en jeux dans l'histoire.

Mais initiallement ce que je disais c'est que c'est pas les graphs eux meme qui font ramer le cpu,et encore moins le fait que le moteur soit dx7(ce qui n'est pas le cas) c'est une mauvaise gestion des objets qui colle des perfs de merde.

[KoV]

Sachant que LoMac et une évolution de Flanker2, je soupsonne qu'il n'y ai pas une gestion des threads, et sur un proc actuel ca la fout mal.

Sinon pour la concurrence, pour l'instant je vois pas qui pourrait détroner LockOn au niveau sensations de vol. Peut etre ca va venir ... dans 1 an ? 2 ans ? mais d'ici là on verra pointer "LockOn2" enf in j'espère.

Au niveau des modeles 3D la communauté se pleint de la qualité de certains modèles, donc il n'y a rien de mauvais à ce qu'on lui prop)ose de participer.

[drafak]

mattez ca !

http://www.fl-tw.com/Infinity/Docs/Demo ... p_1000.avi


1000 vaisseaux. c'est de l'OpenGL

[Cartman]

matte ca:
http://crashy.cartman.free.fr/SOC/bbox.JPG

200 ninjas! et je suis allé jusqu'a 800 à 50 fps, le tout entierment pixel shadé.
Le meme nombre de persos sans instancing, tu fais 5 fps maxi.

Sachant que LoMac et une évolution de Flanker2, je soupsonne qu'il n'y ai pas une gestion des threads, et sur un proc actuel ca la fout mal.

Le multithreading c'est encore quelque chose de compliqué, surtout sur windows(sous linux, c'est finger in the nose). Et faut savoir comment threader, ce qui est pas evident du tout.

[drafak]

je m'absente je reviens debattre dans 1 H B-)

[MajorBug]

Le moteur de lockon a tout pour mettre du bump et du normal mapping, la preuve la plus simple c'est la flotte: elle est bump mappée.

A ma connaissance le bump mapping date de DX7 et le normal mapping a été introduit dans DX9. Quant à l'eau c'est plutot du pixel shader et pas du bump mapping, puisqu'elle n'est pas affichable sur une GF4 MX (qui ne gère pas les pixel shaders, mais parfaitement bien le bump mapping)

Ensuite pour le modèle de UT2004, il a effectivement un rendu équivalent à 200 000 polygones dans la mesure où le normal mapping permet d'ajouter du relief sur des surfaces planes, mais il est aussi lourd à afficher que le modèle de base à 7000 (puisque le moteur est DX9, normal mapping -> GPU). Dans Lock On un modèle à 30 000 polys ça rend comme un modèle à 30 000 polys, point barre, c'est lourd et comme leur moteur n'est pas totalement DX9 (j'ai même l'impression qu'il ne l'est pas du tout, mais bref), ils ont aucun moyen de l'améliorer sauf en réecrivant tout.

Dailleurs si leur moteur est totalement DX9, optimisé et tout, tu m'expliques pourquoi ils ont fait du nouveau moteur graphique DX9/10 une priorité pour LO2 ? Ca marche si bien après tout, c'est quand même bizarre ...

Confonds pas tout. la question du graphisme, ca fait depuis belle lurette que c'est plus le CPU qui s'en charge, et c'est comme ça dans lockon.
Le problème c'est surtout leurs modèles de vols, leur IA, leur code de l'electronique, qui sont beaucoup trop gourmands en resources.

Edité : c'est "plus" le CPU qui s'en charge, j'avais pas vu le "plus" autant pour moi.

Si tu regardes de près, dans LO c'est le son qui bouffe le plus de ressources. La plupart des saccades apparaissent quand tu te trouves dans la "bulle sonore" de beaucoup d'appareils. Ca ne poserait aucun souci si le GPU allegeait la charge du CPU, avec un moteur réellement DX9 ça serait possible, mais c'est pas le cas.



Maintenant merci d'éviter de me rentrer dans la gueule, j'essaye de rester aimable mais on a pas gardé les cochons ensembles ...

[KoV]

La gestion des threads est un chose qui se réflechit en amont ça s'est sur et qui implique du savoir faire dans la conception.
Je sais pas comment ca se passe sous windows, connait que Linux ou Java ...

[berkoutskaia]

Ca pourrait vouloir dire, en quelque sorte, utiliser des modèles géométriques un peu comme des briques de lego pour construire des objets, de sorte qu'on a quantité d'objets avec un nombre réduit de briques?

Je pense qu'il s'agit plutôt d'appeler dans la memoire les 10-15 types de batiments qui existent, et de construire la ville à partir de ces 10-15 modèles, plutot que d'appeler un modèle pour chaque batiment distincts. Un expert pour confirmer

[Cartman]

A ma connaissance le bump mapping date de DX7 et le normal mapping a été introduit dans DX9. Quant à l'eau c'est plutot du pixel shader et pas du bump mapping, puisqu'elle n'est pas affichable sur une GF4 MX (qui ne gère pas les pixel shaders, mais parfaitement bien le bump mapping)

Non non et non!

Le pixel shader c'est un programme!
Dans ce programme tu fais ce que tu veux, notemment du bump mapping.
Le bump mapping EST un pixel shader.

Il ya bien eu des effets de bump en DX7, mais c'etait pas standard, c'etait introduit comme des fonctions hardware pas modulables. C'est mort, plus aucune carte n'a de fonctions integrées faisant du bump. Maintenant tout est fait dans le pixel shader.

Dans Lock On un modèle à 30 000 polys ça rend comme un modèle à 30 000 polys, point barre, c'est lourd et comme leur moteur n'est pas totalement DX9 (j'ai même l'impression qu'il ne l'est pas du tout, mais bref), ils ont aucun moyen de l'améliorer sauf en réecrivant tout.

C'est pas parceque le renderer c'est du dx9 que ca va aller plus vite.
Le normal mapping c'est beau mais ca affine pas les angles. Hors un avion, ca n'a pas de plis de vetements, de rides, et ce genre de trucs. Juste des rivets. C'est la seule chose qu'on peut foutre en bump sur un avion, les rivets(voir les screens de FSX).
Donc pour avoir un avion avec des jolis angles, DX9 ou pas, la seule solution c'est d'ajouter des polygones, point barre. Le normal mapping viendra pas sauver ca.

Ce qui changera, ca sera le per pixel displacement mapping, qui pour le moment tourne à 0.5 FPS dans une scene avec un seul objet.

Si tu regardes de près, dans LO c'est le son qui bouffe le plus de ressources. La plupart des saccades apparaissent quand tu te trouves dans la "bulle sonore" de beaucoup d'appareils. Ca ne poserait aucun souci si le GPU allegeait la charge du CPU, avec un moteur réellement DX9 ça serait possible, mais c'est pas le cas.

Le son donc c'est bien ce que je disais au début concernant l'occupation cpu: ce qui fait ramer, c'est pas les graphismes , vu qu'ils ne sont pas pris en compte par le cpu, mais le CPU("Le problème c'est surtout leurs modèles de vols, leur IA, leur code de l'electronique, qui sont beaucoup trop gourmands en resources.")

Mais la partie graphique est aussi très mal optimisée, et il ya beaucoup trop de polygones

[Cartman]

Ah et pour ajouter un truc:
Bump mapping = normal mapping.

Le code du shader est identique, c'est la texture utilisée qui a un sens different.

[MajorBug]

("Le problème c'est surtout leurs modèles de vols, leur IA, leur code de l'electronique, qui sont beaucoup trop gourmands en resources.")

Tu constateras le même gain de perf sur un CPU supérieur en lançant une mission vide. Pas d'IA, pas de modèle de vol, pas d'électronique, et pourtant le résultat est le même : CG supérieure, pas de changement, CPU supérieur, gros changement, même avec uniquement du graphisme à calculer.

Il ya bien eu des effets de bump en DX7, mais c'etait pas standard, c'etait introduit comme des fonctions hardware pas modulables. C'est mort, plus aucune carte n'a de fonctions integrées faisant du bump. Maintenant tout est fait dans le pixel shader.

On est bien d'accord, si on parle de bump mapping on parle de moteurs DX7 ...

Le pixel shader c'est un programme!

J'ai beaucoup de mal à intégrer ça, dans la mesure où un moteur non DX9 ne permettra pas d'afficher du pixel shader 3.0, si c'était juste un programme à greffer sur ton code ça marcherait sous tous les types de moteurs non ?

(Mais sinon je sais bien qu'un pixel shader se programme oui, dailleurs sous Unreal Engine 3 on va bien se marrer avec)

Mais la partie graphique est aussi très mal optimisée, et il ya beaucoup trop de polygones

Moins que chez une bonne partie de la concurrence, donc la charge en polygones c'est surement pas une bonne excuses

[Cartman]

On est bien d'accord, si on parle de bump mapping on parle de moteurs DX7 ...

Non parceque le bump de l'epoque dx 7 n'etait pas un standard DX7, c'etait une fonction à part dirai-je.

Aujourd'hui: bump mapping = normal mapping. C'est pas plus compliqué que ca

J'ai beaucoup de mal à intégrer ça, dans la mesure où un moteur non DX9 ne permettra pas d'afficher du pixel shader 3.0, si c'était juste un programme à greffer sur ton code ça marcherait sous tous les types de moteurs non ?

Et bien en fait les vertex/pixel shader sont des programmes envoyés à la carte graphique, et qui modifient les caracteristiques des vertices/pixels au moment de la rasterization(au moment du rendu).

Mais pour envoyer ces programmes à la carte graphique il faut des fonctions. Ces fonctions sont fournies par DX8, puis DX9, mais n'existaient pas avant.

Moins que chez une bonne partie de la concurrence, donc la charge en polygones c'est surement pas une bonne excuses

Mauvaise optimisation du traitement des polygones, pas assez de masquage des faces cachées, pas assez de compression, plein de choses peuvent expliquer que la partie graphiuqe de lockon rame plus que d'autres pour un même nombre de polygones.

Il faut aussi prendre en compte les effets divers: les nuages 3D ca bouffe un max, pareil pour les rayures sur la verrière(qui au passage, est un bump/normal mapping tout con)

Bon je peux expliquer plus précisemment la difference d'utilisation entre le bump et le normal mapping, d'ou leurs noms differents, mais bien comprendre que c'est le meme pixel shader et le meme effet graphique.

En fait c'est assez simple. Le bump mapping c'est pour simuler du volume sur une surface avec une texture qui se répète. Par exemple un mur de briques, on fait une normal map pour les briques, et hop, on a l'impression que c'est en volume.

Le normal mapping c'est exactement pareil, mais la texture ne se répète pas. C'est le cas pour un personnage, ou on represente les muscles ou les plis de vetement avec la normal map.


Le Parallax c'est encore different, on ajoute a la normal map une texture (souvent stockée dans la couche alpha) en noir et blanc permettant d'ajouter des informations de hauteur en plus des normales. Ce qui donne un très bon effet au final.

[MajorBug]

Merci pour les explications au début, la fin je connaissais déjà, mais je maintiens quand meme ceci :

Tu constateras le même gain de perf sur un CPU supérieur en lançant une mission vide. Pas d'IA, pas de modèle de vol, pas d'électronique, et pourtant le résultat est le même : CG supérieure, pas de changement, CPU supérieur, gros changement, même avec uniquement du graphisme à calculer.

Dans l'absolu ça ne veut pas dire pour autant que le GPU ne fout rien, il y a peut-être un goulot d'étranglement comme vous dites qui apparait même sur une mission vide. Mais si le graphisme est rendu uniquement par le GPU, ça veut dire qu'il est vraiment très bien optimisé vu que le passage à une carte plus puissante ne change quasiment pas les performances

[Cartman]

Dans l'absolu ça ne veut pas dire pour autant que le GPU ne fout rien, il y a peut-être un goulot d'étranglement comme vous dites qui apparait même sur une mission vide. Mais si le graphisme est rendu uniquement par le GPU, ça veut dire qu'il est vraiment très bien optimisé vu que le passage à une carte plus puissante ne change quasiment pas les performances

C'est simple: quand il n'y a pas grand chose à rendre, une carte graphique plus grosse ne changera rien, vu que deja celle d'avant n'etait pas utilisée à fond.

Pour lockon je pense que c'est surtout un probleme de mémoire video. Textures trop grosses, modèles 3d trop complexes.

Si la scene est presque vide, avec uniquement le paysage, ca va, une carte 9800 pro s'en sort largement. Si on commence à ajouter des avions(je pense que les avions ont un eclairage calculé par pixel, mais j'en suis pas sur du tout), ca veut dire deja de grosses textures, des polygones en plus, des animations en plus.
La memoire commence à ne plus suffire, il en faut plus, et de la plus rapide. Donc deja la si tu colles une X1900 tu devrais voir un bond par rapport avec la 9800, avec disons 10 Su-25 t au parking.
10su-25 T de près, ca fait pas loin de 500 000 polygones. A mon avis, le paysage est constitué d'autant de polygones(c'est en tout cas ce que j'ai comme polycount dans on jeu pour le paysage, et c'est deja enorme)

Avec 10 Su-25 T, on double donc le nombre de polys affichés. La pauvre 9800 se pète la gueule, une X1900 tiendra le coup, mais pas forcemment très bien.

Et à coté de ca il faut rajouter l'ia, les sons, les modèles de vol, et le cpu commence à souffrir.

On a donc deux phénomènes simultanés faisant chuter tous les deux les performances, ce qui est catastrophique.

[Cartman]

Ah et oui, encore une chose: la carte graphique prefere rendre un gros terrain de 500 000 polys que 10 avions de 50 000.
Il faut limiter le nombre de passes qu'effectue la carte, c'est un des avantages de l'instancing.
1*100000 c'est mieux que 100000*1

[Electro]

question bête : pourquoi vous ne posteriez pas ça sur le forum d'ED ?? Peut-être que ça pourrait leur donner des idées, non ?