Strategically advantageous position cocos2d-x-3.0 architecture Design cocos2d (v.3.0) Rendering Pipeline Roadmap (original)

Cocos2d (v.3.0) rendering pipeline Roadmap

Why (The Vision)

The currently cocos2d does rendering is good but it's beginning to feel somehow antiquate and moreover

It doesn't actually leverage modern multi core CPUs so popular nowadays on most modern tablets and Mobil E phones.

So we want to re-design Cocos renderer, for making it more performing, elegant, scalable, flexible but still

Use and to understand. Also we want to maintain this same familiar API that current cocos2d users would feel immediately

Comfortable with, without has to bother about what's changed or new under the hood.

We'll do this maintaining the same key Cornerstone concepts cocos2d users get to know and like as Scenes,

Nodes, Layers, Sprites.

What (the Goals)

Here are a high level view of the new features and improvements we would like to achieve in cocos2d v.3.0:

Decouple the scene graph from the renderer

Visiting nodes issues graphics commands and put them on a queue, but doesn'T actually invoke any OpenGL

Rendering code

viewing frustum Geometry Culling

Sprites (and geometries more in general) is not visible from the Camera's point of view is automatically re Moved

From the current frame and not rendered

Rendering on a thread

The execution of all the rendering commands (i.e. OpenGL calls) would be moved to different thread than the main

One (this would allow for better parallelism and the usage of more than one CPUs cores where possible)

Automatic Batching

Efficiently reduces the number of draw calls (automatically) batching them together when possible (i.e. sprites

Using the same material)

(Node based) Customizable rendering

As in the current version of Cocos, users would still be able (if needed) to customize rendering on a per node basis

, calling OpenGL commands directly, disregarding the official renderer (but possibly incurring on worst performances)

How (The plan)

Central to the new design is the notion commandqueue. While visiting a node, rendering won't call OpenGL

Commands directly anymore (as currently is the case); It'll instead push cocosgraphicscommands to a queue.

Commands in the queue would subsequently is read by the rendering backend, processed as needed and pushed

To the actual rendering API (i.e. OpenGL)

The rendering backend (running on his own thread) would in turn POPs graphics commands from the queue, process

them and actually execute them. Any locking or CPU expensive OpenGL commands would be is then executed from the

Back-end thread, letting Cocos' main thread free continue working on parsing the scene graph or doing O ther non

Rendering related tasks. This would help parallelism and would allow for using multi core CPU's (see picture)

With Cocos2d-x 3.00 We also want to introduce the concept of automatic-batching. In fact we believe reducing the number of draw calls and render device state changes would improve

Drastically rendering speed.

In order to achieve very good batching, we would like to introduce also a new concept of "attributes " for Layers

(formally Cclayer). There is going to (at least) 3 new Layer attributes:

Unordered

Static

Batch

Unordered Layer (formally Cclayer)

We want now focus on Unordered Layers, which is going to help achieving auto batching for improving rendering

Performance.

Rendering order in cocos2d was dictated by the "order" nodes be arranged in the scene Graph (see picture)

This is still going to being true still in v.3.0 unless the Layer is tagged as Unordered.

The Unordered attribute would instruct the Layer to disregard rendering order for

All of his children

The graphics commands'll then being put in the commandqueue and a special "unordered tag" would be PLA Ce

In the command queue as-instructing the rendered to disregard the order and re arrange graphics command S

So-to-render all the primitives using the same material on one draw call. Rendering All Primitives

Same "material") in one go to makerendering much faster, especially on mobile Devic Es.

Static Layer

Layers tagged as static, would is treated as if all children would not going to be translated/rotated/zoomed

(transformed) during the entire lifespan of the layer.

This would allow Cocos performing expensive operations as matrices concatenation or computing culling

Information (i.e Quad-tree) only once (typically before the first rendering pass) improving drastically

Performance. Note that sprites in a static Layer can still is "animated" as far as they' re not transformed or scaled.

Batch Layer

A batch layers would behave very similarly to how a batch Node (Ccbatchnode) currently works in Cocos2d.

All the children of a batch layer would have the same "material" thus allowing the FR Ont end to combine

All the draw calls is the. (erroneously) Adding children that use a different material to

A Batch Layer would trigger an Assert ().

Automatic culling

To do

Rendering context (Renderbucket, RenderTarget, Camera,

Viewport

To do

Rendering and Materials System

To do

Customize Rendering for nodes

To do

Strategically advantageous position cocos2d-x-3.0 architecture Design cocos2d (v.3.0) Rendering Pipeline Roadmap (original)