On the architecture of Panda

General Discussion
1

Hello, I was wondering about the architecture of Panda and its design choices.

When Panda was born, it was almost a monolithic software: it depended on third-party libraries for few parts (maybe only for the audio subsystem), and provided its own implementation for several subsystems (physics, GUI, …).

Over the years, some subsystems have been “replaced” (or, have been put beside) by third-party components (ODE, PhysX, Bullet, librocket, …).

Imho the strategy of maximizing the use of third-party components is winning. Indeed, that allows the adoption of solutions builded by teams focused on specific aspects. That implies the utilization of well-tested/stable/well-documented/up-to-date components. Moreover, that simplifies the code of Panda, since there is less code to manage/maintain/update/bufix. Moreover, it decreases skills required for collaboration: a collaborator needn’t know internal mechanisms of third-party components. Requiring less skill (that is, having a simpler system) increases the number of potential collaborators.

I’ve always appreciated the KISS (keep it simple, stupid) principle, and the Unix philosohy; these imply that softwares should be focused.

So, I’m wondering why that principle (delegating stuff to third-party components) haven’t been extended to other subsystems. There are many features of Panda which haven’t corresponding external tools (intervals, tasks, FSMs, deployment tools, browser plugin, Python support, PStats, …), and these make Panda a software unique of its kind. But there are some subsystems which have corresponding third-party components, for example the rendering subsystem (OGRE is an example).

Now, my questions. Panda 2.0 won’t utilize third-party rendering system, is it right? Why don’t you’ve planned to use an external rendering subsystem, in order to decrease the efforts on that part and allocate them on other parts (game-engine specific)? Maybe there are features of the renderer of Panda which aren’t provided by OGRE (otherwise it makes no sense to reinvent the wheel); do these features are worthwhile the development/maintenance/testing/bugfixing/updating of a big beast like a rendering system? Why can’t these features be developed above OGRE?

Maybe my doubts exist because I’m developing simple applications and I’ve never used (rendering) features of Panda which aren’t provided by OGRE. So, in my case, I don’t see the value of reimplementing that stuff. So (question for other users of Panda), what are the features of Panda you’re using and which can’t be developed above OGRE? Do you think that the overall quality of Panda would decrease if it adopted an external rendering subsystem? Do you think that the quality (perceived by players) of games would decrease? Will you abandon Panda if it adopted an external rendering subsystem in five years?

My doubts were born since rendering is a big beast (it requires development/test/maintenance/bugfix/update of many things - exporters, model viewer, particle editor, documentation, Win/Linux/OSX/iPhone support, …), and these things would come for free with the adoption of an external rendering subsystem. I remember the Josh Yelon’s post (“I put in time on Panda as well, but most of it gets used up dealing with OS and driver compatibility issues. Not much time left for adding features.”), which claimed that the biggest obstacle is to maintain that part, so, why don’t you delegate it?

The observed trend of design choices in Panda is to delegate functions to external subsystems (physics, GUI, audio, …). If Panda had been born today, it would have been developed its own rendering system? And Panda 2.0, which is starting “now”? As a user, I’d feel that Panda would be a more robust project if it were smaller, because it would require less resources to stay alive.

I wonder if the reasons of not adopting an external rendering subsystem are in the performance side, but engines like NeoAxis belie that.

This is NOT a criticism to Panda, I’ve never had huge problems with its rendering system. I’m only asking for help to understand design choices of Panda.

That also applies to another subsystem. Why isn’t it advantageous to adopt a third-party input system like OIS?

PS The new complete C++ implementation of Panda should make the development of other languages (like Lua) bindings easier (if they’ll be needed). This is another winning choice.

2

There are advantages and disadvantages to the approach of using third-party libraries to provide functionality. Certainly, there is less coding that needs to be done on our end, so less maintaining work. But there are other factors to consider.

  • Having a large number of dependencies is a nuisance. It can be incredibly annoying for people to have to install a large amount of dependencies before they can make a usable build of Panda3D.
  • The release maintainer actually gets a different maintaining burden, he has to make and constantly update cross-platform builds of the library, compiled so that they can be used with Panda3D.
  • If the library introduces a bug, then we’re screwed. It’d already painful for one of the Panda3D developers to debug another thirdparty package. Having to send in patches instead of having full control over the code can be a nuisance.
  • Introducing a dependency doesn’t make it simpler. I dare say it would make the whole more complicated. Every thirdparty library has other libraries it depends on, so Panda indirectly depends on them, too.
  • Unless one of the Panda3D developers happens to be the one who developed the thirdparty library, it’s not easy to dive into the source code of another library when another feature needs developed.
  • Thirdparty packages often use other naming and coding conventions. If they are used excessively, the source code and (more importantly) the API would become incredibly inconsistent.
  • It’s usually quite difficult to find a good-quality library that’s permissively licensed and maintained, and has the exact feature set we need.

That said, I also see the advantages of delegating functionality to a thirdparty library. But I’d say we should evaluate the possibilities on a case-by-case basis, carefully evaluate thirdparty libraries before they are included, seek out alternatives, and not jump to anything.

I don’t think it makes sense to just tack OGRE onto Panda3D. The rendering system is an important core system of Panda3D, which means that other parts of the engine are built around it. There’d probably need to be a layer around the renderer, which translates calls from other subsystems of Panda3D to the OGRE renderer. That could also become a performance implication.

I’d say that it wouldn’t make sense to replace very large, significant, core parts of Panda3D with thirdparty libraries.

I hadn’t heard of it. Looks like it’s part of Ogre3D.
I don’t think that input is a very significant subsystem code-wise, so I don’t think it’s worth it for the reasons named above.

3

In regard to the management of bugs, I was thinking about using stable releases of third-party components, in order to make that management a minor aspect.

In regard to OIS, it isn’t developed (afaik) by OGRE developers, but they suggest it because it’s a good choice in projects where you use OGRE (it’s another focused library, so you have no overlays).

It looks like it’s a trade-off issue, when I wrote I couldn’t see many negative aspects that now, after your answer, I can see. So, now I’ve a more realistic idea about the variables that should be considered, thank you!