It’s not clear what direction Panda 3D is heading and what features will be supported.
Is there some general roadmap available ?
We’re in the process of putting the 1.11 roadmap somewhere public, but feel free to request access to this draft document:
1 Like
Roadmap has been requested many times in years before.
Why not pinning it in General category ? at least a first draft.
1 Like
You can always use Google Drive or similar and make the document as a public download link rather than on-demand with a required registration to Dropbox and a wait time. It’s a bit annoying.
1 Like
It must be public for anyone to see what is the roadmap and give some feedback.
Otherwise it’s like having no public roadmap. example.
Yes, obviously the roadmap needs to be public, no question about it; this was supposed to be a draft while we’re getting everything set up in some public place like GitHub Projects, and creating a landing page on the site for all contributor-related resources. I’ve been extremely busy with other engagements, hence the delay on my end on this.
For now I’ve enabled public access to the document.
Thanks for making it public. For me, this part
https://paper.dropbox.com/doc/ShowBase-replacement-ideas--AbZW3znctf0nbYCZ64TSOdzrAg-E2aGKFyxmNwZYSQsHC9eS is especially interesting. Direct and Panda core always looked like they are 2 independent libraries, rather then one engine, and that was very confusing when I started learning it.
Do you also mean you want to reimplement the main loop in C++ while leaving the ability to use Python API? This would be a great improvement to the engine.
Yes. The plan is to split off direct into its own library and make it fully optional (those who need it will be able to do pip install direct or so). Instead we will offer a new C+±based application framework, possibly with a scene layer based on an ECS paradigm.
That is beyond the next release, though; the upcoming release will focus particularly on graphics improvements like PBR.
What is the progress on the roadmap ?
Could a very popular language like C# become adopted as part of the engine ?
We should soon make a development blog post. Perhaps the most exciting bit is that a lot of progress has been made towards iOS support in the past months. Work on the new shader pipeline (which will enable a host of things that benefit such things as PBR shading and mobile support) is also still underway, but hasn’t been finished yet; I’ll be focusing more intently on finishing that in the coming weeks.
I think it would not be a good idea to adopt C#. It’s possible, and I’ll welcome patches to that extent, but Panda3D is currently heavily invested in Python and it is currently the best choice of engine for Python users. It would be significant effort to support C# as well as we do Python and it would not benefit any of our existing users, instead requiring us to attract altogether new users, and we’d be competing directly against giants like Unity in that space. It would be better to spend all that effort on making this a better engine for Python and C++ users, if you ask me.
I’m late to the party but I completely agree.
Godot has a good support for C# and Unity’s revised permissive and affordable licenses also make it suitable for many pro and indie users, and it is completely focused on C# and has abandoned Python.
So really, the only 3d game engine that is still properly updated which uses Python is Panda3D. Panda3D is superior to engines like Godot in some ways since a non-custom language allows us to use use the huge library of third party Python libraries. Just one of my projects uses PyOpenCV, PIL, Numpy, sockets, pyside and PyQt… This is simply not possible to do with Godot’s GDScript unless you spend tens of hours trying to write wrappers for C++ libraries.
So Panda3D should focus its limited dev time and budget on what it does best. There are already good alternatives for C# users.
1 Like
I wouldn’t want to do stand-up, but Panda has almost completely abandoned C++. 