OpenGLES2 iOS: Wie kann man die Vertex-Animation für dynamisches Terrain am besten streamen?

Question

Ich schreibe eine App, die ein dynamisches 640 * 480 Terrain erstellt (ändert jeden Frame). Jedes Gelände wird in einer Rohdatendatei gespeichert, die eine Folge von (Fließ-) Höhenwerten darstellt. Bis jetzt kann ich die Dateien nacheinander in den Speicher lesen und dynamisch ein Mesh basierend auf den Höhenwerten für jeden Frame erstellen (und die Framerate ist eigentlich vernünftig), aber ich maximiere 20 Frames, bevor meine App ohne Fehler oder Stack beendet wird Spur.

Ich vermute, dass ich das falsch annähere. Wie würde ich diese Daten streamen, so dass ich nicht jeden Frame im Speicher halten muss? Hier

ist ein Ausschnitt aus meiner Datenklasse, die eine Sammlung von Terrains hält:

- (void)addModelWithID:(int)modelID; 
{ 
    NSString* resourcePath = [[NSBundle mainBundle] resourcePath]; 
    NSString* fileName  = [NSString stringWithFormat:@"depth_%i.raw", modelID]; 
    NSString* fullPath = [resourcePath stringByAppendingPathComponent:fileName]; 

    NSData *myData = [NSData dataWithContentsOfFile:fullPath]; 
    if (!myData) 
     return; 

    const float *data = [myData bytes]; 

    int meshWidth    = 640; 
    int meshHeight    = 480; 

    Model *kModel = [[Model alloc] init]; 

    int indicesPtr = 0; 
    int depthPtr = 2; 

    for (int y=0;y<meshHeight;y++) // Loop through y pixels 
     { 
      for (int x=0;x<meshWidth;x++) // Loop through x pixels 
      { 
       // Set up vertex positions 
       int index = y*meshWidth+x; 
       float xpos = ((float)x/(float)(meshWidth-1)) - 0.5f; 
       float ypos = ((float)y/(float)(meshHeight-1)) - 0.5f; 
       float zpos = (float)data[index]; 

       kModel.vertices1[index*3+0] = xpos; 
       kModel.vertices1[index*3+1] = ypos; 
       kModel.vertices1[index*3+2] = zpos; 

       // Create a new index based on whether the current line is even or odd (flipped horizontally if odd) 
       int _index = (y%2==0) ? index : (y*meshWidth) + ((meshWidth-1)-x); 

       //Create the first index 
       kModel.indices[indicesPtr++] = _index; 

       // Create the second index 
       if ((x<meshWidth-1) || (x==meshWidth-1 && y==meshHeight-2)) 
        kModel.indices[indicesPtr++] = _index+meshWidth; 
      } 
     } 
    } 

    // Add the model to the data object 
    [Models addObject:kModel]; 
    [kModel release]; 
} 

Und meinen Draw-Code (jeden Frame ich ein anderes Terrain nennen, hoffentlich bis zu 500 oder so, aber ich max out bei ~ 20:

{ 
    ... 
     Model *kModel = [kData.kinectModels objectAtIndex:sequenceCurrentFrame]; 

     glVertexAttribPointer(vertexHandle, 3, GL_FLOAT, GL_FALSE, 0, (const GLvoid*)kModel.vertices1); 

     glEnableVertexAttribArray(vertexHandle); 

     glUniformMatrix4fv(mvpMatrixHandle, 1, GL_FALSE, (const GLfloat*)&modelViewProjection.data[0]); 
     glDrawElements(GL_TRIANGLE_STRIP, kModel.numIndices, GL_UNSIGNED_SHORT, (const GLvoid*)kModel.indices); 
    ... 
} 

Dank einer Million für Ihre Hilfe,

Josh

Answer 1

Sie können Ihre Höhendaten in einer Textur speichern und dann im Vertex-Shader die Funktion texture2D verwenden, um die aktuelle Höhe des Eckpunkts zu ändern.

Mit dieser Konfiguration können Sie ein einzelnes Netz haben und die Höhe jedes Eckpunkts einfach um den in der Textur gespeicherten Wert anpassen.

Wenn Sie sicher sind, dass Sie GPU-gebunden sind, kann das Texturformat, das zum Nachschlagen der Höhendaten verwendet wird, weiter optimiert werden. Nehmen wir an, Ihre Heightmap reicht von 0-255, beim Format GL_RGBA können Sie die gleiche Textur für das Rendern von bis zu 4 Frames verwenden (erstes Frame liest die Höhe von der roten Komponente, nächstes Frame von der blauen Komponente usw.). Durch die doppelt so große Hintergrundtextur (1280x960) können Sie bis zu 16 Bilder in einer einzigen Textur speichern. Eine weitere Sache, die in Bezug auf Texturen erwähnenswert ist, ist, dass die Verwendung des nativen Formats für Ihre GPU auch die Leistung in beiden GPU/IO-gebundenen Szenarien verbessern kann. Für iDevices ist dieses Format PVRTC.

Ich glaube wirklich, dass das Problem ist nur die Zuordnung von 300k + Ecken jeder Rahmen allein ..., die jeden Rahmen zugeordnet 640 * 480 * 3 * 4 = 3 686 400 Bytes addiert und Sie nicht erwähnt Nach wie vielen Frames hören Sie auf, den Speicher zuzuweisen (warten Sie ... tun Sie?). Das ist viel zu viel für eine solche ressourcenbeschränkte Umgebung.