Considering switching from bge/bullet to panda 3D

I would need your comments on wether or not I should switch from blender game engine to panda 3D on a specific project. My explanations will be a bit long but I need to have an educated advice on this.


What I had to do, and done with bge, is a kind of small WoW for scientific simulations of robots swarms. Currently the project is spread across many .blend files.

  • the robot 3D model, currently only one but I might add a couple of other robots type. The robot dynamics model is also stored there as a Python script calling applyForce and applyTorque from bge according to actuators orders and many other parameters. This dynamics model is good enough to reproduce the feeling one gets when piloting a real world robot.
  • a map, currently one but everything is designed to change it at will
  • a blender server managing the dynamics of all the robots in my virtual world but no rendering of the scene.
  • a blender client, connected to the server across the network, rendering the camera view of one or more robots

Typically the blender server starts, loads the robot model and the map and waits for clients to connect.

One, or several, blender client connects to the server, gets the robot model and the map over the network and asks for a given number of robots to be spawned in the virtual world.

Then these clients receives actuators commands (from a joystick, from another program, etc) and they send these actuators commands to the server. They DO NOT simulate the dynamics.

On each logic loop the server computes the physics and collisions of each and every robots it was asked to spawn according to the actuator commands it got from the clients. These values are then made available to the clients which in turn renders the scene for all the cameras of all the robots they manage.

So, for example, I can have 5 blender clients managing 4 robots each for a total of 20 robots in the server’s virtual world. Each client takes care of the actuator commands of its four robots (how this is done is off topic here), updates the actuator commands of these four robots into the server, gets back the position and orientation of the 20 robots and renders the cameras attached to its four robots. If I’m unclear here think of World Of Warcaft but with one human player managing several characters at the same time.

This setup allows me to get a reasonably accurate simulation of the physics and camera view of a couple of dozen robots by splitting the rendering accross many computers and still get a decent framerate.

Issues with bge:

1/ The major issue is that I can"t have lights hooked on my robot 3D model and instantiate this model at will in my virtual world (known limitation of bge with GLSL lights…). What I had to do is to hide many lights in the clients 3D scene and each time I want to spwan a robot I have to pick an available light, hook it to the new robot instance and switch it on. Then when a robot leaves the virtual world I have to take back this light, hide it, switch it off and so on. As I can have several clients connected to the same server it means I have to track each and every light used in each and every client…

2/ Furthermore I can’t have more than ~30 lights in the same scene so I will never be able to simulate more robots even if I had the required computing power. I know that 30 lights moving around on a single scene can be considered as a bad design in the first place but I CAN’T just use a single sun light. I MUST have one light attached to each robot as the only light sources available. I don’t care if I get 6 fps instead of 60 as long as I’m not down to 0.6 fps.

3/ The physics I get from Bullet are not that good, I don’t know if this comes from Bullet of from the way it is used by Blender, I suspect their ode solver to be only good enough for games rendering but not for moderately accurate real world physics models. Don’t take me wrong, I don’t intend to criticize Bullet and start a flamewar, I think it might simply not be designed for I want to achieve and to be honnest I had no time to dig very deep on this issue. The only thing I know is that, without any tweaking, and using blender on top of it, what I get from Bullet is light years away from what a decent ODE solver gives me on the same dynamics model.

4/ As the python interpreter is embedded into blendeperplayer.exe on windows platforms, the Python’s multiprocessing module is a pain in the *** to use. It took me days to figure how to do this on win32 and I’m not proud at all of how I solved this problem. (see here if you are curious: … on-windows )

5/ Documentation is somewhere between awful and nonexistant, I spent too many hours designing workarounds and I’m sick of having to dig into BGE’s source code in order to understand what a Python binding is doing.


According to the above, do you think it would be worth it to port all my physics and client/server code in order to use the Panda3D game engine ? What kind of improvements should I expect regarding the issues listed above ?
I would still use blender as a 3D design tool but I have read it is possible to export my 3D model to Panda so this looks like a non issue, are there any caveats though ?
Thanks in advance for your comments !

Hey & welcome! :slight_smile:

I’m not sure if I can really give much of an answer in whether you should make the jump to P3D or not and I am not very well familiar with BGE, but I’ll try to give some insight from P3D’s point of view:

You can’t actually import lights to Panda3D either. What you can do, however, is to make a simple script that creates lights to named invisible objects in the 3D model file. For example, you can make a bunch of nodes in Blender named “Light_type_2”, “Light_type_3”, etc, and when load that model you create lights to the position of those nodes.

30 lights done properly will be a bit heavy and particularly so if they create shadows, however… Deferred shading can help some.

I do personally think that Bullet should be good enough. It is a very well-done and complicated physics engine with a quite good track record. However, aside of ODE, there’s also PhysX to try with P3D if Bullet didn’t work for you.

Myeah, Python interpreter isn’t embedded per say to P3D. It does come with it, but you can use a custom one.

So that’s not Blender’s modelling side only…! :stuck_out_tongue: Ka-tsih!

I do not know. :wink: It is possible that your P3D version would have somewhat more code, though that code may also be less hacky.

You can use Blender as the tool to create your 3D models with. The Blend->Egg (P3D’s format) exporter works pretty okay.

thanks for your answer !

Ok I get the idea, I have to say that I’m close to incompetent in 3D modeling and rendering, I’m more a software guy. The ~30 lights limit came from the number of GLSL lights my GPU can manage when blender compiles these lights at runtime, maybe I’m missing something here that’s not related to the game engine I use. What I did was to create as much spots as possible in my 3D scene in Blender and use them, as far as I know in BGE it’s not even possible to instantiate a new light at runtime, you have to hardcode them in the .blend.

Anyway if I could find a way to add, at runtime, any number of lights between 0 and -say- 100, with a decent framerate, I would be happy but that’s a bit off topic and I think I should RTFM “3D modeling 101” on that.

Just for the record, when I wrote “ODE solver” I was not meaning the physics engine but “Ordinary Differential Equation solver”, think of RK4 with an adaptive time step for example. But as I said I was so overwhelmed with new stuff to learn regarding 3D modeling that I had to put aside Bullet related problems for the moment.

Well, that would be a good start, 500 lines of well written code are better than 250 hacky ones imho !

A bit late, but I think there won’t be much difference in physics quality when comparing the BGE and Panda3D Bullet. Both use the same Bullet engine unterneath, and both provide a simplified API to the Bullet C++ API (a “facade” if you like). Bullet is primary a game physics engine, and thus trades performance and features for quality. The only difference might be which “tweaking” features of the Bullet C++ engine are exposed at the simplified facade.