panda3d as rendering engine? with pygame, pyopengl or pyqt


does anyone have an example of using panda3d as a 3d engine only?

I’d like to use panda3d without its event loop.

Anyone have an example of using it with pygame, and pyopengl?

Or with pyqt?

I see that panda3d can render to an offscreen buffer. Is there a way I can make it use an externally supplied window?


hi illume, its cool to see you here!

For my servers i use my own event loop. So its not that hard. Although i am not using the renders on my server just he config, eggloading, Math and collision. I have successfully decoupled parts of panda3d i am sure some thing similar could be done with rendering.

"Anyone have an example of using it with pygame, and pyopengl? "
No that would be hard because panda3d can be running in DX mode. But even if not panda3d expects the render state in a specific way, if you do use pyopengl (badly written lib btw - maybe stuff?) you would have to leave the gl state the same as you found it in order for this to work. I would not recommend this though due pain this will inflict upon you and run slow.

“I see that panda3d can render to an offscreen buffer. Is there a way I can make it use an externally supplied window?”
I think you can just get the window handle and pass it to panda3d during cation.

It doesn’t make a whole lot of sense to use panda3d with pyopengl, because what panda does at its core is manage the opengl rendering states.

However, you don’t need to use the run() function for the event loop, you can instead just make sure that the task manager gets ticked each time through your own event loop, and it should work okay.

hi treeform, and jwatte.

thanks for the tips.

For this app, I’m using opengl - so forgetting directx isn’t a problem.

I think it should be fine to manage the opengl state between panda calls.

I guess what I want is this (without the panda parts implemented)…

import pygame
from pygame.locals import *
#TODO: import panda stuff.

screen = pygame.display.set_mode((640,480), OPENGL)

print pygame.display.get_wm_info()
print pygame.display.Info()
    window_id = pygame.display.get_wm_info()['window']
    #NOTE: can't get window id on osx with pygame.  Not sure how to get osx window id?
    window_id = 0

#TODO: initialise panda here, with window_id from pygame.
going = True

while going:
    events = pygame.event.get()
    for e in events:
        if e.type in [QUIT, KEYDOWN]:
            going = False

    #TODO: tick panda task manager here.

    #TODO: display panda things here.

#TODO: cleanup/quit panda here.


That’s the right general idea, but note that you’re not passing the OpenGL context to Panda, and that there’s in fact no realistic way to do that, and further that you probably wouldn’t want to do that if you could (it would be really slow and error-prone).

When you pass the window handle to Panda (search the forums for setParentWindow), Panda will use that window handle as the parent object on which to create a new window of its own. This allows Panda to render onto whatever surface you like, but it must own the 3-D context. You can’t interject your own 3-D graphics in the middle of the scene Panda is drawing, and there’s no need for you to create your window with an OpenGL context, and no need for you to call flip() on your window.

If you want to interject some 3-D graphics into Panda’s scene, you’ll be best off creating geometry within Panda to represent those graphics.



the idea would be to run different libraries on top of panda.

So panda would finish its drawing, and then let other libraries do their thing. For example, existing opengl programs, or new programs written with other libraries.

This is how many opengl libraries are used with each other. Many libraries use other libraries opengl contexts. Is there a reason why panda is different?

I guess that no one’s seriously asked for this before.

Well, let me amend that. It does get asked about every once in a while. Is this really so commonly done? Guess I’m just naive about this sort of thing. It still sounds like trouble to me.

It would be relatively easy to integrate a third-party renderer at the C++ level, and I suppose we could, by extension, make it easy to do so at the Python level, by writing a thin C++ wrapper that would simply call out to a Python function pointer that you supply.

Still, Panda really does want to control the whole rendering cycle, for performance reasons. It’s all about reworking the scene into the fastest draw cycles possible; this means traversing all the scene graph, collecting the individual Geoms and sorting them by state (or by depth), then issuing the appropriate draw commands in rapid-fire order. The bigger picture (not yet fully implemented) is to then pipeline this whole process into multiple threads, so that it’s all going on at once. Having to pause the whole process in the middle of it and make an external callback, and then do nothing while that callback does whatever it wants to do, is contrary to its design.

That’s not to say we shouldn’t support it, I’m just explaining why feels weird to me. Certainly, not every application is all about performance, and if you already have an OpenGL library that does X, I can see that you might want to integrate with that library.


this is, you know, not a bad idea… The only problem is that panda3d isn’t programmed as an API, it’s also hardly using Direct3D and OpenGL, so you get higher FPS cuz of HW accel…And this causes GIANT loss of fps and etc. But it’s your life, you can waste your time with programming microsoft-like… :laughing:

I wouldn’t say this is particularly Microsoft-like programming. Quite the opposite: illume is proposing taking different rendering libraries from different origins, and making them work together to produce a single output. This is really what the open source movement is all about.

This is different from Microsoft’s approach, which is: “We’ve got you covered. You don’t need to use any software other than what we provide for you. If you need a particular feature, we’ll add it to our software so you don’t have to consider using anyone else’s.”

So, in this sense at least, it’s Panda’s philosophy that’s more similar to Microsoft’s.

I gave it a bit more thought, this morning. I think the real reason Panda lacks this feature is that it was never important to Disney, and no one else has seen fit to add it. For a professional game developer interested only in releasing finished titles, it’s not a particularly useful feature. However, it’s a great feature to have for the hobbyist or experimental researcher.

That being said, I do think it wouldn’t be at all difficult to add this sort of feature. Especially if you wouldn’t mind letting Panda own the window and the graphics context–creating it, destroying it, and flipping it–and just took advantage of callbacks we provide in the middle of the frame render to add your own stuff to the scene. This is easier because it’s closer to Panda’s current design; if you insisted on being the owner of the window, we’d have to provide a way to tell Panda not to do all of this stuff. Perfectly doable, but it’s more work.


You could try SDL:

And use that as your base to get a GL context up; While also having it take care of keyboard input ect; leaving you to write some kind of scene handler (go go gadget display lists and vertex arrays [not fun imo]), as well as event handlers ect. The primary language for SDL is c++, if you are truly concerned about every drop of performance.



This would be a great start. I know that it would make it usable with SDL/pygame then. Since they can use an existing window… and through them you could then use pyopengl, cgkit etc.

However I’m not sure about qt/pyqt. I’d have to look into it a bit more. With recent qt releases, you can use their entire toolkit on opengl. Which makes it nice for tool making (especially since maya now supports it too).

(Maybe pyqt can be told to use existing windows+contexts… I’ll have to find out and report back :slight_smile:.

Letting panda own the window would be a good start, then once that is working… putting in hooks to make flipping the window would make panda more flexible there too.


Are you saying that you can render QT stuff in a openGL window? Do you have a link to that? I only find stuff for creating a openGL window in QT window.

I second that - that would be amazing. Link pls :open_mouth:


it is mentioned in the latest qt developer newsletter… but I can’t find a link.

Here’s their gl docs though:


It looks like they just got a wrapper for the bush commands, i want real qt widgets in openGL :slight_smile:


yeah, you can use real qt widgets in opengl.

Here’s the part in the docs that shows the feature: … phics-view


Hmm i should look more into this it would be very cool to use QT as a UI ~ a full featured UI that is.

Maybe the best designed UI you currently get.

I’m not a lawyer, but isn’t it perhaps a problem using Panda3D with it’s BSD license together with the Qt requirements? AFAIK Qt programs have to be under a GPL license, therefore it’s only useful if your application is under a GPL license too or you have to pay. There may be a second problem: Compiling Qt for windows with a non GCC compiler is no piece of cake.

I am just starting Panda now, but I have been programming in Pygame and Python for a few years.
The only thing I have disliked so far (except for some of the manuals leaving a few holes) is the lack of control of the events and main loop - as I much prefer pygame’s (and some other libs) approach on this. I guess I could get used to it, but if you can make it integrate into Pygame I would be so happy :slight_smile:

And I gotta say, what a nice engine - keep up the good work!

can’t you control the event loop stuff easily?