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 http://cocos2d-x.org/games/ 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?
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?
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
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
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.
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.
@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.
