I was brainstorming in the shower on what could make panda3d more attractive to the outside world. Like any brainstorm it is probably a bad idea, but I thought I would bring it up anyway!
So here is my assumption: Maintaining backwards compatibility makes it more difficult to maintain the engine and add new features. If my assumption is wrong, the disregard this post
Are there enough (or any) benefits to start a new version that doesn’t worry about backwards compatibility, “simplify” the engine code base by replacing older parts of it with third party libraries?
My understanding of history is that when panda was first being developed there was not much in the way of third party libraries, so everything had to be done in house. A few years later there were a wonderful assortment of third party libraries, but Disney was rightly hesitant in abandoning support for legacy systems (windows 98, etc). I don’t know how much of a concern this still is with the future on mobile devices. Regardless, with the eventual migration to DVCS it becomes a lot more viable for Disney to continue working on the version 1 branch and merging the appropriate commits into 2.0.
So what could this look like?
Redoing the python api to be pep 8 compliant.
Drop python 2 and move to python3 (dodges rotten fruit)
Personally I would love to see Panda at least migrate to Python 3. Panda is the only application I use Python 2 for any more and I occasionally find myself getting tripped up on things like int division and even the more restrictive use of arg expansion (*args). Would this migration require changes to the panda c++ core or just the python code?
We’ve discussed the idea of Panda 2 several years ago, and set up a roadmap of features that we would like to see. It included under_scored() method names, reimplementing the core ShowBase, Actor, FSM etc. interfaces in C++, patching up the DirectX support, OpenGL 3.2±only contexts, implementing a more modern GUI system, restructuring the scene graph to build an effects-oriented pipeline, switching the build system to CMake, switching from .egg to COLLADA as native file format, and many more.
However, several of the developers who were most excited about Panda 2 aren’t actively contributing to the project any more, so we don’t have the manpower to code up something like that. So, Panda 2 has since become more of an abstract concept denoting the general direction we want to work towards, albeit one feature at a time. For instance, Panda 1.8 saw the introduction of the under_score() syntax as an alternative way to call C++ methods, libRocket has been integrated in 1.8, etc.
So, long story short, we currently don’t have the manpower to go all out with a huge and shiny Panda 2 release, but we can still work towards the idea of a more awesome and more modern Panda, one step at a time.
@csios77: I’ve recently checked in experimental Python 3 support to the core of Panda. However, all of Panda’s Python modules (in the direct tree) are still written for Python 2, so they would need to be rewritten in a way to be compatible with both (which isn’t always possible). I’d be happy to accept patches, though.
I’ve done some 2->3 migrating before so if it just means updating python code that’s something I could help with if wanted.
As for maintaining compatibility do you mean you would want a single panda installation to be able to run both 2 and 3 code? As an alternative would it not be possible to have 2 distributions, one for each python version?
Patches would be appreciated. There are a few things to watch out for, though, since some of the guys at Disney rely on old Python behaviour, such as a tidbit about the callable() check. But we might be able to work around those cases.
Having one build that works with multiple Python versions won’t be possible. I’m talking about source-level compatibility here - I mean that we shouldn’t need to keep two copies of the “direct” tree in the source code, one for Python 2, and one for Python 3. It’d be good if the Python code in the “direct” tree can be run in both Python 2 and 3.
Get rid of the dependence on egg, far too many things only work on eggs like the builtin collision system.
promote the “switch node” to the same status as a LOD node eg. creatable outside of an egg.
a better node heirarchy system perhaps based on a native code integration of SQLite with a user modifyable schema this could replace the DC file trainwreck and Panda Tags on nodes and make it easier to build some sort of on demand loader for large DB based world crawlers
totally trashcan the Disney distributed networking as its almost undocumented and nobody has access to Disney OTP or CMU serversides to run it. Replace it with something more of us can use, some sort of tiled SQL
integrate a tiled terrain system like Animate Dream’s at the C++ level, with collision geometry
64 bit coordinates at the application level clipped to 32 when sent to GPU by default, don’t make those of us without C++ skills have to try to build it
dont’ know what the advantages of Python 3 vs. Python 2 are but soon Python 2 will be backwatered, obsolete and unsupported
better ingame GUI with ability to do “Runes of Magic” style floating text over avatars
I would better suggest aiming for pypy instead. For performance reasons. Too bad swig doesnt work with pypy so its yet another big challenge…
EDIT:
Sounds like making pypy bindings is much easier. doc.pypy.org/en/latest/cppyy.html
Once cefpython is complete enough we could do wonders with it. Cef could be integrated on c++ level too. I am making implementation of gui system and html textures on ogre3d. Should be easy to port to panda too once its ready.
That was the point I was trying to make that i failed to articulate. I was not refering to panda 2.0 as something new written from the ground up, but a branch where it is ok to break backwards compatability like the callable() check. The idea is that disney and others can contribute to the 1.x branch where relavant commits can also be brought into the main 2.x branch.
Sent: Tue Mar 26, 2013 1:56 pm
From: lord gengoro kitsune
To: ThomasEgi
Just wanted to see if folks were really thinking about improvements or not. I have decided once and for all this thing is DEAD and will be removing all text from my posts soon and deleting this one entirely. Probly will delete all accounts I have anywhere on the web as well.
A few points:
there is no good documentation on use of the switch node outside of an egg like there is for the LOD node
I had the floating text working for a while then POOF! it quit, IDUNNO and I haven’t had time to even see how librocket works
as far as the SQL heirarchy proposal goes, many folks especially those building editors seem to be having to build some sort of wrapper around the existing node system, mine would have simply been yet another way of doing it
was under the impression that the 64 bit coordinates was only a “build” option and not something I could simply enable with a switch in my PRC file (oops! my bad for misunderstanding what has been posted) would rather have the C++ side of the actual engine do it and slow a little, than build a Python wrapper class around everything and slow it all down to a crawl.
I stand by my statement concerning the Disney Distributed Networking code, it is a trainwreck and almost totally undocumented, somebody ( not me as I’m through trying ) needs to be writing something a wider audience can actually use.
as far as balls and chains go all of my attempts at using my creativity in this greedy hellhole of a world have been such which is why I’m quitting everything related to the web and computers, before this ball and chain drags me completely under.
See! I rip my own self apart constantly anymore and need no help whatsoever doing it.
Sincerely
Lord Gengoro (roadkill on the information superhighway) Kitsune
@rdb: Ok, I wouldn’t mind giving this a shot, though I can’t give any guaranteed time frame or anything. You mentioned you recently put support for Python3 in the core, so what version would I need to get my hands on then? I presume I would have to build the most “stable” version which includes Python3 support? My C++ / compiling skills are a bit sketchy, but just point me in the right direction and I should be able to get started.
Are you using Windows?
You would need to grab the latest CVS version of Panda3D from the CVS repository.
Then, you would have to grab the thirdparty packages of Panda3D. Remove thirdparty/win-python and install Python 3.2 from their website into thirdparty/win-python (use “install for this user only”).
Then, run makepanda normally, with --everything --installer.
(The version of Python should be 32-bits. You can use a 64-bits version of Python, but then you’ll also need 64-bits builds of all of the thirdparty packages, which we don’t currently provide. If you do want a 64-bits build, you’ll need to install it into thirdparty/win-python-x64 instead.)
In order to build on Windows you’ll need at least the Express version of Visual C++ 2008 installed.
On any non-Windows system, instead of messing with thirdparty/win-python, you just have to make sure that you have to have the right version of Python installed on your system, and then run makepanda with the version of Python that you want to compile against.
If you run into any issues, please let me know and I’ll help out. I haven’t tested it extensively at all, so it could be that portions of the codebase don’t even run. A quick test shows that importing libpanda crashes, and I don’t currently have time to debug that I’m afraid.
Yeah, I’m on Windows XP still actually (hopefully not for too much longer though). I’ve made some progress on this but rather than discuss it here I started a new thread in the features forum. I figured it would be better than taking over this thread which people might want to add to still.
