It seems a lot of the documentation, even though it has a ‘C++’ switch, doesn’t actually cover how to use something in C++. Does this mean python is a dependency for Panda3d? Some things, such as low level vertex manipulation and other procedural methods seem ridiculous to implement in python. Are we forgetting that python is very slow compared to C++?
Nope, Panda can be compiled without the Python bindings. Check the Makepanda.py flags if you’d like to see how it accomplishes this.
However, there is a lot of helper code written in Python, such as the Directbase material. By foregoing Python, you miss out on a lot of convenience wrappers, but there’s no reason why you couldn’t write C++ code to do the same thing.
I’ve only just started to poke into the C++ side of Panda3d, and there’s some odd conventions due to philosophical differences between C++/Python, but otherwise it’s pretty straightforward to me.
So far I am enjoying some aspects of the engine, such as its reliance upon ordinary STL and the automatic Python binding generations. The last engine I used was old and had a lot of custom container formats (Microsoft C++ compilers didn’t even have a working STL back then), plus all script bindings had to be done manually. (Annoying to go through a 20 minute compile to find that you forgot to go add the script-side interface to your C++ method. It also meant every method was duplicated twice… Getters/setters for your class variables, and then script-engine-specific getter/setters. Gah.)
I don’t know how many games are written in pure C++ with Panda3d and don’t use Python – Maybe some of the Disney games do this, but I am not sure.
The switch for C++/Python is pretty new, previously only python was covered, now it’s only about updating the manual (and it seems that the geomVertexWriter part is not yet done)… Python is no dependancy, you can do everything that panda offers (the apiref is generated from the c++ code afaik) in c++.
the speed requirements depend on what you intend to do, generating some procedural models at startup using python is no problem. if you intend to modify your 100k vertex model every frame you will have problems in c++ as well (shaders?). also the performance depends on how well the code is. also there are tools (for example psyco) that can improve python scripts speed up to 20times for low level math’s.
long story short:
-yes you can write panda applications without a single byte of python.
-but in 99,9% there is no reason to drop all the benefits offered by python. so using python is recommended simply because develpment is lot faster and there are no real drawbacks (with veryveeery few exceptions)
Suppose I was implmenting (which I am not, but will hopfully in the distant future), a real time face editing mechanism, such as that for the sims, and some mmorpg games? Will python be fast enough to update the required geometry (assuming the face is a ‘mildly’ detailed face) based on the required equations?
The main reason python is seeming a bit shady is because of how difficult it is to debug, and to even read for that matter. The syntax is simple, which makes it hard to read and know whats going on in large files. Since I want to go semi-serious about the game I plan on developing, I will probably be putting some stuff in C++ and other high level stuff in python (the every-frame stuff I will probably put in C++).
Another question I have is, can I debug the C++ side, say I make a C++ object from python, can I still use the debugger to step through the object’s creation? (as you might have noticed, I’m not familiar with doing a project with a scripting language layer)
P.S. It’s a shame there are no benchmark tests for Panda3d, there is no indication as to the rendering capabilities of Panda3d, how detailed can models be I wonder, and how many models can one have? I may have to do some benchmarks once I get an engine together. Although knowledge of other engine’s optimization techniques to improve benchmarks makes me cringe…
The only real way to answer this question is to bench it yourself. Generate some test objects, perform some of the operations you want, and then see just how fast it is and whether its acceptable.
It’s pretty easy to add your own class extensions to the C++ code behind Panda3d; If necessary, you could write most of your code in Python and then convert to C++ what isn’t fast enough.
I’m doing per-frame stuff in Python and I haven’t noticed any particular lag in doing so. But I try to rely upon the C++ parts of Panda3d as much as possible. (For example, instead of iterating over a list of collision objects in Python code looking for the one I need, I am using collision messages instead, which are generated/parsed on the C++ side.)
I admit it took a while for me to adjust to the Panda3d Python-driven method at first, too. Most of my own game engines, or engines I’ve used by others, were C++ driven, with scripting as a secondary component.
But now I find it isn’t too bad. I came to Panda3d primarily because of its Python base, as I rather enjoy Python as a language.
Yes, you can step-debug C++ code, as long as that code is generated with debug symbols. You will, however, need a debug version of Python in order to get a clean path to your code. If you want more details, check out my thread about debugging (assumes you are using Windows/MSVC). pro-rsoft helped me a lot on getting a working, debuggable Python/Panda3d combo. He’s committed these changes to the latest CVS HEAD, so they’re available.
However, if the idea of using Python really rankles you, then there isn’t a reason you couldn’t skip it and say, implement some really lightweight scripting language such as Lua. But you’ll need to write your own scripting engine and bindings.
FenrirWolf’s comments are right on the money. I have a few more particulars to add.
No, writing a vertex-blending algorithm like this in Python would probably not be a good idea. But you don’t have to; that’s why you have Panda, which has the required vertex-blending algorithms already implemented to you. If for some reason you find that Panda’s algorithms aren’t satisfactory, you can always implement just this part of your game in C++.
It might seem shady and scary now because you’re not yet comfortable with the language, but I find that once you get into it, Python is actually much, much easier to debug and develop than C++. This is primarily because you can interrupt the interpreter, write some new code, and restart exactly where you left off. I have developed entire subsystems of a MMO game without ever even shutting down the game I was developing it into.
Note that I am a hardcore C++ programmer myself. I spend 95% of my time writing C++ code, because I have to, working deep in the Panda3D engine. Yet I love my opportunities to program in Python.
Within my branch of Disney, we do all of our game development in Python. Every once in a great while we find that we need to migrate a particular piece of code from Python to C++ for performance reasons. It’s happened maybe five times in the past ten years. The other side of the tradeoff is all of the developer time we’ve gained: the amazing efficiency of Python development has allowed us to develop much richer, fuller games with the limited staff we have available than we ever could have imagined had we been working strictly in C++.
David
That’s why all Panda’s functionality where speed really matters is implemented in C++. The amount of Python code that happens every frame is not really significant.
If you write something like a terrain generator or so, which does countless of calculations every frame, you can implement that specific part into C++ and compile it with Python wrappers, and use it in your code.
But today, that kind of heavy stuff usually happens at the GPU, using a shader.
Uhm, you need to use a C++ debugger then instead of a Python debugger.
Er, benchmarks of an engine are really useless. Panda just passes the model you make to the GPU driver - so you need to get a benchmark for your GPU, not for Panda.
Panda provides lots of tools to help you optimize your performance though. But in the end, performance is up to the one who makes the game.