How about remove 3D related and some other codes when integrating metal?

How about remove 3D related and some other codes when integrating metal?


I think its easy to want to keep the 3D - why not keep everything and do everything? But you need to balance the cost in time and resources. Keeping the 3D capabilities I think will greatly delay the Metal/Vulkan/Low-Level-Graphics version of cocos-x. The 3D parts of cocos were always kind of an experiment anyway - there are much better 3D engines around if your game uses 3D.

You should take into consideration what percent of cocos developers are using 3D. My guess is its a very small percentage. If so how much do you delay the next version for this minority of developers.

So it depends on how many people are using Cocos for 3D games. And how much added work it will be to update the OpenGL 3D parts of Cocos.

My humble suggestion is to ditch 3D for now. Concentrate on making the best next gen 2D engine. And only when thats done consider how to add 3D in a way that makes sense for the new engine.


A quick look at I cant find any that make use of the 3D engine. I know some games like “Knife Hit” and “!Ball Chase” do - but they seem in the minority.


Does it mean, that I can use the latest flatbuffers version, if you remove it? That would be create, because currently I had to remove it manually from the engine to use the latest one.

PS: As the major version numbers 3.x suggest, I would say: deprecate everything, which you want to delete, but do not delete it in the next version. This way every developer will see in the next update the warnings and can react accordingly. But this is your opinion anyway. - Do you have any plans, when you could recreate/rewrite the 3D part?


Good question, I was thinking to make a 3D game usind cocos2d-x. This depresses me :pensive:


Correct, because of my own plans, I was asking it. I want to do a mixed game. 2d backgrounds with 3d characters. It’s like the opposite of Fallout Shelter, where the environment is 3d and the characters are sprites. But if cocos is removing 3d code for undefined time, I had to chose a different engine for that project.


Based on previous and this question I’m almost positive you were asking about removals for v3.19+ and I responded based on that.

Just to be clear, for the next version, v4.x, you should feel free to do whatever you want and break whatever. Ideally most games should port with little work, but remove all the things. People will use or not use the new version based on its features, but at least will have v3.x to fallback on if they need all the things.


I’m not sure of the impications of this. What happens to v3 when v4 comes out? Will there be further updates to v3 to deal with changes in Android and iOS to support new phones etc.? Or does this mean any 3D game relying on cocos2d-x will have a limited life span, unless ported to another engine?


I look at the ‘3d’ folder, and what I see?

3d skeletal animation support, Billboard support, ‘c3b’ model loading via Bundle3D, Frustrum checking, Mesh and Material support, Skybox support and Terrain support.
Is it really hard to support?

How does it effect 2d performance?? I read rendering cycle code and did not find something. zhangxm What do you say about?

In my opinion there are some things that can be cut off or reimplemented in 3d:

  1. Terrain - the current implementation drops fps. (May be clipmaps algo?)
  2. Recast navigation - it seems it is not simple to create navigation mesh using it.
  3. The binding code to bullet. It has linear complexity in some places - look at Physics3DObject* Physics3DWorld::getPhysicsObject(const btCollisionObject* btObj) -
    May be it is better to set a match between btCollisionObject* and Physics3DRigidBody* via ‘std::map’ ? Besides Physics3DObject looks like excess object, may be I wrong.

I busy under 3d game on cocos a long time, and it is my hobby, not real work. But I waste many time on it, and really belive in success.

Why not Unity - I would like simple open source C++ engine
Why not UE - It is very hard for simple games, besides - licensing.

This is your right to cut these features, if you really know why.
In any way I will say thanks, since I could learn many things by means of cocos2d :grin:

  • cocos builder and cocos studio support codes

Why? It shoudn’t be related to rendering. It may be optional to disable in config, but it should be here. This is important for me, because I have more than 30 games made in cocos studio and I don’t have resources to port them to cocos creator (and it’s not easy) and if openGL will go out in the next iOS release, I’m done :slight_smile:


what 2d features does it break and how does it slow down the engine ?, if thats the case remove 3D then, cocos2d-x was designed to be a powerfule 2D game engine anyway


I can tell you for a fact that Knife Hit has no 3D. It’s animated with spine.


huh, thanks for correcting me! It looked like the it was a 2d game but when you won a level and the log broke apart that animation looked 3D.

But on that note: “Steps” was a 3D game written in cocos-x. But the author felt that it was a “painful” experience and also that the 3D part of cocos-x had performance problems.

It always felt like the 3D cocos-x code was more experimental than production ready.


No problem, that’s the magic of good animation :wink:


You can reimplement some code when models loading and doing static batching for meshes.
All tree stubs are drawing in one drawcall, and grass in one drawcall.

‘Prestigio psp3506 duo’ gives 20 - 30 fps for this. (30 is stable without grass)


Because 3D will be removed, so there is currently no plan to create a gltf importer. Right?


3D is super important to my current projects. I would need this work.

But the other three aren’t important to me at all.


If you are trying to do all these stuff (OpenGL ES 2/3, Metal, Vulkan) by yourself it will take years to create a GameEngine with same features as Cocos2dx v3.X. I just read some documents about all these APIs… this will be some hard work for you.

I know that no one likes the idea to begin a new Project with the old openGlEs2 engine… but I mean most Devices on the market still support openGL… so there is (still) no hurry atm.

My suggestion would be:

  • It’s not about the amount of features (new features)
  • Important: Design the new Engine 100% backward compatible. Porting from v3 should be possible (and some kind of easy)
  • Design the API future-proof. That means implementing new features should not lead to re-designing the already existing structure.
  • 3D related stuff will be needed. If you do not implement it… you will get tons of requests in future.
  • 3D should have a lower priority for now. but…
  • 3D stuff should be planned now and designed well… like I wrote above… implementing it later should not lead to redesign the engine… this really should be designed carefully.
  • Another thought could be to design the engine modular. Devs could load/implement 3D API (or other APIs) independently in Cocos Console. So the Base Engine would still be a lightweight 2D Engine.
  • Last but not least: VERY IMPORTANT… a Documentation! Every little function should be documentated and explained… like it has to be in SoftwareDevelopment. It doesn’t mean anything if there are tons of features but no one knows how to use them. cocos2dx v2 documentation was great (good tutorials. Many documents in english)… cocos2dx v3 changed so many times that all documents was outdated within month. CocosCreator Documentation is the worst atm. As Example: CocosCreator has the Extension Feature… so everyone should be able to extend CocosCreator… but the Documentation so bad… that its a pain to create Extensions. Almost no english Docs… and half empty Documentation.

CocosBuilder, CocosStudio, JavaScript Bindings and Deprecated Codes should be removed.

I like your informative forum threads about this Topic. A Roadmap (with Milestones) would be nice.
Thank you… and good luck with this project.


Here’s the 3D app I’m working on: That’s a link to the version based on cocos2d-iphone, which I’m probably about 90% the way through recoding in cocos2d-x.