Каким образом cocos2d-x и cocos2d-iphone гарантируют правильный зордер (окклюзию) для одной партии из 2 спрайтов? - PullRequest
0 голосов
/ 29 июня 2018

Для 2-го рисунка окклюзия выполняется по порядку нанесения. Более поздний из них закроет прежний. Но когда все рисование выполняется за один вызов, как cocos2d-x (и cocos2d iphone для spriteBatchNode) гарантируют правильную окклюзию?

Простой пример, спрайт B и спрайт C оба находятся под узлом A. Они имеют одинаковую текстуру, шейдер, blendFunc, что позволяет оптимизировать их с помощью системы автоматического пакетного рендеринга cocos2d-x 3.x ( В случае с cocos2d-iphone они используют ту же таблицу спрайтов, что и текстура, и под одним и тем же spriteBatchNode) и рисуются одним вызовом glDrawElements. AFAIK, тест глубины отключен для gles в этот момент. Если мы хотим, чтобы спрайт C покрывал спрайт B, мы должны сначала нарисовать B, а затем C. Но теперь они нарисованы вместе. Как система рендеринга может гарантировать правильную окклюзию C и B?

Пожалуйста, поправьте меня, если я допустил ошибку.

1 Ответ

0 голосов
/ 02 июля 2018

Я нашел следующую цитату в спецификации OpenGL «Это означает, например, что один примитив должен быть нарисован полностью, прежде чем любой последующий может повлиять на кадровый буфер» https://www.khronos.org/registry/OpenGL/specs/es/3.2/es_spec_3.2.pdf

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

Ссылки:

https://www.opengl.org/discussion_boards/showthread.php/176630-Rendering-order-within-a-single-draw-call

https://forums.imgtec.com/t/order-of-operation-for-vertex-arrays/787

Наконец, хотя B и C нарисованы в одном glDrawElements, их примитивы имеют другой порядок в массиве вершин. Таким образом, в Cocos2d-x один с более низким localZOrder будет нарисован раньше, чем с более высоким localZOrder. Они на самом деле не объединены.

...