Управление государственным управлением OpenGL

Question

В настоящее время я работаю над небольшой игрой для iPhone и переношу 3D-движок, который я начал разрабатывать для Mac на iPhone. Все это происходит очень хорошо, и вся функциональность движка Mac теперь присутствует на iPhone. Двигатель был отнюдь не закончен, но теперь, по крайней мере, у меня есть основное управление ресурсами, график сцены и конструкция, которые легко оживляют и перемещают объекты вокруг.

Снимок экрана из того, что у меня есть сейчас: http://emle.nl/forumpics/site/planes_grid.png. Маленький самолет - это тестовый объект, который я сделал несколько лет назад для игры, которую я делал тогда. Это не связано с игрой, которую я сейчас разрабатываю, но, конечно, 3-й движок и его средства.

Теперь я пришел к теме материалов, описание которых текстуры, огни и т. Д. Относятся к рендерируемому объекту. Это означает, что много запросов OpenGL clientstate и glEnable/glDisable для каждого объекта. Каким образом вы бы предложили минимизировать эти изменения состояния? В настоящее время я сортирую по материалам, так как объекты с одним и тем же материалом вообще не нуждаются в каких-либо изменениях. Я создал класс RenderState, который кэширует текущее состояние OpenGL и применяет только те элементы, которые отличаются при выборе другого материала. Является ли это работоспособным решением, или оно будет выходить за рамки контроля, когда двигатель созревает, и все больше и больше состояний нужно кэшировать?

Answer 1

Если количество состояний в OpenGL ES выше стандартной версии, в какой-то момент будет сложно управлять.

Кроме того, если вы действительно хотите свести к минимуму изменения состояния, вам может понадобиться какая-то концепция сортировки состояний, так что чертежи с похожими состояниями будут отображаться вместе без необходимости использования glEnable/glDisable между ними. Однако это может быть сложно справиться даже с аппаратным обеспечением ПК (представьте себе, что сортировка тысяч тысяч чертежей), и слепое изменение состояния может быть дешевле, в зависимости от реализации OpenGL.

Для сравнения, вот подход, OpenSceneGraph:

В принципе, каждый узел графа сцены имеет свой собственный stateset, который сохраняет свойство материала, состояние и т.д. Хорошая вещь в том, что statesets могут быть разделены несколько узлов. Таким образом, бэкэнд рендеринга может просто сортировать чертежи по отношению к их указателям на штатные элементы (а не по содержимому штатива!) И отображать узлы с одним и тем же множеством состояний. Это дает хороший компромисс, поскольку бэкэнд не беспокоится об управлении отдельными состояниями opengl, но может достичь почти минимального изменения состояния, если сгенерирован сценарий.

Что я предлагаю, в вашем случае вам нужно провести много испытаний, прежде чем приступать к решению. Что бы вы ни делали, я уверен, что вам понадобится какая-то абстракция для состояний OpenGL.

Answer 2

Немного совета. Просто напишите код, необходимый для вашей игры. Не тратьте время на создание обобщенного механизма рендеринга, потому что это более чем вероятно, вам это не понадобится. Если вы закончите писать другую игру, извлеките полезные биты в движок в этот момент. Это будет быстрее.