Discussion :

[bigkaktus]

Bonjour,

Je souhaite trouver une façon pour charger des données d'un fichier assez lourd de façon répétitive. Elles sont ensuite utilisées pour être affichées (coordonnées, normales etc... ) par openGL. Il y a plusieurs milliers de données à chaque fois.
Là, j'utilise un appel de fonction classique, et évidemment ce n'est pas très fluide (quoique acceptable), c'est vraiment le chargement du fichier le facteur ralentissant et non l'affichage.


J'ai deux questions :
- Je voudrais bien utiliser un thread mais je ne sais si c'est une bonne idée car ces données vont être affichées, il va y avoir partage de tableaux à moins de faire des doublons??
- Et aussi je ne vois pas comment attendre que les données soient complètement chargées avant de les faire afficher.

Merci pour vos conseils

[Médinoc]

J'ai du mal à comprendre.
Les données sont-elles chargées plusieurs fois ou une seule fois ?

[Alp]

Tu voudrais commencer à charger les données, afficher les données que tu viens de charger tout en continuant de charger celles qui n'ont pas été chargées du fichier ?

[bigkaktus]

Rebonjour,

Je vais essayer d'être plus clair.
Il s'agit d'afficher un terrain de très grande taille en dynamique.

A chaque passage, je calcule le frustrum view (valeurs limites vues par la camera) que je transcris en un rectangle, facile à afficher.
S'il change par rapport au frame précédent et bien je recharge les données correspondantes dans mon fichier plat.
A titre d'info, pour un terrain de 1000*1000 (petit terrain), le fichier fait déjà 23Mo.
La taille du fichier n'influe pas sur les performances (ou si peu).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
 
// Calcul du frustum de la vue
void Map :: calculateFrustrum() 
{   			
    static bool init_frustrum = true; // Indique si c'est le premier passage
 
    // Calcul du frustrum 
    /**********************************/
 
    // Si changement de vue ou premier passage 	
 
       if (c_ext != this->extremum || init_frustrum)
      {
                  // Nouveaux extremum et chargement des données                
                   this->extremum = c_ext;  // nouveau frustrum
                   loadDataFromFile();
	         init_frustrum = false;    // ce n'est plus le premier passage  
       }				
}
 
 
// Chargement des données (vertices/ normales) et calculs (couleurs etc..)
void Map :: loadDataFromFile()
{
    // Ouverture du fichier en lecture
    std::ifstream r_file("datamap.m3d",std::ios_base::binary);
 
    // Lectures des valeurs du fichier
    // x_min, x_max, z_min, z_max viennent du frustrum
    for (Uint32 z = z_min; z< z_max; ++z)      
    {
	     Uint32 first_value = z*MAP_SIZE + x_min;
 
	    // Les coordonnées d'abord     	   	    	      
                  r_file.seekg(3*sizeof(GLfloat)*first_value,std::ios_base::beg);
   	     r_file.read(reinterpret_cast<char*>(&this->vertices[3*delta_x*
                 (z-z_min)]),3*sizeof(GLfloat)*delta_x);  	 	   
 
	    // Ensuite les normales qui sont en fin de fichier
	    r_file.seekg(3*sizeof(GLfloat)*first_value + 3*sizeof(GLfloat)
                 *MAP_SIZE*MAP_SIZE,std::ios_base::beg);
   	     r_file.read(reinterpret_cast<char*>(&normals[3*delta_x*
                 (z-z_min)]),3*sizeof(GLfloat)*delta_x);  	 	      	
   }
 
    r_file.close();
 
 
          // Calculs de couleurs, d'indices etc...
          /******************************/
 
}

Les calculs ne ralentissent pas trop, ni l'affichage (j'utilise les vertex array avec indices)

Le facteur limitant est vraiment le chargement du fichier, pourtant j'essaie d'y accéder le moins possible quitte à charger plus de points.
C'est la boucle notamment, il peut y avoir 600 accès pour charger les coordonnées (vertices) et les normales (normals).


J'ai essayé par thread (et de mettre les calculs dans une autre fonction) mais j'ai eu des plantages et je suis obligé de faire deux tableaux de vertices, deux tableaux de couleurs, deux tableaux de textures etc...
(ou surtout je m'y prends comme une m****).

L'idée est effectivement de pouvoir afficher mes anciennes données tout en chargeant les nouvelles ... En faisant attention de ne pas lancer deux chargements en même temps.

[ram-0000]

Je ne connais pas ton environnement de travail mais si c'est du Microsoft, tu pourrais essayer de mapper ton fichier d'entrée en mémoire.

Les temps d'accès sont alors considérablerment meilleurs.

Quelques pointeurs:
* CreateFileMapping()
* MapViewOfFile()
* UnmapViewOfFile()

Attention, c'est des fonctions de l'API Microsoft

[bigkaktus]

Non, ce pas du microsoft, en fait j'aimerai bien que ça tourne sur Linux aussi . Je n'utilise que des librairies style SDL etc...

En gros tu me conseilles d'ordonner mon fichier, un peu comme une BD ?
C'est une idée que j'ai aussi, en fait partitionner ma grosse map en plusieurs sous parties dans mon fichier.
Et au lieu de faire mes requêtes, je me positionnerai à l'endroit souhaité et je chargerait tout le paquet en un coup (au lieu de boucler).

Les deux avantages sont :
- Pas besoin de recharger à chaque frame, il suffit de dépaser les valeurs critiques.
- Une super fluidité

Deux gros inconvénients :
- Ca va bouffer plus de RAM (de 20Mo à 60Mo .... ) j'ai testé avec un gros paquet de 1000*1000 pixels (lol).
- Un fichier énorme car évidemment certaines données seront redondantes (pour gérer les bords de mes partitions). Bon, est-ce-gênant?


Je vais tester plus en approfondi, je vais vraiment laisser tomber les threads pour ce genre d'actions (rofl).

Merci

[yan]

Bonjour,
tes points sont espacés régulièrement suivant (x,y)? (à condition que z est la hauteur)?

[edit]
tu trouve cela beaucoup 20Mo à 60Mo ??

[bigkaktus]

Mongaulois : oui. Plutôt (x,z) et y la hauteur (je trouve ça plus simple).
60Mo juste pour un terrain et une musique, oui je trouve que c'est pas mal.

C'est même plus pointu que ça la relation récupération/ affichage des points.
En fait je récupère bien les points par coordonnées (x,y1,z); (x+1,y2,z); (x+2,y3,z) ... (x,yn,z+1); (x+1,yn+1,z+1) etc... mais après je ne les affiche pas tous. J'utilise un "pas" qui fait que je ne peux qu'afficher qu'un point sur 4 par exemple.
Comment je fais? Au niveau des indices du vertex array, j'en mets simplement un sur 4 et effectivement, je gagne un peu de temps et j'envoie un drawElements().

Je vais essayer de faire ce système de parcellisation de map avec le fichier ordonné

[yan]

Mongaulois : oui. Plutôt (x,z) et y la hauteur (je trouve ça plus simple).
60Mo juste pour un terrain et une musique, oui je trouve que c'est pas mal.

C'est même plus pointu que ça la relation récupération/ affichage des points.
En fait je récupère bien les points par coordonnées (x,y1,z); (x+1,y2,z); (x+2,y3,z) ... (x,yn,z+1); (x+1,yn+1,z+1) etc... mais après je ne les affiche pas tous. J'utilise un "pas" qui fait que je ne peux qu'afficher qu'un point sur 4 par exemple.
Comment je fais? Au niveau des indices du vertex array, j'en mets simplement un sur 4 et effectivement, je gagne un peu de temps et j'envoie un drawElements().

Je vais essayer de faire ce système de parcellisation de map avec le fichier ordonné

Si je ne dit pas de connerie,
Tu peut donc stocké tes vertex dans une height map.
Une sorte d'image avec la hauteur comme valeur de pixel.
Tu pourra ensuite l'utiliser avec des vertex shader pour l'affichage.

[edit]
http://www.ozone3d.net/tutorials/ver...ing.php?lang=1
http://www.gamedev.net/columns/hardc...ph/default.asp