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:
- Terrain - the current implementation drops fps. (May be clipmaps algo?)
- Recast navigation - it seems it is not simple to create navigation mesh using it.
- 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 
1 Like
- 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 
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 
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.
3 Likes
@zhangxm
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.
3 Likes
Here’s the 3D app I’m working on: https://itunes.apple.com/gb/app/tower-of-babel-1989/id1006403268?mt=8. That’s a link to the version based on cocos2d-iphone, which I’m probably about 90% the way through recoding in cocos2d-x.
1 Like
I am fine with all of this.
We’re using 3D part too. If it will be removed, so we couldn’t user cocos2d-x anymore. Please, save it!
3 Likes
Yep, 3D part will be saved.
3 Likes
Please save these.
1 Like
cocos studio will be saved since cocos2d-x tests depends on it. But i don’t think cocos builder reader need to be saved, it is not maintained a long long time ago. As i know, the cocos builder editor is not maintained too.
3 Likes
Yes, I was talking about cocos studio.
1 Like
But can someone please update the flatbuffers dependency, because Cocos Studio uses it and I’m not able to verify if my changes worked, because I don’t have any data. Also see my topic for that.