Sure, like almost everything game logic related…
Still, I actually think comparing OGRE with Panda is perfectly pointless. OGRE is a mare rendering engine. It doesn’t do anything outside of that, unless coupled with lots of other libs, so it’s no surprise it’s graphics arsenal is larger. And while there are integrators for many of those on the OGRE website/wiki, it can’t really be called a “game engine”. Panda, on the other hand, is probably as close to a middleware as you can get with OpenSource. It’s somewhere between stuff like OGRE and stuff like UDK or Unity. It does everything you need to make a game OOTB, while OGRE does only rendering.
Being a sole renderer surely helped OGRE gain momentum at the time Panda wasn’t even Open Source (or half-open source). A small, coherent, rendering-only library is far more purpose-agnostic. Obviously, Panda (or even UDK/Unity middlewares) can as well be used for non-game-related stuff, but it’s usually easier to use clean renderers for that. Coupled with clear focus and simplicity, I think it explains OGRE’s popularity. And interest from commercial developers imho came from that. Also, as a result of that popularity, there are even books covering OGRE’s usage – this certainly aids in gaining interest on the commercial games field. Just like the “meant for consoles” additional licence option. It all helps. OGRE is also very mature in terms of approach, and that helps too, because you will only attract professionals if you look professional. I’m not implying Panda doesn’t, I just rant on OGRE at the moment ;D.
That all said, I think Panda just didn’t have enough time to shine yet. It’s been OpenSource since 2008, and I think people who looked for a free (as in beer) engine and ended up eventually using, for example, OGRE actually wanted that too. Also, being so long on the scene makes OGRE more reassuring. But maybe that’s just my assumption.
I fully agree with Thomas, that it all depends on what you need. That’s what I’ve learned over my years – choose an engine based on the needs you have, not anything else. Thus you must understand your needs, or there’s large chance you’ll end up changing the engine, no matter where you start.
I also agree with the C++ assumption. You can see all over the Internet that people are somewhat afraid of Python and tend to prefer C++ whenever they can, despite the fact that even engines like UE3 also provide (custom) scripting languages, usually used write do most gameplay anyway. They think a game written in Python must be slow and that Python will limit their possibilities. In the same way, people are afraid of throwing all of their eggs into one free soft basket, as in using an OpenSource middleware like Panda. Trust given to big open source projects by commercial developers is very limited (falsely, as Panda and it’s community proves). They think such projects have large chance of being unstable or unable to provide good support. That, as I assume, is a reason why they prefer to use only a renderer, building the rest of the stuff separately, either from other small, self-contained packages or in-house.
All the above in turn forms a reason why one shouldn’t depend on opinions, rough lists of “(commercial) projects made with” or even sole feature lists. Sure, that way you get some indication of the quality of the project, but not of the project’s usability for your very purposes. Your neighbor might suggest the best screw driver to you, but it won’t do you any good, if what you need is a wrench. Also, one must understand that “popularity contest” is a self-perpetuating mechanism. When something is popular it attracts more people, even on popularity and feeling of assurance alone, making it even more popular. If you go with this, you might loose great opportunities of actually using what you really need.
Panda is for people who look for an all-in-one Python-powered game dev middleware. OGRE is for DIY people who only need a renderer, because it would take them too much time to write it themselves. That’s the way I see it.
It’s like asking someone why they use Panda over, let’s say, UDK. UDK is great, it’s a derivative of the industry standard, but I need Python, Linux/Mac support, community and/or (not my case, but surely someone else’s) source code access etc. The sole fact that UDK is better in feature comparison doesn’t mean anything to me.
Oh, and one more thing. You just CAN’T judge documentation based a peak into the API reference. The real value of documentation becomes visible only when you actually start using software. API reference is a must, but with Panda the real power sits in the manual. It describes basically everything one needs to know (the remaining 10 or 15% can by found on the forums). When you’re done with the manual and become fluent, the API reference’s lacks in method descriptions become far less relevant, because you already know which method does what. The manual taught you that, and you use API reference only to remind yourself of names or arguments. And the method names are usually self-explanatory enough. I really don’t see Panda as lacking any kind of documentation.
Just my thoughts.
. Or finding out why others have the opinions they have. Don’t see anything wrong in this, as long as it ends there.