Définition d'un tableau statique de flottants en C++

Question

Je travaille sur un outil de génération de planètes en C++ et actuellement j'essaie de générer des textures et des heightmaps. J'utilise une fonction de bruit perlian 3d pour cela, donc chaque fois que je génère une texture ou heightmap je vais calculer la valeur de la fonction de bruit pour chaque sommet sur la surface de la sphère.

Ces coordonnées ne changent pas. À l'origine je calculais ces derniers en mappant un cube à une sphère en utilisant this method. Je pensais alors bien si je sais que ces valeurs vont être les mêmes à chaque fois, pourquoi ne pas les calculer une fois et les sortir dans un fichier d'en-tête où elles peuvent être définies comme des tableaux statiques.

Je veux créer des textures de 512x512, cela signifie 260,000+ co coordonnées sont générées par face :(

Les coordonnées de co résultantes ont été stockées dans un tableau:

float textureMapSaved[6][512][512][3] = {etc}; 

Comme le cube a 6 faces, 512x512 pixels par face et 3 co-ordonnées (x, y & z)

Cela je l'espère me permettra alors que la boucle à travers le réseau obtenir la co ordonnée de la valeur dans la fonction du bruit perlian que je suis intéressé.

Jusqu'à présent, je n'ai réussi à transformer mon ordinateur en chialer désordre.

Ma question est:

Y at-il un moyen viable de le faire?

Sans créer le fichier de sortie, le programme prend environ 15 minutes pour calculer la sphère. Je ne pouvais pas vraiment compiler avec l'en-tête, il a crashé mon ordinateur. J'ai ensuite essayé 256x256 et cela a fonctionné un peu mieux mais mon ordinateur continuait de caler; Je suppose que c'est parce qu'il ne peut pas allouer de la mémoire pour le tableau 4D efficacement.

---

Merci pour les réponses rapides!

En ce moment je suis en train de faire ce qui suit:

std::vector<std::vector<std::vector<std::vector<float>>>> textureFaces = GenerateSphereCoordinates(TEXTURE_MAP); 

std::ofstream myfile; 
myfile.open ("spheremapping.h"); 
myfile << "#ifndef _SPHEREMAP \n#define _SPHEREMAP \n\nfloat textureMapSaved[6][" << textureRes << "][" << textureRes << "][3] = {"; 
for(int i = 0; i < 6; i++) 
{ 
    myfile << "{"; 
    for(int j = 0; j < textureRes; j++) 
    { 
     myfile << "{"; 
     for(int k = 0; k < textureRes; k++) 
     { 
      if(k != textureRes - 1) 
      { 
       myfile << "{ " << textureFaces[i][j][k][0] << ", " << textureFaces[i][j][k][1] << ", " << textureFaces[i][j][k][2] << "}, " ;    
      } 
      else 
      { 
       myfile << "{ " << textureFaces[i][j][k][0] << ", " << textureFaces[i][j][k][1] << ", " << textureFaces[i][j][k][2] << "}" ; 
      } 
     } 
     if(j != textureRes - 1) 
     { 
      myfile << "}, \n"; 
     } 
     else 
     { 
      myfile << "} \n"; 
     } 
    } 
    if(i != 5) 
    { 
     myfile << "}, \n\n"; 
    } 
    else 
    { 
     myfile << "} \n\n"; 
    } 
} 
myfile << "};\n\n#endif"; 
myfile.close(); 

Comment puis-je enregistrer comme un fichier binaire et le lire directement dans la mémoire?

Answer 1

La méthode que vous décrivez est la meilleure combinaison d'efficacité et de simplicité. Si votre compilateur ne peut pas gérer toute la définition de tableau en une fois, divisez le problème en plusieurs parties.Par exemple:

typedef float CubeFace[512][512][3]; 
CubeFace face1 = {etc}; 
... 
CubeFace * textureMapSaved[6] = {&face1, &face2, &face3, &face4, &face5, &face6}; 

Comme alternative, arrêter d'essayer de faire de votre définition d'un fichier texte compilable et en faire un fichier binaire. Vous pouvez le lire en mémoire en une opération ou en faire un fichier mappé en mémoire et laisser le système d'exploitation l'échanger si nécessaire.

Answer 2

Sauvegardez vos visages séparément. Aussi, je doute sérieusement que vous ayez besoin de trois coordonnées par pixel; Je parie qu'un seul scalaire, combiné avec les valeurs inhérentes x, y dans les coordonnées du tableau, serait suffisant.

Answer 3

Comme d'autres l'ont fait remarquer, la taille du tableau n'est pas une grosse affaire. Quelque chose d'autre ne va pas, par ex. vous avez essayé de mettre ceci sur la pile comme une variable automatique.

J'ajouterai que lorsque l'on travaille avec des ensembles de données de cette taille, l'efficacité du cache joue un grand rôle dans les performances. Votre algorithme devrait essayer de faire deux choses: 1) Garder les lectures de tableau groupées les unes près des autres à la fois en temps et en adresse mémoire. Cela signifie ne pas sauter dans les dimensions d'ordre élevé, par ex. faces de cube, jusqu'à ce que vous ayez fini de traiter les dimensions de poids faible, par ex. sommets individuels. Réorganisez les dimensions du tableau selon les besoins pour y parvenir. 2) Essayez de toucher la matrice dans un modèle incrémentiel prévisible en termes d'adresse mémoire. Cela permet aux préextracteurs de cache de mettre les données dans le cache de manière proactive à l'avance.

Vous pourriez aussi vous amuser en divisant le travail en tâches parallèles.