Tout charger ou pas ?

[PhM]

Je redémarre ici pour ne pas polluer plus le sujet où la discussion à débuté.

Certes, mais nous ne sommes pas dans Unreal ici et je doute fort que X-Plane utilise le moteur de rendu de ces logiciels 3D

Nous sommes bien d'accord, le lien visait à donner de l'information pour ceux qui pourraient être intéressés par le sujet.

Certes ! mais comme dans X-Plane, contrairement à Unreal, le champ de vision porte loin (voire très loin), la caméra doit voir … plus loin qu'une seule tuile !!

Unreal ne fixe pas ce qui est vu ou non, c'est le programmeur qui utilise Unreal qui le fait. S'il souhaite voir loin il positionne sa caméra en fonction de ses désirs.

...Certes, les tuiles lointaines seront dans un premier temps affichées en très basse résolution, mais pour pouvoir les afficher, même dans cette basse résolution, il faut bien les avoir lues !

J'ai dit : "...on ne charge que ce qui est nécessaire pour générer l'image que l'on va avoir sur l'écran à un moment donné.". Cela ne veut pas dire que l'on ne charge pas ce qui se situe au loin. Ce qui est nécessaire, pas plus, pas moins. Ce qui implique, par exemple, de ne lire que les textures basse résolution contenues dans le fichier dds et pas tout le fichier incluant toutes les résolutions intermédiaires et de ne pas avoir en mémoire ce qui est hors du champ de la caméra.

A un moment donné correspond une orientation de la caméra et seulement un ensemble d'éléments visibles. Ce qui est visible se situe dans le volume défini comme le view frustum dans cette image. Si la caméra change de position alors le streaming va chercher ce qui est nécessaire pour les rendus suivants et libère ce qui n'est plus nécessaire.

Donc dans ton exemple si l'on se suppose centré sur +46+006 en regardant vers l'ouest nous ne pourrons pas voir d'éléments provenant de +47+007, +46+007, et +45+007, et nous ne verrons probablement pas grand chose de +47+006 et +45+006. Et si l'on regarde vers l'est alors +47+005, +46+005, et +45+005 ne sont plus visible. De même en regardant nord-ouest +47+007, +46+007, +45+007, +45+006 et +45+005 ne sont plus visibles, cinq tuiles sur neuf au total.

PhM

[Glah_Salamanthe]

Ce qui implique, par exemple, de ne lire que les textures basse résolution contenues dans le fichier dds et pas tout le fichier incluant toutes les résolutions intermédiaires

Entièrement d'accord, d'ailleurs je l'ai dit récemment dans un post (que je ne retrouve plus …)
[EDIT] … retrouvé !
C'est d'ailleurs à toi que je disais (dans le post "plantage en quittant"):

On peut le voir dans certains jeux où le streaming de texture est parfois en retard et où l'on voit une texture basse résolution sur un objet proche passer en haute résolution.

Pas besoin d'aller ailleurs, tu le constates dans X-Plane aussi !

Unreal ne fixe pas ce qui est vu ou non, c'est le programmeur qui utilise Unreal qui le fait. S'il souhaite voir loin il positionne sa caméra en fonction de ses désirs.

Effectivement, mais dans ce genre de jeu, le champ de vision n'a rarement besoin de porter à plus de 2 kilomètres, en encore, c'est un peu loin pour un snipper

A un moment donné correspond une orientation de la caméra et seulement un ensemble d'éléments visibles. Ce qui est visible se situe dans le volume défini comme le view frustum dans cette image. Si la caméra change de position alors le streaming va chercher ce qui est nécessaire pour les rendus suivants et libère ce qui n'est plus nécessaire.PhM

C'est vrai … mais si, équipé d'un Trackir, tu effectues un 360°, je doute fort que le programme ait le temps nécessaire d'aller lire les données sur ton disque dur pour permettre de suivre ton regard en rotation (à moins d'avoir un SSD et encore)
Il est donc indispensable que les données graphiques autour de toi soient déjà en mémoire ! peut-être en tampon dans la DDR3, mais déjà lues du disque de façon à être très rapidement disponibles (1 à 2 secondes), car ce n'est pas que l'affichage des tuiles qui doit être disponible, mais aussi les bâtiments qui constituent les agglomérations (même à très très basse résolution) : il ne s'agit donc pas de juste afficher une image de sol, mais bien de "reconstituer" une scène !

[PhM]

...Pas besoin d'aller ailleurs, tu le constates dans X-Plane aussi !

La différence dont il est question dans la discussion réside dans la façon de le faire, avoir tout les différents niveau de résolution toujours présents en mémoire ou les charger quand ils vont être nécessaires.

...Effectivement, mais dans ce genre de jeu, le champ de vision n'a rarement besoin de porter à plus de 2 kilomètres, en encore, c'est un peu loin pour un snipper

Je ne parlais pas d'un genre de jeu mais de l'utilisation d'un moteur graphique, du fait que ce n'est pas le moteur qui décide de ce qui est vu ou non mais l'utilisateur. Accessoirement voir ici, les images parlent d'elles mêmes.

C'est vrai … mais si, équipé d'un Trackir, tu effectues un 360°, je doute fort que le programme ait le temps nécessaire d'aller lire les données sur ton disque dur pour permettre de suivre ton regard en rotation (à moins d'avoir un SSD et encore)

C'est un cas particulier, c'est le cas le plus défavorable pour le streaming.

• Vaut-il mieux se focaliser sur un cas particulier ou le cas général ?
• Quel est l'utilisation majoritaire d'un simulateur de vol, faire des 360 avec un track IR ou modéliser au mieux le vol ?
• Veut-on mobiliser des resources pour garder beaucoup de chose dont on aura peut-être pas besoin ou les utiliser pour ajouter du contenu à l'écran ?
• Dans le cas de mouvements très rapides est-ce que des textures basse résolution défilant très rapidement au lieu d'une résolution plus haute sont suffisantes ?
• Dans ce même cas est-il utile d'avoir un mesh le plus fin possible alors que le mouvement rendra les détails impossibles à voir ?
• Si l'on utilise du motion blur cela ne va-t-il pas aider dans ces cas particuliers ?
• etc.

Il est donc indispensable que les données graphiques autour de toi soient déjà en mémoire ! peut-être en tampon dans la DDR3, mais déjà lues du disque de façon à être très rapidement disponibles (1 à 2 secondes), car ce n'est pas que l'affichage des tuiles qui doit être disponible, mais aussi les bâtiments qui constituent les agglomérations (même à très très basse résolution) : il ne s'agit donc pas de juste afficher une image de sol, mais bien de "reconstituer" une scène !

Je n'ai pas abordé tous les détails, mais effectivement c'est tout ce qui est dans les fichier DSF qui doit être considéré. Il est également évident que la façon de déterminer ce que l'on garde et ce que l'on libère inclu le fait de prévoir ce qui va être utilisé dans un futur proche, et comment organiser un hiérarchie mémoire, un peu comme celle en place avec les caches CPU mais à un niveau supérieur, etc. Tu trouveras certainement beaucoup de lecture sur le net qui te détailleront comment fonctionne un tel système. Tu peux également t'intéresser au geometry clip mapping par exemple.

Au final on peut être partisan du je charge tout ou pas. En tant qu'utilisateur on n'y peut rien, on ne peut qu'en subir les conséquences. En tant que concepteur c'est une autre histoire.

PhM

[PhM]

Un aperçu de ce que fait Microsoft.

PhM