[Mesh rebelle] Le topic des techniques qui décoiffent dans les jeux


#1

Suite à la demande populaire, nous allons ici causer de fractales, de procédural, de shaders, d’interpolation, d’extrapolation, de compression, de texels, de phase large, de pathfinding, mais aussi de copper, de blitter, d’IRQ, de cycles de palettes, de sylphes (© le manuel de prog de mon C64, toi aussi devine ce que ça désigne en anglais) et de toute autre technique ou technologie passée ou future un tant soit peu intéressante qu’on peut trouver dans les jeux.

Bon, moi je suis surtout graphique, mais s’il y en a qui tapent dans le son ou d’autres secteurs, qu’ils n’hésitent pas à crier.

Ce message vous est offert par le mode 7.

Vu qu’on était dans les terrains larges avec Midwinter, comme technologie sympa pour le futur je vais commencer par mettre sur la table le rendu planétaire, ou plus généralement la génération de terrains gigantesques et où on peut quand même aller dans les petits détails.

Actuellement le top du top pour le terrain, c’est les slovaques de Outerra:

Et Eric Bruneton:


à qui on doit notamment la meilleure technique pour les océans. Avec des papiers là. Et Rama (pas en temps réel mais qui préfigure ce qu’il allait faire après).

Pour ceux qui veulent piger comment ça marche je conseille Making Worlds pour une bonne intro et une approche plus artistique, alors que les deux précédents se basent sur des vraies données géographiques du style Blue Marble avec du procédural pour les détails plus fins.

En tout procédural, il y a bien sûr Infinity Engine:

Si on retourne dans le plat, il y a Procedural World et Project Frontier.

En jeu vidéo l’application la plus connue de génération de terrain c’est bien sûr Minecraft, et il y a aussi Fuel.


Le topic indispensable de la Sega ♥ Saturn // CR2032 remembers love
#2

Holy shit ! A quand une simu moderne qui tourne là dessus ? J’imagine que ça doit être tendu de faire rentrer ce moteur + l’IA et l’avionique mais wow.


#3

Eh bien, voilà un bon titre.

Dans les questions qui m’intéressent actuellement, je repensais à la démo de Saint’s Row 3 et aux essais de Tanguy sur Eve Online. Comment sont gérés les éditeurs de personnage auxquels un consommateur aura accès dans un jeu AAA actuel ? Ce sont des outils internes, la plupart du temps ? Ou bien y-a-t’il des middlewares dédiés pour certains moteurs populaires ?

S’il y a des éditeurs sous licence (ex. un éditeur de perso lambda pour UE3), comment est gérée l’interface ? A-t-on le droit de librement changer les paramètres disponibles ?

Quand je vois certains éditeurs de persos, j’ai envie de suggérer à certains devs d’intégrer une solution toute faite mais je ne sais pas si cela existe. D’un autre côté, je suis surpris que les mecs d’Eve se soient cassés le cul à ce point pour leur éditeur alors qu’on ne voit jamais personne ou presque, donc je me demande s’ils l’ont juste acheté/piqué ailleurs.


#4

(super premier post, les deux premières vidéos et la démo sur l’océan sont wahou)

Chaz > Il n’y a pas de réponse toute faite. A ma connaissance, je n’ai pas entendu parler d’éditeur de perso clé en main en middleware mais cela doit exister évidemment. En revanche, créer un éditeur de perso pour le end user est pas “si compliqué”. Je mets des guillemets car pour avoir travaillé sur un tel machin, c’est tout sauf facile à mettre en place, mais la théorie est simple.

Pour te donner un exemple, Top Spin 2, sur lequel j’ai travaillé il y a des années maintenant, avait un éditeur de perso assez poussé. La techno qui fonctionnait derrière marchait sur un mélange de meshs pour les corps et les accessoires qu’on avait prédéfinis avec un certain nombre de gabarits (chacun existait en version mince/moyen/gros pour simplifier). Donc pour générer des persos, tu as besoin de produire les ressources de bases et ensuite de utiliser des techniques de morph entre ces différents gabarits (+ les maps de diffus, specs et bump pour les textures avec les UV qui correspondent).
En revanche, et à ma connaissance cela ne sert que rarement à la production interne, 3DS Max ou tout autre outil de modélisation étant irremplaçables. Par contre, tu peux utiliser ce genre techno pour générer du NPC. Par exemple dans le cas de Top Spin 2, nous utilisions une version du machin branché avec une 360 pour faire la génération et un PC pour les sources et l’export final. Le tout tournait en random avec un set de paramètres prédéfinis et pouf, tu laissais tourner quelques heures en priant pour que cela ne plante pas et tu obtenais 200 persos masculins et 200 persos féminins pour la campagne solo.

Bon c’est un exemple, et d’autre développeurs ont sans doute d’autres idées farfelues dans le genre. Mais en général, ce genre d’éditeurs étant basés sur le moteur, ce sont souvent des technos maisons avec une interface pour l’utilisateur final. Dans le cas de EVE, leur éditeur parait balèze comme ça, mais étant donné qu’il ne sert qu’à blender des gabarits pour en faire un rendu (et non un perso utilisable ingame avec toutes les contraintes d’animations, comme Top Spin 2 par exemple), il n’est pas si difficile à coder à mon avis vu que son usage est très restreint justement.

Mais à mon avis, chaque jeu ayant ses propres ressources graphiques même avec une techno standardisée, je doute qu’il y ait 36 000 middlewares du genre vu la difficulté de répondre à chaque besoin.


#5

Pas mieux. Effectivement au fond tous les éditeurs de persos utilisent les mêmes techniques de base qui n’ont pas fondamentalement changé depuis au moins PSO, empilement de différents segments, morphs et textures à choix, on a juste plus de segments et de morphs. Mais du coup comme c’est super standardisé ça peut être surprenant que ça soit quasiment tout le temps des solutions propriétaires, mais effectivement ça doit être trop lié au moteur. Le seul middleware de création de persos que je connais fait partie de HeroEngine, qui est un middleware MMO clé en main, pas seulement pour les persos. Eve Online a bien une solution propriétaire. Par contre là où ils font appel au middleware, c’est pour la physique des vêtements ou cheveux et l’animation. ça c’est de plus en plus commun.

A noter que quasiment tous ces éditeurs fonctionnent au choix et au morph entre un certain nombre de formes de base, donc il y a peu d’émergence, on est limité par ce que les devs y ont inclus, à part Spore, qui est bien sûr à un tout autre niveau pour le degré de contrôle, et d’une manière générale bourré de technos intéressantes.


#6

Oui pour Eve, je voulais dire que c’était leur techno à eux, je me suis mal exprimé.

J’ai oublié de réponse à cette question, mais ce ne sont que des curseurs que tu bouges et qui influencent les morphs en temps réel (en gros tu choisis comment se fait la “moyenne” entre deux gabarits). Mais comme le dit Chev, tu es tjrs limité à ce que le développeur aura défini à l’avance comme ressources. En revanche, tu peux évidemment t’éclater en offrant 20 milliards de fringues et d’accessoires pour cacher le fait que tes persos auront peu ou prou la même forme.


#7

En parlant d’Eve, sur leur blog ils expliquent l’implementation des nouvelles trainées de lumières derrière les vaisseaux.


#8

Hey, un peu de respect pour la seule fille participante de boulette, merci.


#9

Perso je me serais jamais cassé à faire des vrais cylindres en raytracing, mais en même temps je suis nul pour ce genre de shader.


En retard:

Ils arrivent déjà à faire tourner l’avionique et l’IA ne devrait pas vraiment être un problème (enfin, ça c’est à moitié vrai. A cause de l’étendue du territoire offert tout un tas de nouveaux problèmes se posent), en fait le gros des calculs se fait en préprocessing et l’algo d’affichage lui-même est conçu pour être simple pour le CPU (c’est sauf erreur du chunked LoD, c’est super light pour le CPU). Par contre des trucs comme les textures procédurales (qu’on pourrait optimiser en les précalculant aussi), l’océan, l’atmosphère ou les forêts tapent probablement déjà pas mal dans le GPU, et l’autre truc bien taxé c’est les accès au disque dur ou au réseau, pour streamer le paysage (même si de nouveau le chunked LoD est prévu pour et que sur les paysages on peut faire de la compression assez aggressive, ça laisse quand même 12 gigas à balader). Sur le site officiel la recommandation c’est une Nvidia 8800GT avec 512 mégas.


Une autre technologie du futur (même si ça a été déjà utilisé tout plein dans le passé), c’est la génération procédurale. ça revient pas mal dans les histoires de paysages, mais pas seulement. Plein de gens pensent que c’est aléatoire, mais pas seulement. John Carmack disait que c’est de la compression, mais non, c’est juste un aspect possible. En fait c’est de l’extrapolation: on part du petit jeu de données et on génère beaucoup plus avec. Donc contrairement à la compression, on n’a pas besoin de créer le jeu de données gigantesque à la base. Par contre on perd un certain contrôle sur ce qui est généré. La machine n’a pas d’imagination, donc moins on en fait nous-même, moins les règles de génération sont élaborées et moins le résultat aura de personnalité. Par contre au niveau quantité, on peut toucher l’infini du doigt.

On peut en voir dans Dwarf Fortress, les roguelikes, Minecraft, Les deux premiers Elder Scrolls, Spore, Elite, les Midwinter, Infinity, Kkrieger et plein d’autres.

Il y a un équilibre à trouver entre ce qu’on fournit et ce qu’on récupère, et aussi où on l’applique. Il y a pas mal de trucs très répétitifs visuellement qui pourraient être automatisés au lieu de balancer 50 artistes dessus, où on pourrait augmenter la capacité de production. Rien qu’être capable de générer des humains de base à la volée (en balançant des valeurs aléatoires dans un éditeur de persos généraliste, comme Aliochou le mentionnait) permet d’éviter le truc des NPCs immédiatement taggés comme pas important parce qu’ils n’ont pas de doigts. La création de villes aussi, c’est le genre de truc qui peut être gigantesquement augmenté par du procédural.

Et là vous me voyez sûrement venir, ce qui a introduit ce genre de générateur dans la culture des joueurs, et qui a récemment été mis en vente dans un bundle, c’est Subversion, le générateur de villes d’introversion:

Mais il y a aussi Structure ou Pixel City

Dans le domaine des villes, le grand gourou c’est Pascal Müller, c’est sur son travail qu’Introversion s’est basé. Il avait un wiki fort sympa il y a encore un mois, maintenant il ne reste plus que la liste des papiers et vidéos. Il faut dire qu’il ne s’est pas contenté d’écrire sur ses trouvailles, il a créé une boîte qui les utilise dans un middleware bien dodu appelé CityEngine.

Il a appliqué des principes de génération similaires aux bâtiments:

ça se fait via une structure appelée L-system, à la base créée pour décrire des plantes mais qui fonctionne pour n’importe quelle structure hiérarchique (ville, maison, donjon sont donc des bons candidats mais on pourrait aussi décrire des livres ou des habits, voire des personnages même si c’est ps forcément le plus approprié). En gros c’est une série de règles du genre “une maison a un toit, trois murs et une façade”, “un mur a des fenêtres”, “une façade a une porte” qui s’enchaînent pour décrire tout un objet. Une bonne explication est sur Procedural World. Donc c’est un mécanisme super utile pour décrire la structure de quelque chose, mais en plus en hiérarchisant un objet comme ça on obtient des tags qui peuvent être bien utiles plus tard pour l’IA.

Comme le faire en texte c’est pas assez futuriste ses complices ont ensuite mis au point un éditeur graphique (qui est dans CityEngine, bien sûr). Il y a une vidéo de démo sur la page, je ne l’ai pas trouvé sur youtube.


#10

Concrètement, pour qu’une bécane puisse gérer proprement la génération procédurale d’un monde en 3D genre Subversion ou Minecraft, il faut quoi ? De la RAM à gogo ? Je me pose la question à cause de Minecraft, qui pèse trois fois rien, tourne avec Java et propose des graphs sommaires mais met certains “vieux” PC à genoux. Aurait-on pu faire tourner Minecraft sur PS2 tranquillou ?


#11

Le problème de MineCraft, je pense que c’est Java.


#12

Si tu veux mon avis, c’est aussi le problème de la musette.


#13

Un programme JAVA n’étant pas compilé en code natif du system cible mais passant forcément par une machine d’exécution elle même compilée en code natif et exécutant le code JAVA, cela demande effectivement plus de ressources qu’un programme en C(++) ou mieux en assembleur (pour les standards que je connais), eux compilé en code natif directement.


#14

les machines virtuelles sont quand même très performantes maintenant, j’avais vu un benchmark sur des process de calcul et java s’en tirait quasiment aussi bien que le reste.
après c’est peut être sur une partie spécifique que ça peut coincer au niveau java, sur la partie graphique ?


#15

Le problème du Java, c’est surtout le garbage collector, qui libère la mémoire un peu quand il veut, comme il veut.
J’imagine que sur des modèles du genre de Minecraft, qui peuvent être gourmands au point de vue mémoire, cela puisse parfois coincer.


#16

Surtout qu’il y a des shaders machin chouette, genre l’Ambient Occlusing et l’atténuation atmosphérique. Ca doit sucer en Java. Mais ouais, c’est peut être aussi du au fait que Minecraft tourne sur un noyau minus codé avec les couilles à la base, et qu’il était pas pensé scalable dès le départ. Et qu’il tourne encore dessus non ?


#17

Les mecs de Fuel (Asobo) avaient trouvé une parade il me semble, par contre j’ignore exactement ce qu’ils avaient fait (sans doute à partir de quel moment l’humain passait le relais au procédural dans la génération du monde). De plus on voyait tellement le monde au raz des paquerettes que les éventuelles répétitions ou côté générique devaient être plus ou moins invisibles.

EDIT = Ah et je me demande comment dans le cas d’un générateur de ville (par exemple, mais surtout parce que c’est le plus embêtant), fait-on pour solidifier les données ? En gros, comment éviter que le jeu ne soit complètement en aléatoire et que le joueur de ne se retrouve avec un plan de ville ou bien des landmarks jamais au même endroit ?
J’imagine que l’on doit partir d’une map de base définie pour y arriver : layout des rues, emplacement des points de repères, puis des zones où l’on peint des styles de batiments, etc. Et puis zou ! Le procédural prend la relève à chaque exécution en remplissant les blancs de manière invisible.


#18

L’aléatoire, en informatique, ça n’existe pas : TOUT est déterministe. Même les fonctions de random.
En gros, à chaque fois que tu lanceras un appel à la fonction, tu auras toujours les mêmes résultats, toujours dans le même ordre ; pour palier à cela, les fonctions de random s’initialisent à partir d’une valeur que l’on appelle la seed, sur laquelle elles s’appuient pour générer leurs séquences de nombres renvoyés. C’est cette seed qui doit être “random” pour que la fonction le soit également – en général on utilisera le temps courant, qui est une assez bonne approximation d’un nombre aléatoire à un moment T.
DONC, si tu utilises toujours la même seed, tu as toujours le même random.
Donc tu peux t’appuyer sur de la génération “aléatoire” tout en étant certain d’avoir toujours les mêmes résultats.

(En espérant que c’était bien ta question ? ^^)


#19

C’était exactement ça. Je subodorais un truc dans le genre en lisant l’article linké sur la génération de la petite maison cubique (vu que c’est un exemple simple). Merci !


#20

En plus, pour des trucs géographiques on utilise des fonctions de hachage, soit des fonctions qui reçoivent une valeur en entrée, et qui pour la même entrée et le même seed renvoient toujours la même valeur en sortie. La fonction est absolument déterministe, mais ce qui est pseudo-aléatoire c’est que pour des entrées même proches on a des sorties très imprévisibles. Et en entrée on utilise les coordonnées dans l’espace, comme ça au même endroit on aura toujours le même truc qui sera généré. Mais j’y reviendrai.

L’autre solution c’est bêtement d’enregistrer le résultat. Pas besoin de recalculer, par contre il faut stocker.

Tanguy> en fait les shaders c’est pas un problème, ils s’exécutent sur le GPU, complétement séparés de java tout comme ils sont complétement séparés de C++ ou C#. Donc tu peux avoir les mêmes shaders de sauvage en java qu’ailleurs, sauf s’il y a beaucoup de choses à préparer avec le CPU avant.

Mais en fait la lenteur possible de java c’est pas le vrai problème, le problème c’est les fameuse fonctions qui vont dire ce qu’on a au point XYZ, qui peuvent être super compliquées et donc super lentes. Du coup tout dépend de leur complexité, de leur nombre et du nombre de fois où on les appelle, et sur combien de dimensions. Deux dimensions suffisent pour un paysage, mais si on veut des grottes et des arches et des choses qui peuvent se superposer il en faut trois. Comme dans Minecraft, donc. il y a quelques détails là: http://notch.tumblr.com/post/3746989361/terrain-generation-part-1

Par contre ce sont des fonctions super parallélisables, avec beaucoup de calculs très répétitifs, donc ils vont bénéficier à fond de SIMD ou d’architectures multicore. On peut aussi les exécuter sur le GPU, ce qui va en général vraiment très vite.

Perso sur mes programmes de test je ne stocke rien mais j’ai tout un core réservé pour la synthèse, qui va bien être mis à contribution (notamment parce que j’ai envie de voir loin, donc je génère loin). Donc pour revenir à ta question, Chaz, pour faire du procédural, si on précalcule il faut de la mémoire, et sinon il faut du CPU, et si possible du parallèle. Mais si on s’en tient à des fonctions relativement simples ou d’autres compromis on peut faire faire tourner ça sur des vieux trucs. Midwinter le faisait en limitant la profondeur de champ à 5 “cases” ou quelque chose du style, Commander Blood échantillonnait large et simple, Daggerfall se contentait de choisir parmi des blocs préfabriqués, etc…