Что касается моделей, я думаю, что подход, аналогичный соотношению между UIImage и UIImageView, уместен. Таким образом, у каждого типа кирпича есть один буфер вершин, GLKBaseEffect, текстура и все остальное. Каждый кирпич может появиться несколько раз, так же как несколько UIImageViews могут использовать один и тот же UIImage. С точки зрения сохранения нескольких опорных кадров, на самом деле очень хорошая идея построить иерархию, по существу эквивалентную UIView, каждая из которых содержит некоторое преобразование относительно родителя и один вид, способный отображать модель.
Из документации GLKit я думаю, что лучший способ сохранить вид камеры, которую вы хотите (и, в действительности, расположение объектов), это сохранить ее непосредственно как GLKMatrix4 или GLKQuaternion - так что вы не получите матрица или кватернион (плюс местоположение) из какого-либо другого описания камеры, точнее, матрица или кватернион непосредственно являются хранилищем для камеры.
Оба этих класса имеют встроенные методы для применения поворотов, и GLKMatrix4 может напрямую обрабатывать переводы. Таким образом, вы можете напрямую связать соответствующие жесты с этими функциями.
Единственная немного неочевидная вещь, о которой я могу подумать, имея дело с камерой таким образом, - это то, что вы хотите отправить инверсию в OpenGL, а не саму вещь. Предположим, что вы используете матрицу, причина в том, что если вы хотите нарисовать объект в этом месте, вы бы загрузили матрицу напрямую, а затем нарисовали объект. Когда вы рисуете объект в том же месте, что и камера, вы хотите, чтобы он в конечном итоге был нарисован в начале координат. Таким образом, матрица, которую вы должны загрузить для камеры, является обратной матрицей, которую вы загружаете, чтобы нарисовать в этом месте, потому что вы хотите, чтобы два умноженных вместе были матрицей тождества.
Я не уверен, насколько сложны модели для ваших кирпичей, но вы можете столкнуться с узким местом в производительности, если они простые и все движутся совершенно независимо. Общее правило при работе с OpenGL гласит: чем больше геометрии вы можете отправить одновременно, тем быстрее все пойдет. Так, например, полностью статичный мир, подобный тому, что в большинстве игр гораздо проще рисовать эффективно, чем мир, в котором все может двигаться независимо. Если вы рисуете шестигранные кубы и перемещаете их все независимо, производительность может быть хуже, чем вы ожидаете.
Если у вас есть какие-то кирпичи, которые движутся согласованно, то более эффективно рисовать их как один кусок геометрии. Если у вас есть какие-то кирпичи, которые определенно не видны, даже не пытайтесь их рисовать. Начиная с iOS 5, GL_EXT_occlusion_query_boolean доступен, что позволяет передавать некоторую геометрию в OpenGL и спрашивать, видна ли какая-либо из них. Вы можете использовать это в сценах в реальном времени, создав иерархическую структуру, описывающую ваши данные (которая у вас уже будет, если вы непосредственно следовали аналогии UIView), вычислили или сохранили некоторую ограничивающую геометрию для каждого вида и выполнили отрисовку, только если запрос окклюзии предполагает, что хотя бы некоторая ограничивающая геометрия была бы видимой. Следуя такой логике, вы часто можете отбросить большие участки вашей геометрии задолго до ее отправки.