Oh, thank you @almax27 for such a detailed answer but according to cocos2d::Renderer::processRenderCommand I can see that batchDraw method will be called in any condition so CC_INCREMENT_GL_DRAWN_BATCHES_AND_VERTICES will be increment too!
flush3D method is really calling only 1 time but only batchDraw will really draw the content.
Can you please help me with this?
Extremely grateful!
Just wanted to confirm something from my deleted post. Sprite3D by default doesn’t batch, from my testing of adding a bunch of Sprite3D instances using the same box.c3b model from cpp-tests (without any other nodes in the scene). Draw call per each.
I’ve got the same 
@stevetranby @igormats I see where you’re coming from now.
I think CC_INCREMENT_GL_DRAWN_BATCHES_AND_VERTICES should be called in MeshCommand::preBatchDraw() but only when _material == nullptr. It seems using a material does in fact break batching as geometry is rebound (per pass) during MeshCommand::batchDraw() if _material != nullptr.
Perhaps batches should be done per pass, per material instead.
That’s correct.
It works more or less like this:
A Sprite3d object is composed of one or more meshes.
Each mesh has a MeshCommand
MeshCommands have certain properties like: skipBatching, materialId, etc…
Depending on those properties and the renderer context either one of these two options will happen:
meshCommand->execute(): immediate drawing, no batching.meshCommand->prebatchDraw() & batchDraw()
The thing is that batchDraw actually does not batch anything. It just reuse the context (VAO), but will perform a glDrawElements for each mesh.
IIRC, MeshCommand never batched the draw calls, but I could be wrong.
What I know for sure, is that if you are using the Material system that was introduced in v3.7 (?), then objects won’t be batched, since the context is being changed in each pass.
@ricardo A couple of questions:
Could you explain the thinking behind the current approach?
Thanks 
IIRC, we have two different command (Mesh and Triangles) because of legacy reasons.
Right now Mesh is optimized for 3d: it has normals and other attributes needed for 3d. And Triangles is just a simplified mesh optimized for 2d.
I don’t think it is worth unifying them since it is not that common that you are going to batch 2d and 3d objects together, but I could be wrong.
But yes, we should support material batching at some point.
Hi! Tell me please is any steps was made to archieve 3D batching!? Really can’t make a nice game without it
not yet, but we are planning a much better 3d renderer for v4.0
@ricardo when do you plan to start in on 4.0? Is it going to be an internal private project until some time that it’s deemed complete. And do you know if this is going to be a CREATOR-first project?
we started a few weeks ago with the requirements gathering.
I think the implementation will start in a few weeks (or months?).
the new 3d renderer req. comes mostly from the Chinese market, but it is something that we have been discussing here in the forum as well.
as far as a I know it will be cocos2d-x first.
@ShunLin any idea when the implementation of the 3d renderer will start?
The 3D progress is on requirement gathering, and we also doing some research of engineering now.
The prototype of 3D renderer of Cocos2d-x will be created on WebGL firs, and then native support.
The aim of the 3D is Creator friendly, and of course 3D editor will be integrated into Creator.
Now, we are working on v3.1x to fix more bugs as we can, and make sure that users are happy with the quality of v3.1x, then we will put it in maintain mode.
After that we will freeze the v4 requirement and Launch it. Wish we can launch it on Nov.
Hi, As far as I know, what you need is really batching, However, in 3d cases, batching is much more hard to archieve than 2D. Generally, two methods will be used for 3D batching, dynamic batching and static batching. Both methods involve merging vertex and index buffer operations. In cocos2d v3.x version, we do not achieve this. the performance improvement in sprite3D is material sorting as @ricardo mentions.
Some more details for 3D renderer.
Phong lighting and some Physically based rendering.Thanks, appreciate the response.
Has there been any progress with this?
Unity engine has this feature: dynamic and static batch drawing for 3d models.
https://docs.unity3d.com/Manual/DrawCallBatching.html
It would be great if cocos2d-x would have this also.
Now to create a game similar to Minecraft is ridiculously expensive. Each cube calls additional GL draw functions.
In this picture: GL calls: 262, GL Verts: 61858
You’ll have to modify the engine yourself. For a minecraft clone I’d recommend writing your own Node class and using the primitive rendering commands instead. You’re also going to want to possibly look at texture arrays, among other extensions that you won’t find supported in cocos2d-x. The engine is open so you can write your own, but I wouldn’t expect it to provide any help with this type of 3D game (or any 3D game) going forward.
Hi there!
If anyone made it works please share it with community please because for me it is too hard to make it
With help from shadowphiar I was able to achieve draw call batching of static 3d cube models:
