Has anyone thought about implementing a Mono version of
Panda3d and using Boo/IronPython to drive it?
For those of you who don't know Boo/Mono is, it's a framework with python syntax that is roughly ~50% the speed of C, and contains several features such as threading across multiple CPUS which CPython doesn't support.
I know one can use numeric/psyco/swig to workaround the speed issue, but they can't solve every problem in a simple way. Also, in another years time, the ability to thread from a single process across multiple cpu cores is going be pretty important and I don't see CPython ever solving that problem as the core developers seemed to be fixed on language eccentricities like generators.
So back to my original question: is anybody looking at integrating Mono with Panda3d? Mono seems like it would solve a lot of problems while preserving the python syntax.
And David, I have a tangential question as well: I have a hard time
imaging a commerical application executing by calling Panda C++ functions using python. Is Toontown constructed the otherway around? A C++ framework calling python scripts?
well i’m not dave but whole panda is c++ with python bindings. so you have the easy-to-write python files which are controlling a nice and fast c++ engine. the other way around doesnt make any sense since c++ is not as easy to write as python so it would be bad for actual game-programming, and python is ways slower than c++ which would make it pretty bad for using it for most things a engine usualy should do as fast as possible
about your mono question…i wonder why would you want mono?.
The difference between python calling c++ and c++ calling python
is illustrated by the two example 'Hello World" programs in the manual. In the former you have a main python loop intializing and calling the C++ rendering pipleline. In the latter, you have a main C++ loop calling C++ rendering pipeline and possibly python scripts for things like AI.
The problem with python is when you start to write complicated code like flocking behaviour, it's too slow! So what happens (for me anyways), is the flocking behaviour ends up being written in C++. Then the program looks like
1) python calls C++ rendering
2) python calls C++ flocking code
Python ends becoming a glue language holding two modules together. Yes, this kind of development is still better than
1) C++ calls C++ rendering
2) C++ calls C++ flocking code
because of code comparmentalization and dynamic testing, but I rather have it be
1) python calls C++ rendering
2) python calls python flocking code.
CPython is in general too slow for 2) and I hate having to use SWIG or thinking up some insanely convulated slicing algorithim with Numeric to working around 2)
This is where Mono/Boo would be useful. It would let you write 2) in plain pythonic syntax without sacrificing the speed.
Moreover, in the future you would like to toss Panda3d (the rendering engine) onto one cpu, your AI onto another cpu, ...etc. With CPython, you just can't do it right now. But with Mono/Boo it seems this is (relatively) trivial.
I'm not saying Panda3d should drop python, but I'm raising the question of whether the python should be 'CPython' or a Mono/Boo variant.
i dont really know what you mean with “flocking code” but using c++ extensions works quite well in python.first of all hole panda seems to work great this way … and one of the best examples for non-panda-flocking-code i can think of it the SOARX terrain algorithm.
worls perfectly fine, is fast and easy to use.
well for the multicore processing stuff i dont really know. never played around with it since i dont have one.
well i dont know… i wouldnt need it. if you do, feel free to add it to panda
What I mean by flocking code is code that simulates bird flocking behaviour. I currently use C++ with python and it works, but I wouldn’t
call it convinient (and the whole point of python is to have convinient things!)
Here’s an example of a Boo code which creates an array of vectortypes.
def createArray(count as int):
a = array(Vector3, count)
for i in range(count):
a[i] = Vector3()
return a
a = createArray(25000)
total = 0
for v1 in a:
for v2 in a:
total += v2.Distance(v1)
++count
This codes reads like python, interfaces with the rest of the python framework nicely, but performs like C. And better yet, If panda3d had Mono or .Net bindings, you would never have to leave your python IDE to use it. I got so exicted thinking about this which is why I'm asking about Mono or .Net interfaces/embedding.
hm. i see… well if it doesnt only looks like python but also works together with it it might be indeed quite intresting. too bad i dont know much about mono/boo/c++ . but indeed sounds intresting.
From what I read on mono-project.com/Boo, Boo is a different programming language inspired on python. For one, it is statically typed, while python is loosly typed. So it is not a matter of simply taking panda’s python code and running it through the Boo interpreter.
I’ve never used it myself, but it is basically a language that is almost Python, but uses C data types with static binding, and compiles down to a C extension. So it basically offers the speed of C, most of the nice features of the Python language, and eliminates the need to write tedious bindings.
I’d really suggest looking into this, because while a port of Python to Boo/Mono is pretty unlikely to ever happen (unless you do it yourself), Pyrex sounds like it could solve your problem with full compatibility to Panda3D as it exists today.
I didn’t know about Boo/Mono before, and browsing their webpage for 15 minutes left me interested. Interested in spending some time one exploring what is behind Boo/Mono, one of the next days.
But Laurens is right. Boo/Mono is a completely different language, which just mimics Python syntax and is missing lost of nice Python features. E.g. generators which are more than eccentricities. Generators can gain you a lot of speed, if used in the right way.
There might be plus points for Boo/Mono which I would like to explore, like access to the full Mono family or multiprocessor support. On the other hand so far I haven’t seen anything Python can’t do right now, with a bit of tweaking.
Or it means keeping the C++ Panda3D core and providing Boo/Mono wrappings. In this case there will be a speed penalty for conversion between Boo/Mono and C++, like with any wrapping. And given the size of the C++ API this would still be a huge chunk of work. Since you are probably the one with the most Boo/Mono experience perhaps you want to provide a small working sample how to access C++ Panda3D methods from Boo/Mono. This would certainly buy you a lot of attention.
If it is about speeding up Python code I (too, like Arkaaein) suggest using Pyrex for writing C extensions. Pyrex syntax is almost the same as Python. This means you can just copy your Python code to a .pxy file and compile it. Not much speed gain so far. But now you can start working on the Pyrex code. Change Python loops to C loop, then declare variables to be C variables (static types). This alone will speed up your code. Finally you can switch from using the Python API calls to C/C++ API calls (e.g. Panda3D Python API --> C++ API). Now you have 100% C code. One weakness though: Pyrex supports interfacing C code only. C++ is possible for simple C++ API’s, but it means more work.
How capable Pyrex can be is perhaps best demonstrated with an example: Soya3D, which is a (high level) 3D game engine written completely in Pyrex. If Soya3D would support shaders too it would be a serious rival to Panda3D in my eyes. Also I had a simple example on how to embed (not extend!) Panda3D/Python code with Pyrex.
Also I tried using Boo with Irrlicht.NET, but the compiler seems to be buggy.
I don’t think Boo is ready for prime time. The compiler error messages are very hard to interpret, and there were some bugs that I couldn’t resolve. (I know it wasn’t from Irrlicht.NET because the equivalent program in C# worked fine.)
Right now I’m using a combination of psyco, weave, SWIG, and
it’s driving me crazy. I’ve never used pyrex but I lumped it into the SWIG cateogry because it requires me to drop out of my python IDE (whereas with weave I can keep typing along in the same .py file.)
If I stick with Panda3d, I’ll make the .net/mono bindings myself, but I raised this issue mostly to get David thinking about converting to .net/mono for Panda3d 2.0
Cyan: I agree Boo’s compiler error messages sucks big time, but I haven’t
ran into any compatibility problems yet. I’ll have to take a look at Irrlicht though, I didn’t know it had .net bindings.
Oops, one thing I haven’t been making clear is that I’m not suggesting
a rewrite of the base C++ engine but rather changing the bindings
for it from CPython to .net/mono use we can use Boo/IronPython.
Sounds like I showed up a bit late to this party. But let me add my two cents: you’re all welcome (and encouraged) to experiment with interfacing Panda with whatever languages you like, be they Python, Pyrex, Boo/IronPython, Java, DarkBasic, Fortran, or whatever. We originally intended Panda to be portable to multiple different scripting languages.
As for us, though, we like plain old Python, and plan to stick with it, at least for the foreseeable future. It’s wildly portable, it’s easy to use, it looks like it’ll be around for a while, and we’ve never had a problem with performance. We’re quite comfortable implementing the occasional math-intensive algorithm in C++ if necessary.
Steering Behaviors require an enormous amount of square root calls. (calculating distance, interpenetration, etc). These calculations are typically done between all the agents. N * N-1. It might be useful to implement a Fast Square Root C function (as well as a fast inverse Square root).
I think CPython/Panda3D in it’s current form could handle a large number of Autonomous Agents (i.e flocking, obstacle avoidance, etc) by offloading some of the math intensive stuff to compiled code.
I am no expert but if you standardize on a type, (use all floats) then a compiler such as psyco could compile some of these modules and offer some speed increases.
Uhm, well, you could always just subtract two points. This will result in a vector, which you can grab the .length() of, which is the distance between those two points. No need to call the slow-as-molasses (compared to C/C++) Python math functions.
It’s a very ‘pythonic’ way of doing things, but I figured that out from digging around in the Reference, and not in the Manual. It’s a pretty important piece of information to derive, so I don’t know why it wasn’t very clearly explained in the manual.
Also, you can avoid having to do square roots on distance calculations if you square the ‘sizes’ of the two objects (the ‘minimum distance’ in a flocking algorithm, I’d guess) and store that.
I don’t know to what extent Panda3D does this, but it’s really the niche that Python is finding; Python code should almost always be running on top of some sort of API written C/C++ because that’s just how it’s most effectively been used.
Also, if you don’t feel like using Pyrex, you can just write a .dll / .so in C (not C++) and write / generate a wrapper for it with the ctypes package. It comes builtin with Python 2.5+. I’ve used it with pretty good success, but you need to make sure your C lib and wrapper code are rock solid or your program will segfault randomly and you have no idea why.
