1

簡潔にしようと思います。私はiPhoneでOpenGLES2.0を使用しており、VertexBufferObjectを使用して画面上に一度に多くの形状をレンダリングしています。

一連のゼロ上向きのインデックスがに使用されGL_ELEMENT_ARRAY_BUFFER、これらは次の場所に格納されます。

GLushort *ixData;

各形状には頂点数があります。新しい形状が作成されると、合計頂点数'vxCount'がixDataのメモリを再割り当てするために使用されます。

NSLog(@"allocating ixData for %i shapes, %i vertices",shapes.size(),vxCount);
ixData = (GLushort*)realloc(ixData, vxCount*sizeof(GLushort));

もちろん、ixDataの初期mallocもあります。

各形状には6つの頂点属性（2つの位置、4つの色）があり、これらはすべてGLfloatです。各形状には、合計24個の頂点があります。vector<Shape>コードはC++であるため、形状はに格納されます。値vxCountは、この形状ベクトルのサイズに形状ごとの頂点の数を掛けることによって計算されます（つまりshapes.size()*24）。

各シェイプの位置はフレームごとに変わるため、各レンダリングでglDrawElementsを呼び出す直前にバッファデータを再送信します。

glBindBuffer(GL_ARRAY_BUFFER, buffers[0]);
glBufferData(GL_ARRAY_BUFFER, vxDataSize, vxData, GL_STATIC_DRAW);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, buffers[1]);
NSLog(@"render vxcount is %i",vxCount);
glBufferData(GL_ELEMENT_ARRAY_BUFFER, ixDataSize, ixData, GL_STATIC_DRAW); //*

このアプリは、508までの任意の数の図形に最適です。ただし、509番目の図形を追加しようとするEXC_BAD_ACCESSと、インデックスバッファーデータ用に取得されます。上記のコードでは、関連する行にアスタリスクが付いています。

上記のコードのNSLogプリントアウトを以下に示します。ご覧のとおり、最新の割り当てられた頂点カウントは、プリミティブインデックスの送信時のカウントと一致しています。

..。

2011-08-31 20：35：59.438 nibfree [26409：707] 503形状、12072頂点にixDataを割り当てます

2011-08-31 20：35：59.441 nibfree [26409：707] 504の形状、12096の頂点にixDataを割り当てます

2011-08-31 20：35：59.444 nibfree [26409：707] 505の形状、12120の頂点にixDataを割り当てます

2011-08-31 20：35：59.448 nibfree [26409：707] 506の形状、12144の頂点にixDataを割り当てます

2011-08-31 20：35：59.451 nibfree [26409：707] 507の形状、12168の頂点にixDataを割り当てます

2011-08-31 20：35：59.454 nibfree [26409：707] 508の形状、12192の頂点にixDataを割り当てます

2011-08-31 20：35：59.457 nibfree [26409：707] 509の形状、12216の頂点にixDataを割り当てます

2011-08-31 20：35：59.746 nibfree [26409：707]レンダリングvxcountは12216です

〜12kの頂点はデバイスにとって問題ではなく、インデックスデータのタイプは、 0〜65535のGLushort頂点インデックスが可能であることを意味します。

私は本当に困惑しています、誰かが何が間違っているのか推測できますか？iPhone固有の頂点/インデックスバッファの制限を超えていますか？

アップデート

洞察を追加するために、形状サイズを24頂点から12頂点に半分にしました。その後、再試行し、制限に達しました1536 shapes, 18432 vertices。シェイプごとに12の頂点を持つ1537のシェイプを追加しようとすると、以前と同じように。でクラッシュしEXC_BAD_ACCESSます。

この最新のテストは、vxData / ixDataストレージが問題ではなく、頂点または頂点インデックスの数に制限がないことを示しています。可能な形状の数はおよそ3倍に増加しました-これは、私が遭遇しているGL_TRIANGLESレンダリングの癖を示唆していますか？それとも、reallocの誤用ですか？なぜそれが問題なのかよくわかりません:(

更新2

パターンを見つけるための別の数字のセット：300の頂点には最大61の形状があり、62はクラッシュを引き起こします。62には、vxcount 18300、最後のixDataインデックス18299があります。

4

1 に答える 1

3

アップロード時のEXC_BAD_ACCESSは、GLドライバーがアプリケーションが所有していないメモリを読み取ろうとしたときに発生する可能性があります。したがって、のixDataSize値が。より大きい可能性がありますvxCount*sizeof(GLushort)。このような問題は、バッファサイズが小さいと発見されなかった可能性がありixDataSizeます。これは、そのような場合に考えているのは、アプリケーションに指定された領域の外では実行されず、実際に必要な数よりも大きいため、すべてのデータが使用に進むとコピーされます。

于 2011-08-31T21:48:49.973 に答える