Proposal for v3.0: new rendering pipeline

cocos2d-x C++
#21

Sounds good to me :slight_smile:

#22

That’s an interesting idea. In fact, I was thinking about this when I was talking about the key-value pair draw calls. However, don’t you need 2 values in order to represent a global z order (tree level and child index)? So for example node E in your example has a tree level of 2 and a child index of 1. Also, wouldn’t you have to re-calculate the z order of a node hierarchy every time you add a child to it?

By the way I’ve noticed that you are using a key in the new RenderCommand object that you then use to sort all render commands. Are you going to encode the global z order on the key?

#23

@nick

I was thinking something like this:

// f and g are siblings
f->setZOrder(100);
g->setZOrder(200);

// to render something between them, you should do
e->setZOrder(150);

Yes, the Z-order value will be used as part of the key to sort the “render commands” in the render queue.

#24

+1 Global Z order.
2.5D extension also need this.

#25

+100 for global Z order.
I’m really looking at possibility of modifying current 3.0alpha to get that right now, even thou I’m not yet sure how hard it could be. That tempting it is, and that needed in some situations.
(offtopic: can I get some advice on how to go with it? some pitfalls maybe?)

Yet ideally user should choose a model for himself. Not all type of games require such a thing, it could get overcomplicated easily.

I believe its possible to simulate old ordering behaviour with GlobalZOrder.

My proposal:
If user chooses a simple mode: before rendering each object gets from its parent a range of Zorder values available (root gets full range, maximum value, and divides it between children) which child gets what range depends on child’s local ZOrder value - lowest values get lowest “subranges” in parents range. Range division could be affected by totalChildernCount that is automatically accumulated while childrens and their childrens are added or removed. It takes some simple math and several quick loops and I believe that it wont affect execution drastically, leaving simplicity for those who crave it.

#26

Thanks `Bulat

I haven’t updated this thread in a few days, but I sort of “evolved” the `setZOrder()@ thing.

Instead of using setZOrder() as the global Z, I think it is better to use setVertexZ() (already part of cocos2d-x), and sort by that key.

So, the sort key would be something like this:

| vertex Z  |  scene-graph order | order-of-arrival (to keep the sort stable) |

// proposes API
// Exactly the same as v2.1
// But setVertexZ() will be more useful, since the Draw commands will be sorted by

// f and g are siblings
f->setVertexZ(100);
g->setVertexZ(200);

// to render something between them, you should do
e->setVertexZ(150);

API is backward compatible, and easier to understand.
In fact, in order to avoid confusion, I’m thinking in deprecating setZOrder().

// deprecated
child->setZOrder(100);

// Instead use this. It removes the method "set z order", and possible confusions with "vertex Z".
parent->reorderChild(child, 100);

Thoughts?

#27

Sounds great!

The only proposal is to leave a room for sneaking objects here and there if you know what you are doing. I mean, something like a functions to get a meaningful data on where that current node is (what order key it has) and some functions to manipulate that. (with some additional diligence and work been done on programmer’s side: sneaking particles between childs of spritebatch, or mixing 2 spritebatches, if one texture is not big enough for all monsters etc)

#28

`Bulat

Yes, it should be possible to do that.
We are going to support auto-batching as well. ( “manual batching”, `SpriteBatchNode@ objects, won’t be removed )

#29

I think one of the most pressing issues is the question of the draw order. This question is evoked here : http://www.cocos2d-x.org/news/137#62-Profiling-Story-2—PerformanceTest-Sprite-A1-case

I think it would be of great help if the drawing sequence was fixed in the renderer. Setting a Z-order when the commands queue is being built. and running the draw commands in reverse order would probably fix most problems with overdraw performances.

#30

Thanks @slawomir

You can draw front-to-back for opaque sprites. But for translucent sprites, we need to draw back-to-front.

#31

my last project used rendering pipeline in cocos2dx 2.1.3
but I was removed most class that I does not need
maybe I can rewrite it in cocos2dx 3 when I have free time and open source

#32

Here is an updated version of the document:

It is still unfinished, but it shows a high level design of the new renderer.

Please, let us know your thoughts. Thanks.

#33

Pseudo code of the new renderer:

Please, read the Google Doc for further info.

#34

It might be a good idea to allow attaching a real 2D camera to CCScene.
It’s also helpful to expose interface to allow custom shaders for arbitrary node.
Not sure why you still leave CCMenu there. I thought that’s gonna be replaced by a new UI system.
I think it’s a good idea to do away with the UI root idea entirely, and allow any objects of dimension to be a target for touch.