| Message |
|---|
|
Chez Develop-online.net, Gabe Newell explique pourquoi VALVe ne prévoit pas de sortir un "Source Engine 2". Si vous avez la flemme de tout lire, vous avez raison.
Lire toute la news sur Nofrag.com... |
|
C'est bien dommage car le SE a beau être un très bon moteur, il commence a fatiguer un peu quand même, et puis bon faudra bien qu'un jour ils sortent cs:s 2 sur un nouveau moteur.
|
Birdroun a dit :Il fatigue ? Portal 2 a prouvé le contraire je crois... |
|
Pas au niveau des chargements.
|
bloodyhenry a dit :Ouai enfin, Portal 2 c'est pas non plus Crysis faut pas déconner. Certains décors sont jolis mais tout de même, de là à dire que c'est magnifique ou que "ça prouve le contraire"...Birdroun a dit :Il fatigue ? Portal 2 a prouvé le contraire je crois... |
|
C'est tout à fait honnête comme graphismes, je préfère un jeu avec des graphismes stylés avec un style propre qu'un jeu "avec les graphismes de crysis (pour ce que ça veut dire...)".
Faut arrêter avec "les graphismes", c'est pas ça qui fait le gameplay. Et source, c'est loin d'être moche à l'heure actuelle. Et c'est aussi un gage de bonne optimisation en général, ça peut tourner sur des machines assez faibles. |
|
@Oyoel
Un renderer ça évolue. Comme dit dans l'interview d'ailleurs, il continuera à évoluer et rien ne dit que les prochaines itérations de Source n'incluront pas SSAO, éclairages et effets volumétriques, etc. Le réel problème c'est ce que dit BaToU. Source est terriblement statique : comme au temps de Quake 1 tous les calculs importants sont offline (à la compilation) puis quand tu lances un niveau, tu charges tout ton BSP en RAM. Du coup aujourd'hui, Source est un très mauvais moteur pour tout ce qui est dynamique non-précalculé, de plus dès que la complexité du niveau devient importante (géométrie, physique pré-calculée, variations dans les environnements), les chargements deviennent terriblement fréquents. Dans Portal 2 c'était à la limite du foutage de gueule. Et ça, ça touche à la base du moteur. Réécrire tout ça reviendrait à -quoi qu'en dise Gabe Newell- programmer un deuxième moteur. Même s'il garde les mêmes modules comme le rendu et ses API, on serait dans une situation qui s'apparenterait à passer de UE2 à UE3. @bloodyhenry Je suis d'accord sur le fond, il n'empêche que la bonne optimisation actuelle de Source et sa capacité à tourner sur des petites configs sont intrinsèquement liées à ses limitations au chargement monolithique ainsi qu'aux compromis en termes de taille de niveau. Si Half-Life 3 doit se dérouler en Antarctique dans de grands environnements détaillés, chez Valve ils vont avoir énormément de mal s'ils ne réécrivent pas un moteur. |
|
Vu que tu as l'air de t'y connaître, une question me taraude depuis la sortie de portal 2 : pourquoi les maps de L4D sont immenses, et sans chargement, alors que les maps de portal 2 sont minuscules ?
Si le moteur peut gérer des maps assez grandes comme dans L4D, pourquoi avoir choisi de découper tout ça en petits bouts ? |
|
Il ne me semble pas que les cartes de L4D soient immenses, tout au moins si on compare avec BF² ou BFBC2. J'ai même l'impression que le source engine gère de petites maps avec de longs temps de chargement, comme si il était complétement dépassé. Si un pro peut nous expliquer si je me trompe :D
|
|
Je ne m'y connais pas aussi bien ce que ma manière de m'exprimer pompeusement voudrait faire croire :P Ceci dit je pense que ça vient de plusieurs facteurs (à confirmer par un connaisseur de source/hammer) :
- Les maps de Portal 2 sont visuellement plus petites mais physiquement, le sont-elles réellement ? A mon avis, tout ce qui est "cinematic physics" (c'est-à-dire toutes les animations de la géométrie lorsque les labos se reconstruisent ou se détruisent) doit être stocké et chargé en parallèle avec le reste de la géométrie statique. Cela est quasi totalement absent de L4D et pourrait expliquer l'essentiel des chargements à chaque salle de test. - De même, certaines salles de test contiennent un nombre important d'objets/lumières, en tout cas plus important que Portal ou L4D. Or il me semble que la limite max d'entités dans Source est relativement faible. - Enfin, les développeurs ont peut-être voulu homogénéiser les impressions des joueurs en imposant un "une salle de test / un sas = un chargement", peut-être plus confortable psychologiquement qu'un écran de chargement inattendu après quelques salles. Quoi qu'il en soit dans Portal 2, perso j'aurais préféré le petit "CHARGEMENT" de HL2, discret et élégant, à ces incessants écrans pleins. |
|
Dans le cas de L4D je ne saurais pas m'exprimer, mais sinon le source engine en général gère très mal les grandes maps. Et si on force un peu trop ça finit en overflow en mémoire (tout fout le camp).
Les Devs de E.Y.E ont eu quelques soucis avec ça il me semble. Résultât c'est usage d'un Fog abusif pour entretenir l'impression d'immensité. Et puis faut pas oublier le système des skybox 3d propre au source engine qui simule un petit morceau de map et l'agrandi vachement (genre la map sandbox du garry's mod, les immeubles aux alentours sont en fait minuscules). On retrouve ce système également pour la citadelle de Hl2 et Ep1 quand on est à son pied. La base de la citadelle est à échelle humaine, mais au dessus c'est juste un truc agrandis genre x10. Bref c'est de l'esbrouf. |
|
C'est pas vraiment un élément de comparaison, mais dans mes souvenir, DIPRIP (mod pour HL2) avait des maps giganstesques avec pas mal de décors déstrucibles.
|