Journal de bord

Journal de bord

Par Swing Swing Submarine Blog créé le 08/01/10 Mis à jour le 05/04/15 à 22h03

Ajouter aux favoris
Signaler
Seasons after Fall

Salut tout le monde !

Prêts pour un nouveau "tech post" avec une vidéo bonux intégrée ? Cette fois-ci on va parler des tests de visibilité dans Seasons.

La semaine dernière, j'ai donc tenté d'améliorer le code de rendu pour réduire le temps que nous passons à fabriquer les images.

 

>> Contexte

Jusqu'à présent, je ne m'étais pas trop soucié de l'optimisation du rendu (faut croire que je me soucie de pas grand chose en fait !). Quelques techniques d'optimisation avaient bien été implémentées... Mais comme nous sommes passé d'un affichage style 2D à style 3D (souvenez-vous), le tout est devenu très buggué... jusqu'à la semaine dernière !

 

>> Frustum

La chose principale que l'on essaie de faire lorsque l'on veut optimiser l'affichage, c'est de n'envoyer au rendu que les objets qui seront visibles depuis le point de vue de la caméra. Ça peut sembler logique mais c'est une chose qui n'est pas automatiquement gérée par un quelconque hardware. On doit donc prendre en charge tout cela du côté du moteur de jeu (côté CPU la plupart du temps) afin de d'alléger le rendu. On appelle le procéder le "culling" (l'élimination des parties cachées). 

Pour parvenir à déterminer ce qui est visible de ce qui ne l'est pas, on peut compter sur l'utilisation intensive du frustum. Le frustum est une structure géométrique prenant très souvent la forme d'une pyramide tronquée. Cette forme représente ce que voit la caméra et comment elle projette ce qu'elle voit sur son capteur CCD qu'est l'écran.

Un frustum et sa caméra

Les objets partiellement ou entièrement contenus dans le frustum de la caméra sont potentiellement visible à l'écran. Potentiellement car ces objets peuvent être cachés par d'autres objets plus proches et/ou plus gros également présents à l'intérieur du frustum.

 

L'algorithme

Comme vous l'aurez compris, l'idée est d'empêcher certains objets d'être dessinés en testant leur visibilité avec le frustum de la caméra. Voici le pseudo-code (algorithme).


FONCTION mise à jour/rendu
{
    POUR CHAQUE Objet dans la liste des objets du niveau FAIRE
    {
        SI l'Objet courant est dans le frustum ALORS
        {
            rendre l'objet 
            (ou le mettre à jour,
            ou effectuer une action)
        }
    }
}

Et voici un petit schéma pour illustrer la situation. On y montre une scène composée de 25 objets et d'un frustum, le tout en vue de dessus.

Le frustum et les 25 objets, le dernier film dans vos salles

Seulement 3 des objets de la scène sont à l'intérieur du frustum et seront donc envoyés au rendu.

Avec cette technique, on évite de rendre 22 objets mais on doit quand même parcourir TOUS les objets de la scène afin de savoir au cas par cas qui est potentiellement visible et qui ne le sera définitivement pas. Notre scène d'exemple ne contient que 25 objets, mais dans le cas de scènes plus complexes, on va passer un temps fou à tester beaucoup d'objets... et dans le jeu vidéo plus qu'ailleurs, on évite de passer trop de temps machine à calculer une image sous peine d'avoir un jeu qui perd en fluidité.

Le rêve américain, c'est de mettre moins de 16 millisecondes pour construire une image du jeu.

Pour éviter de parcourir tous les objets de la scène, on peut tenter de faire des groupements d'objets. Ces groupes vont contenir des objets spatialement proches.

>> Élimination par grille

Il existe une multitude de manières de regrouper des objets afin de simplifier le travail d'élimination des parties cachées. On peut citer les BSP, les portails ou encore les Quadtree et autres Octree... mais nous n'utiliserons aucune de ces méthodes. Nous n'allons pas élaborer de zones hiérarchiques ("tree" insinue arborescence) mais nous allons nous contenter d'une grille 3D régulière.

Parce que nous ne sommes pas dans le cas d'un jeu réellement en 3D (dans le sens où les objets affichés ont des épaisseurs infimes et sont toujours face caméra, et que la caméra regarde toujours le long d'un axe donné), alors nous pouvons nous permettre d'opter pour une solution moins "complexe" que celles sus-citées.

Ce que nous voulons, c'est retirer au plus tôt quelques objets supplémentaires de la boucle du pseudo code précédent, aussi vite que nous le pouvons. En ayant un système plus élaboré, on perdrait plus de temps à maintenir ce système que de conserver notre grosse boucle.

Voici un exemple simpliste de grille 3D. La grille est composée de cellules de couleurs différentes.

Mini grille régulière

On remarque que 2 cellules sont visibles car contenues dans le frustum de la caméra. On note aussi que cette grille est vraiment simpliste, mais c'est pour l'exemple !

 

L'algorithme

Le pseudo code mettant en jeu une grille est un peu plus complexe que le précédent car il se compose de 2 étapes.

La première étape consiste à enregistrer un objet nouvellement créé dans une ou des cellules de la grille.


FONCTION ajout d'objet/déplacement d'objet
{
    dé-enregistrer l'Objet de la grille 3D
    (si il était enregistré)

    trouver les cellules de la grille qui contiennent l'Objet
    (facile à faire car la grille est régulière)

    enregistrer l'Objet dans les cellules trouvées
    (dans le meilleur des cas l'Objet se trouve que dans
    une seule cellule)
}

Et voici l'équivalent du pseudo code de mise à jour rendu de tout à l'heure !


FONCTION mise à jour/rendu
{
    déterminer quelles sont les cellules visibles autour de la caméra
    (facile à faire car la grille est régulière)

    POUR CHAQUE Cellule visible par la caméra FAIRE
    {
        POUR CHAQUE Objet enregistré dans la cellule courante FAIRE
        {
            SI l'Objet n'a pas encore été traité ALORS
            {
                SI l'Objet courant est dans le frustum ALORS
                {
                    rendre l'objet
                    (ou le mettre à jour,
                    ou effectuer une action)

                    marquer l'objet comme traité
                    (pour ne pas être traité une 2eme fois
                    durant la même image dans le cas où l'objet
                    était enregistré dans plusieurs cellules)
                }
            }
        }
    }
}

Et voici l'illustration des objets et des cellules sur une même image.

Frustum, cellules, grille et objets : le megamix

Comme vous pouvez le constater, 2 cellules sont visibles, et 7 objets sont testés avec le frustum (au lieu de 25 précédemment).

 

Réglages

Pour avoir une élimination des plus efficaces, il convient d'effectuer des réglages sur le nombre et la taille des cellules. En effet, si la taille des cellules est trop petite, alors on aura beaucoup de cellules et dans le pire des cas on obtiendra 1 objet par cellule, ce qui revient à ne pas utiliser de grille et de cellules du tout, en pire.

Si les cellules sont trop grandes, on se retrouve dans la même situation car dans un cas extrême la scène ne contiendrait une grille composée que d'une seule cellule, ce qui revient à ne pas utiliser de grille.

Il faut donc trouver le juste milieu, et pour cela il convient déjà de créer des niveaux afin d'avoir l'échelle des objets qui y sont positionnés. De là on peut ajuster la taille des cellules.

 

>> C'est dans la boite

Pour pouvoir déterminer si un objet est dans le frustum, on doit connaitre son encombrement. Pour déterminer cet encombrement le plus rapidement possible, nous n'utilisons pas directement le maillage d'un objet ni même sa boite englobante orientée (OOBB, Oriented Object Bounding Box) mais plutôt une enveloppe englobante plus simpliste encore : la boite englobante alignée aux axes du monde (AABB, Aligned Axis Bounding Box).

Voici un exemple de l'évolution d'une AABB en comparaison d'une OOBB sur un maillage de chat qui subit diverses rotations (non, ce n'est pas Buster).

Maintenant vous voyez un chat pivotant, sans prendre de drogue (en haut l'AABB, en bas l'OOBB)

 

En utilisant une AABB plutôt qu'une OOBB, on rend le calcul de visibilité super simple et rapide (ou efficace et pas cher, comme vous préférez). Pour mieux comprendre pourquoi une telle facilité, voici des exemples de situations de positionnement entre 2 AABB.

Quelques unes des configuration possibles entre 2 AABB

 

On ne présente pas toutes les combinaisons possibles, mais l'algorithme utilisé pour savoir si oui ou non 2 AABB se superposent prendra dans tous les cas le même nombre de calculs, quelque soit la configuration. Revoici nos AABB mais cette fois-ci avec des vecteurs tracés entre certains des coins des boites :

AABB et vecteurs reliant les coins bas-gauche et haut-droit

 

Les vecteurs tracés connectent toujours le coin bas-gauche d'une boite avec le coin haut-droit de l'autre boite.

Il devient alors facile de remarquer que 2 AABB se superposent quand les 2 vecteurs ainsi formés pointent une direction Nord-Est. On peut aussi dire que 2 AABB se superposent dans les cas particuliers où les vecteurs pointent une direction Nord (vecteur vertical pointant vers le haut) ou Est (vecteur horizontal pointant vers la droite).

Je ne vous écrirais pas le pseudo code ici, mais on voit bien que le calcul est vite fait, et qu'il fait bien toujours le même nombre d'opérations.

 

>> Résultats dans le jeu

C'est bien joli tous ces trucs théoriques, mais si on matait une petite vidéo maintenant ?

Vous allez y voir plein de boites englobantes, des rouges (pour les objets), une bleue (représentant la coupe du frustum le long du plan vertical autour de Z = 0) des vertes (pour les cellules de la gille).

La boite bleue varie de taille uniquement pour montrer comment les objets sont rejetés ou acceptés. Changer la taille laisse apparaître un phénomène de poping pour bien mettre en évidence le culling.

Du point de vue du framerate, voici quelques chiffres relevés sur ce niveau qui reste toutefois assez petit/simple :

- 48 fps sans aucune optimisation de visibilité
- 55 fps quand les AABB des objets sont testés directement avec le frustum (sans l'usage d'une grille)
- 60+ fps quand on utilise une grille ("+" car le moteur limite le framerate à 60 fps)

Tout ceci sur mon PC pas terriblement récent (P4 C 2.8Ghz et sa copine Geforce 7600Gt, AGP s'il vous plait !).

 

>> Pour conclure

C'était une première passe d'optimisation, il y en aura forcément d'autres. On ne vise pas des configurations de fous, donc il faudra qu'on s'applique à ce que le jeu tourne sur une grande variété de machines.

Dans un prochain article sur l'optimisation, on pourra pleinement parler de choses passées sous silence ici, comme le Batching, ou l'utilisation de buffer dynamiques vs. buffer statiques ou d'autres joyeusetés du genre.

 

Pour le moment, place à vos remarques et expériences vis à vis de la visibilité dans les jeux (en tant que joueur ou développeur) ! 

 

Hop, je ne suis plus visible.

Guillaume

Ajouter à mes favoris Commenter (22)

Commentaires

Swing Swing Submarine
Signaler
Swing Swing Submarine
Salut Druss :)

Merci de venir nous lire si régulièrement ;) (à toi et aussi les autres, on va devoir finir par vous payer ^^).
Et je suis toujours attristé quand je pense qu'on a pas pu te rencontré l'autre fois à paname, mais pour une prochaine fois !

Sinon pour l'article, j'aurais peut-être du parler de l'occlusion culling, histoire que l'on discerne bien l'occlusion culling du frustum culling ici présenté. Mais comme on l'utilise pas (l'occlusion culling) pour le moment dans Seasons, peut être que j'en ferais un petit post à part, juste pour présenté la technique avec ma maigre expérience de la chose ^^.

Vous êtes des lecteurs fous furieux hein, donc on essaie d'être à vote hauteur. C'est pas évident. Là par exemple je viens de recevoir un MP de l'ami Enimal... et il s'amuse bien sur Unity sur un truc que je garderais "top zigret", NDA oblige, mais qui me fait bien marrer :)

Bon j'arrête ma bizounoursitude pour ce soir (mais c'est plus fort que moi) :P

Guillaume
Druss
Signaler
Druss
Les blogs dont les commentaires sont aussi interessants a lire que les articles sont rares... Que dire de plus, si ce n'est que je reviens toujours ici avec plaisir? Ah oui, je sais : vivement votre prochain post ! :)
Swing Swing Submarine
Signaler
Swing Swing Submarine
@hairaz:
Eh bien merci pour ces éloges :) Merci aux gens de venir poster ici leur avis aiguisés :)
Et je connaissais pas FastestFox ! Bon voyage de quelques heures chez les Wolfire ^^

Et puis c'est toujours plus intéressant de partager ensemble que de rester chacun dans son coin :P
Comme le disait le papa de tous les programmeurs (JC, John Carmack), dans la préface du Black Book:

"La programmation n'est pas un jeu à somme nulle. Apprendre quelque chose à un programmeur de votre entourage ne vous fait pas perdre ce 'quelque chose'. Je suis heureux de le partager lorsque je peux, parce que je suis passionné de programmation. Les Ferrari ne sont que la cerise sur le gâteau, sincèrement !"

Bon a SwingSwing ont a mis une croix sur les Ferraris depuis bien longtemps, mais pour le reste j'adhère à 100% avec ces propos. Et je pense même qu'on peut remplacer "programmation" par n'importe quoi.

@Pignata:
Mais pas de quoi, si ça a pu te faire réfléchir ou te débloquer d'une situation, ou que ça t'ait donné des idées, c'est le plus beau truc qui pouvait arriver :)

Guillaume
Pignata
Signaler
Pignata
L3 informatique et je comprend que je suis pas au niveau... eh bein ca fait plaisir que y'a du boulot à faire :)

je me suis posé la question pour le scrolling il y'a peu avec un pote, et la solution la voila !

merci pour le mal de tete et les com sont intéressant c'est sympas
hairaz
Signaler
hairaz
Pfff, si seulement il n'y avait que les articles d'intéressants sur votre blog ... Mais en plus, les commentaires sont pris d'assaut de développeurs qui viennent y discuter !
Évitant avec brio toutes les mauvaises comparaisons avec WOW et les conseils de refilement de dossiers à Pix ('n'love, cette fois-ci), je vais simplement vous féliciter pour ce blog.
Bon, je vous laisse, je viens de voir que le module chargé d'afficher la page suivante en-dessous de celle actuelle de FastestFox marche sur le blog de Wolfire, ce qui va me faire perdre des heures :wry:
Swing Swing Submarine
Signaler
Swing Swing Submarine
Yop Enimal!

Pour l'occlusion culling, Unity utilise Umbra Occlusion Booster.
(un petit tuto Occlusion Culling)
On voit que l'utilisateur doit poser des zones et dire ce qui est un occluder de ce qui ne l'est pas. Et tu places des potals pour indiquer comment les zones sont reliées entre elles.
Umbra prend en charge les objets marqués "static" dans Unity. Ce sont des objets dont tu garantis qu'ils ne seront pas déplacés lors de la session de jeu (je pense que ça doit même être impossible de les déplacer, même via un script).

Par contre pour le frustum culling, je suppose qu'ils se base sur les composants utilisés sur les objets. Genre leur outil de terrain doit surement utiliser un quadtree derrière. Mais il ne te le dis pas. C'est la magie Unity.

Pour les autres objets non statiques ... bah je sais pas trop :) C'est là encore la magie Unity qui opère. Peut être qu'ils confrontent directement les objets non statiques au frustum sans les organiser en grille... mais j'en doute.

Si quelqu'un à trouvé une doc qui indique comment ils cull leurs objets, je suis preneur.

Guillaume
Enimal
Signaler
Enimal
Houa, super article, et super complet.
Comme d'habitude j'ai pas tout compris, mais je vais le relire encore une fois.
Et sur unity comment ça fonctionne ?
Swing Swing Submarine
Signaler
Swing Swing Submarine
@MrMouche

Wouahou ! Respect !
J'avoue que je suis un Fan de PIX, même s'il est moins bien sur PC que sur XBox (pour laquelle il a été originellement développé il me semble ^^). C'est d'ailleurs pour ça (pour Pix) que j'ai choisi de développer avec une implémentation D3D du renderer, pour ensuite le porter pour Ogl. Je trouve les outils pour Ogl plus austères (ou payant, genre gDEBugger).

Le must des outils de la sorte ça reste GPAD pour PS3, c'est juste un truc de fou, pour l'avoir vu entre les mains d'un guru 3D, c'est assez bluffant.

2 ans d'XP sur Wii c'est toujours bon à prendre aussi !
Je suis honoré de rencontrer un senior programmeur de ta trempe :)


Guillaume
MrMouche
Signaler
MrMouche
@Guillaume : oui je connais bien les problemes d'optimisation 3D, j'ai bossé pendant quelques année sur le developpement d'un Debuger OpenGL/Direct3d pour chasser les appels redondants, les buffers trop souvent lockés, les culling 15 fois trop large, les objets plus utilisés mais encore en mémoire, identifier les bottleneck... bref, pleins de joyeusetés comme. ça nous a bien dépanné il y a quelques années mais depuis les outils comme Pix et NVperf sont devenu tellement complet qu'on a plus vraiment besoin d'un outil maison. Maintenant je m'occupe d'un moteur d'animation et entre temps j'ai bossé une paire d'année sur du developpement géneraliste sur Wii (juste pour la déconne :) )
Swing Swing Submarine
Signaler
Swing Swing Submarine
Salut Mayto !

C'est clair qu'Irrlicht gère pas mal de trucs... on aurait peut être du utiliser un moteur déjà existant mais on savait pas si tout allait être géré comme on le voulait pour notre approche 2D.
Du coup on simplifie pas mal de calculs du fait qu'on est dans une configuration bien spécifique :P Mais bon, faut toujours que les programmeurs recodent des trucs déjà existants... :( On dira que c'est pour garder la main !

Guillaume
Curious Planet
Signaler
Curious Planet
Superbe article !
Pour ma part Irrlicht se démerde tout seul avec la gestion de l'affichage ou non, et j'en suis bien content :P
Je sais que mes maps sont divisées en Octree pour le rendu, par contre j'ai l'impression que le moteur ne s'occupe pas de savoir si un objet (disons un personnage) est caché par un autre ou pas...

Et je ne connaissais pas la méthode de test que tu utilises sur tes AABB, je crois que je vais la garder dans un coin de ma tête, ça peut se révéler utile :)
Swing Swing Submarine
Signaler
Swing Swing Submarine
Hehe, merci CastorTroy!

Pour les problèmes, je pense qu'on a de quoi alimenter pas mal encore :P C'est pas ce qui manque ! On a des gros dossiers aussi sur des revirements de design et de techniques qui datent déjà du tout début du développement. Faudra qu'on prenne le temps de post-mortem-izer tout ça quand on en aura fini !

Guillaume
CastorTroy
Signaler
CastorTroy
Technique, mais très intéressant. Difficile parfois d'imaginer toutes les difficultés rencontrées afin de n'afficher rien qu'une image. Votre (Game!)blog est une très bonne illustration des différentes problématiques liées au développement d'un jeu vidéo (game design/QA, programmation/rendu, design graphique/sonore). Je n'ai qu'une envie, que vous rencontriez encore plus de problèmes pour nous faire part de vos solutions... bien qu'après réflexion je préfère que tout se passe bien pour enfin pouvoir jouer à Seasons ^^. Bonne continuation !
Swing Swing Submarine
Signaler
Swing Swing Submarine
Ahah grilled par MrMouche pour l'occlusion culling ! :) En plus c'est plus compréhensible que mon pavé !

@MrMouche
Merci pour ton retour... tu programmes un peu non ? T'as l'air d'être au courant niveau technique en tout cas !

Guillaume
Swing Swing Submarine
Signaler
Swing Swing Submarine
@Tenkai

Exactement, tu peux faire une demande d'occlusion à la carte graphique (GPU) (c'est pour ça que je dis que le culling c'est CPU la pluspart du temps).

Mais les occlusions Querry sont pas non plus supportées sur toutes les cartes (quoique aujourd'hui ça doit quand même le faire).

En gros les occlusions querry servent du coup à savoir si un objet en cache pas un autre. Dans Seasons on pourrait s'en servir pour par exemple éviter d'afficher un arbre qui se trouve entièrement caché derrière un autre. Mais que les 2 arbres sont "potentiellement" visibles à l'écran. Donc il est encore nécessaire de faire du frustum culling pour éliminer les objets hors champs (dont on est sûr qu'ils ne sont pas visibles).
En gros là dans Seasons, il est probable qu'on affiche des choses qui seront totalement masqués par des éléments plus proches... mais ça doit pas arriver souvent :)

Les occlusions query ça sert souvent par exemple pour les éclairages fake, pour savoir si on montre ou pas le petit halo lumineux au loin qui fait genre je suis une lumière alors que j'éclaire rien mais je fais un halo au loin.

Remarque très pertinente ! J'ai pas pensé de parler des occlusion querry dans le post (même si on ne s'en sert pas pour le moment)... peut être pour une prochaine fois !

Guillaume
MrMouche
Signaler
MrMouche
@Tenkai: occlusion culling exite encore en hardware, tu a raison, mais c'est une technique complementaire des autres méthode de culling, ça ne les remplaces pas. Il faut donc commencer par enlever sur CPU tout ce qui n'est pas dans le champ de la camera et apres seulement on peux essayer d'enlever les objets qui sont bien vu par le camera mais caché par les autres objets de la scene.
Swing Swing Submarine
Signaler
Swing Swing Submarine
@SeeDreeks: merci de venir le lire surtout! Je pense que partagé des connaissances (si modestes soient-elles au passage).
Moi même je lis le blog de Wolfire (http://blog.wolfire.com/) et j'y apprends des trucs, donc c'est un juste retour des choses :)

Guillaume
MrMouche
Signaler
MrMouche
Bravo, c'est une fois de plus tres bien expliqué et surtout bien illustré.

on en redemande, c'est tres interessant de voir le jeu se construire un peu plus à chaque article.
Tenkai
Signaler
Tenkai
Je vous cite :

"La chose principale que l'on essaie de faire lorsque l'on veut optimiser l'affichage, c'est de n'envoyer au rendu que les objets qui seront visibles depuis le point de vue de la caméra. Ça peut sembler logique mais c'est une chose qui n'est pas automatiquement gérée par un quelconque hardware. On doit donc prendre en charge tout cela du côté du moteur de jeu (côté CPU la plupart du temps) afin de d'alléger le rendu. On appelle le procéder le "culling" (l'élimination des parties cachées). "

Il me semblait que la carte accélératrice 3D "Power VR", à l'époque de la préhistoire de la 3D sur PC, gérait un truc du genre "occlusion culling", si ma mémoire ne me joue pas des tours.

Je pensais que le procédé avait été repris par les générations suivantes de CG, mais apparemment, vous dites le contraire. Je trouve cela très surprenant.

En tout cas merci pour l'article, c'est assez technique et les non-spécialistes peuvent s'y perdre un peu par moment, mais sinon, c'est vraiment très intéressant. :thumbsup:
Swing Swing Submarine
Signaler
Swing Swing Submarine
Salut Eska !

Merci pour ton feedback bien ou bien :P

C'est clair que Crysis doit être impressionnant niveau culling. J'ai bossé sur le CryEngine 1 à Ubi et déjà y'avait pas mal de trucs à l'époque... Mais dans le CryEngine version Crysis ça n'avait déjà plus rien à voir !
Genre pour streamer un max les textures, ils chargeaient les mipmap les plus petits d'abord, pour ensuite aller jusqu'au mipmap de plus forte résolution. Truc bien chiadé quoi :)

Au début dans Seasons on voulait avoir un monde ouvert où tout aurait été streamé, mais ça posait des problèmes de LD et Art (faire une transition entre une zone de plaine et une forêt de manière pas trop choquante sans qu'on est à marcher pendant des plombes...). Du coup avec une séparation en plusieurs niveaux on peut se permettre de faire des ellipses (couper un peut les transitions entre paysages) et d'avoir du LD plus vertical ou plus horizontal ou encore plus ou moins confiné.

Pour le moment j'ai laissé le streaming de côté, et je charge la librairie d'asset instanciales au démarrage du jeu, un peu à la Xna... mais faudra que je stream des choses quand même à terme :)


Les mecs de Crytek c'est juste des brutes ! (je me souviens avec émotion du code de Martin Mittring pour le rendu, ou encore du moteur physique écrit en russe ou ukrainien et aussi des optims hardcores de IVO, avec son fameux commentaire "Optimized by IVO" haha).

Bref, vous zêtes trop fort :) Ça doit surement venir de la bière !

Guillaume
SeeDreeks
Signaler
SeeDreeks
Non mais votre blog je crois que je vais me l'enregistrer en offline histoire de toujours l'avoir sous le coude tellement il recèle de choses intéressante. Je n'ai pas encore tout lu car je suis au boulot mais encore merci pour ce grand partage de connaissance.
EsKa
Signaler
EsKa
Excellent article Guillaume !

C'est très intéressant de voir les problématiques liées a la visibilité des objets dans un jeu a scrolling horizontal. De notre coté, dans Crysis 2, la visibilité des objets et leur chargement en mémoire ou "streaming" (comme on l'appelle dans les milieux chics) est assez complexe et nécessite l'utilisation de pas mal de méthodes (et d'insultes) avant d'en voir le bout.

Il faut jongler entre occlusion planes, l'occlusion automatique du terrain ou le layer streaming (technologie séculaire des moines bouddhistes de shaolin) qui nous permet de contrôler via des scripts quelle partie du niveau (ou layer) sera chargee en mémoire et/ou visible a quel instant de la progression du joueur dans le niveau. Et enfin, last but not least, les portails que tu mentionnais, ou "occlusion volumes", qui nous permettent par exemple de cacher l'intérieur d'un building lorsqu'on est a l'extérieur.

Bref, sans trop rentrer dans les détails, on a pas mal d'outils de notre coté entre lesquels il faut jongler pour arriver a réduire ces horribles millisecondes perdues sur l'affichage et la mise en mémoire des objets !

Mais franchement, respect (t'as vu ? Bien ou bien ?) pour avoir crée cela de toute piece ;)

Édito

Grâce à ce mini-devblog en français, vous pourrez suivre l'activité de notre minuscule studio de développement indépendant Swing Swing Submarine.

Nous sommes une petite équipe d'hommes et de chats passionnés qui souhaitent partager de nouvelles expériences interactives avec les joueurs du monde entier, et ceux de Gameblog en font bien évidemment partie !

--------------------------------------------------------

Quelques liens utiles :

> Site officiel <

> Twitter <

> Facebook <

Archives

Favoris