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