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


#181

realtime ASCII post processing sur Unity.


#182

REVERSE ENGINEERING WIPEOUT (PSX)


#183

Excellent, le lien sur WipeOut

Ma contribution aujourd’hui, rapport à une interrogation dans le topic indé:

Voici un pack de shaders pour faire de la PS1 dans Unity, clé en main! Spécifiquement deux effets clés, une précision limitée dans les coordonnées des triangles à l’écran et les textures sans perspectives.
http://burningnorth.com/unity/flashback94/
Pour avoir l’effet complet le dernier élément qui tue serait de couper le z-buffer (le truc qui mémorize la profondeur des triangles pour savoir qui est devant qui à chaque pixel) et tout trier à la main.


La présentation GDC sur les graphismes de Guilty Gear Xrd est disponible publiquement, slides et vidéo:

http://arcsystemworksu.com/guilty-gear-xrds-art-style-the-x-factor-between-2d-and-3d-talk-from-gdc-2015-is-now-available-online/


#184

Le shader pack a l’air sympa.

On dois pouvoir egalement desactiver le Z Buffer sans trop de probleme j’imagine et je suis sur qu’il y a un truc pour que unity trie lui meme les poly a la main. Ils sont deja obligé de le faire pour les poly transparents.

edit:
mmmh en fait je suis pas convaincu de leur systeme pour les coordonnés en entier.

Le manque de precision des vertex ne se fait pas vraiment sentir dans les coordonnées monde.
La position des vertex dans les modele 3D etait (tour comme les calcul 3D) en point fixe (donc en entier) mais generalement le manque de precision se faisait surtout sentir apres la projection en 2D.
Je ne me rappele pas vraiment de “snapping” (tout du moins sur Saturn et PS)


#185

Sur PS1 les coordonnées après transformation étaient des entiers en nombre de pixel (pas de subpixel accuracy), c’est ça qui induisait l’effet de snap/flottement et c’est aussi pour ça qu’aucun émulateur ne peut le corriger (c’est déjà des entiers post-transform quand ça arrive au GPU). Effectivement pour les transformations avant ce point on pouvait se servir de virgule fixe et ça réglait raisonnablement la plupart des problèmes. Donc oui, en te contentant de snapper les coordonnées post-transform pour les faire correspondre au vieux mode écran de ton choix tu auras dans l’ensemble déjà un effet plus vrai que nature.

Par contre après sur PC (et portages) il y a encore toute l’histoire des moteurs de Quake 1-2-3 (id tech 2 et 3 pour causer moderne) où les polygones des persos étaient pré-transformés dans un système de coordonnées entier pour chaque frame d’anim du perso (parce que ces moteurs ne supportaient pas l’animation par squelette), ce qui induisait déjà un effet de flottement avant, qu’on ne remarquait pas vraiment en résolution VGA mais qui devenait super flagrant, en particulier sur les visages, une fois que les premières cartes 3D sont arrivées et ont permis des plus hautes résolutions.


#186

Justement ce qui me derange dans le pack http://burningnorth.com/unity/flashback94/
c’est que leur “vertex snapping” n’a pas l’air de tenir compte de la resolution, donc l’effet est largement amplifié. A tel point que je me demande si ils ne reduisent pas la precision avant la projection a l’ecran.

Pour Quake, je ne suis pas sur de te suivre quand tu dis effet de flottement. Pendant une animation tu vois les polygones changer legerement de taille?
J’avais fait un viewer de md3 a l’epoque et je me souviens d’avoir était tres supris de voir que toutes les anim etait juste une interpolation de points. Ca a été en fait une tres bonne lecon: il faut savoir utiliser une solution simple a chaque probleme. Quake 3 n’avait vraiement pas besoin d’un systeme d’animation compliqué. Par contre j’avais completement oublié que c’etait en virgule fixe. (Si a l’epoque wikipedia avait existé ma vie aurait était beaucoup plus simple http://en.wikipedia.org/wiki/MD3_(file_format))


#187

Pour le snapping, un truc super important, c’est que pour restituer l’effet d’un vieux jeu, ça n’est pas forcément la résolution effective de ton écran qui t’intéresse, c’est la résolution du framebuffer que tu veux rappeler. Autrement dit si tu veux restituer un jeu PS1 résolution standard tu vas devoir faire le snap sur 320x240 même si tu es en 1080p (ce qui te donneras le même résultat qu’un émulateur PS1 en haute résolution). Si tu fais le snap sur ta vraie résolution moderne l’effet rétro en sera grandement diminué, d’où le snap paramétrable.

Pour Quake, sur cette vidéo (Heretic 2, avec le moteur de Quake 2), note comment les cheveux ou l’armure du héros semblent onduler, alors qu’en fait c’est tout à fait un moteur qui fait du subpixel accuracy et les décors n’onduleront par exemple jamais. C’est justement dû au fait que les persos eux-mêmes n’ont pas de squelette et c’est juste de l’interpolation linéaire entre deux frames stockées à des précisions limitées.

Je ne suis pas d’accord pour dire que c’était un bon choix technologique, et c’est à mon sense par là que Carmack s’est mis à perdre son avance sur la concurrence (ce qui s’est poursuivi avec des mauvais choix sur Doom 3 et Rage). Half-life ou Unreal, en adoptant les squelettes, a amené des animations plus complexes, plus compactes, avec la possibilité de costumes alternatifs reprenant les mêmes animations avec des modèles différents, des anims paramétriques, mais aussi la possibilité d’avoir des gros plans ou persos géants sans perte visible de précision.

Bon, le plus marrant dans tout ça, c’est que Raynal avait déjà tout inventé en matière d’anim par squelette en temps réel dans le premier Alone in the Dark et que ça a été essentiellement ignoré jusqu’à Half Life.


#188

Merci pour la video. En effet on vois tres bien les limites de la technique.

Techniquement des animations avec squelettes sont superieurs a une simple interpolation de vertex mais avoir un squelette n’ajoute quasiment rien a Q3A. Sur ce meme projet j’avais été également surpris de voir que la majorité des fichiers était en mode texte. Quel gachis!! Cependant le peu de resource gaché (memoire et CPU) est donné comparé aux avantage pour les moddeurs pour comprendre le format et commencer a creer des outils. Trade-offs!!

Ce sont des choix tres pragmatique. Carmack n’a pas fait ces choix simplement parce qu’il ne pouvais pas creer un systeme d’animation avec squelette mais simplement parce qu’une solution plus simple et deja mis a l’epreuve est simplement plus adapté au projet.

De ce point de vu je preferes l’approche d’id que d’unreal avec leur usine a gaz de moteur.

“Si Carmack avait utilisé un systeme d’animation avec squelette, je n’aurais pas éxisté” Orbb


#189

Au contraire, rien n’empêche Orbb d’exister, niveau production c’est la même quantité de travail (car Orbb est bien animé par squelette lors de son passage chez l’animateur).

Q3A est même le premier signe que Carmack réalisait son erreur, intégrant une forme rudimentaire de squelette via segmentation (les tags dans le format MD3). Ainsi, les persos étaient communément séparés en tête, torse et jambes parce qu’il était devenu commun dans les FPS de montrer la direction dans laquelle les autres joueurs regardaient et pointaient leur arme, information tout à fait intéressante, mais qu’une telle animation dynamique est impossible sans au moins une forme rudimentaire de squelette.


#190

Pour etre honnete je ne le vois pas comme un aveux de Carmack. Q3A n’avais simplement pas besoin de squelette. Par contre il a été plus clair sur les fichiers en mode texte qu’il considere comme une erreur a cause de l’impact sur le CPU.

En effet Orbb est tout a fait possible avec un squelette mais le designer de Orbb avait dit dans une interview que le design du perso était le resultat des limitations qu’ils avaient (ils ont du remplacer les jambes avec les mains ou un truc du genre).


#191

S’il n’avait pas eu besoin de squelette il n’aurait pas eu l’amorce d’un système de squelette. Mais il l’a. Et dans le contexte c’est logique, ils arrivaient après HL qui avait été encensé sur son système d’animation. D’ailleurs si tu regarde quelles étaient les features ajoutées par les développeurs qui ont acheté le moteur de Q3A, l’animation par squelette est presque systématique.

Pour Orrb, c’est ce que je disais avant: les persos de Q3A sont divisés en trois “os”, tête, torse, jambes. Ses mains sont les jambes, d’un point de vue du moteur, parce que la partie qui ne bouge pas avec l’angle de tir a besoin d’être les jambes dans Q3A. Mais ça n’a rien à voir avec ce dont je parle, qui est que pour produire les frames fixes utilisées dans les trois premiers Quake c’est bien des persos animés par squelette qui sont utilisés par les animateurs (ça fait depuis l’aube de l’animation 3d que personne n’ess assez maso pour animer directement somme par sommet).


#192

Je crois qu’on tourne en rond mais je reitere mon point: Q3A n’avais pas besoin d’un systeme de squelette comme HL. La squelette simplifié est juste la methode qui convenait le mieux au projet. Meme a l’epoque un systeme d’animation par squelette n’etait pas de la une tech si avancé, on en avait un dans notre jeu pour gosse a petit budget et les jeux playstation sont tres rapidement passé a une animation par squelette egalement. Si iD avait vraiment besoin d’un systeme d’animation plus avancé ils l’auraient fait.

Et c’est le point que je voulais mettre en avant. Il y a une tendance pour les programmeurs de favoriser des technique plus compliqué qu’ils n’ont besoin juste pour suivre la course a la tech, faire comme ou mieux que le voisin. Pour moi (et je dis souligne pour moi) une solution simpliste mais adapté au projet est une meilleur approche.

Il y a un argument a avoir de la consequence de ce choix pour un moteur utilisé par d’autres developpeur. Mais c’est d’ailleur un point interessant car finalement il faisait un moteur pour eux et pouvait le vendre, mais ce genre de choix montre qu’ils ne se voyaient pas avant tout comme une boite de moteur 3D.

Pour Orbb je ne contestais pas ce que tu disais. Je sais tres bien comment les animations sont faite. J’ajouterais sur ce point que les animateurs pour Q3 n’avait pas de limitation pour le nombre de bone alors qu’a l’epoque les animateur avait des grosse contrainte a ce niveau pour les moteurs avec des squelette :wink:


#193

Le truc du nombre d’os est un faux argument vu qu’aucun des persos de Q3A n’est assez complexe pour dépasser les standards de l’époque (tu n’as pas de truc dingue genre un slime qui morphe, et pendant ce temps sur PS1 tu as FF8 qui pousse des monstres à 70-80 os), et ça ne fait que le remplacer par un autre problème (le nombre de sommets que tu peux faire tenir en mémoire quand tu dois les dupliquer pour chaque frame).

Pour la course à la technologie, c’est oublier que c’était exactement ça, le positionnement stratégique d’id à l’époque, ce sur quoi ils avaient fait leur réputation et leur blé, et que justement ce Q3A un peu à la ramasse techniquement était le premier pas de travers d’id à ce niveau alors qu’avant ils dominaient complètement, et qu’après Doom 3 allait carrément s’en prendre plein la gueule pour son choix technologique pour les ombres. Le fait de dire “ouais en fait on n’est pas une boîte de moteurs” quand ils étaient LA boîte qui a créé le marché du moteur dans cette industrie est en soi un aveu. Et donc historiquement c’était un tournant.


#194

(en tout cas c’est passionant comme discussion sur les histoires de coordonnées et squelette/pas squelette, ne changez rien !)


#195

Quelqu’un a fait joujou avec Portal pour faire des espaces non-euclidiens (physiquement impossibles quoi, comme des pièces carrées à cinq coins ou plus grandes à l’intérieur.


#196

Un article très intéressant et merveilleusement illustré sur les systèmes de caméra dans les jeux 2d:


#197

How did game developers pack entire games into so little memory twenty five years ago?


#198

Les réseaux neuronaux de google essaient de comprendre ce qu’est une image.


#199

Pour les vrais nerds du codage sur ce forum, une petite présentation de 4 minutes sur quelques effets de bord rigolos en JavaScript et en Ruby.
Oui je sais, les rires sont insupportables, mais ça nous donne des merveilles comme :

et d’autres que je vous laisse découvrir.


#200

Je vais en profiter pour déverser ma haine du monde franglais, d’autant plus que je l’entends tous les jours au boulot: ça n’existe pas, “effet de bord”. Pouah! La traduction de side effect, c’est effet secondaire. C’est comme mon boss qui me demande de fixer des issues. Apprenez votre langue!