Moving window

As you may know, I’m that good-for-nothing newbie who was asking about stereoscopic :laughing:

I kinda found the way to use SSRendering, I found a code somewhere in here that opens a second window that renders exactly the same with a slight offset.

However, every time I render, I have to move the “right eye” window to the next screen myself. I want a code, that moves automatically the window to the extended desktop, so that I do not have to move it myself.

(elaboration: I use two projectors projecting on the same surface, the first shows the desktop, the second shows an extended desktop, as if I had two screens. So when I drag the window, it shows like it wraps around the desktop, but actually it moves onto the second “screen”)

When you open the second window, are you passing a WindowProperties object to the base.openWindow() call? If so, then you can easily place the window where you would like by calling wp.setOrigin(x, y) on the WindowProperties structure before you pass it in.

But creating two side-by-side windows is probably not the best way to do this. It’s usually better to create one big window that spans the desktop, and divide it in half with two DisplayRegions. Most graphics drivers can render to one big window more easily (and more quickly) than they render to two side-by-side windows. There are plenty of examples in the forums of doing this; here’s one of them: [I want to create a stereo camera)

You can easily make this Panda window span your dual desktop with something like this in your Config.prc file:

Assuming your desktop size is 1024 x 768 on each monitor. (You probably don’t want to make your desktop size overly large for this purpose, but you can experiment to see what gives the best performance.)


Thanks, seems simple enough to follow. I’ll try it on Monday and give you feedback (or ask for more help :blush: )

Probably I was too optimistic. It gives me an error:

 File "", line 33
    dr = base.camNode.getDisplayRegion(0)
IndentationError: expected an indented block

I remember at the old code I used (the one that created the two windows) there was a declaration (I don’t know the term for that) that defined “wp” as WindowProperties()…I added


but still gives me an error.

This is the most frequently asked question by new Python developers. Unlike other languages, in Python the amount of whitespace to the left of your code line is very significant, and is part of the syntax. Python uses this to figure out your program’s structural grouping.

The error message indicates that the indentation of this line is inconsistent with that of the line(s) above.


Final edit and closure:

I finally did it. The code (a patchwork of many codes suggested here) does split the default DRegion (in my case, the spanned) in two, and does create and utilise two cameras, and finally does stereoscopic rendering.

I am quoting the code for future reference:

def splitScreen(): 
# This function splits the main display region into two separate 
# left-and-right regions, which represent the left and right eye of 
# the camera. 

# First, disable the default DisplayRegion, which covers the whole 
# screen.
	dr = base.camNode.getDisplayRegion(0) 

# Now, make a new pair of side-by-side DisplayRegions. 
	window = dr.getWindow() 
	dr1 = window.makeDisplayRegion(0, 0.5, 0, 1) 
	dr2 = window.makeDisplayRegion(0.5, 1, 0, 1) 

# Turn off the default camera and replace it with two new cameras, with 
# side-by-side DisplayRegions. 
	base.makeCamera(, displayRegion = (0, 0.5, 0, 1)) 
	base.makeCamera(, displayRegion = (0.5, 1, 0, 1)) 

# Adjust camList[1] and camList[2] positions.
	base.camList[1].setPos(-0.3, 0, 0) 
	base.camList[1].lookAt(0, 20, 0) 
	base.camList[2].setPos(0.3, 0, 0) 
	base.camList[2].lookAt(0, 20, 0)

# Set each display region to show one of the cameras. 

# And make them into left and right stereo pairs. 

# Now that we defined the function, time to call it.

The config.prc file also has to be edited, with this code added:

framebuffer-stereo 1
default-stereo-camera 1
default-iod 0.2 
default-converge 25.0

Plus, the win-size has to be edited so that the width is double than the resolution of the screen. Oh and there has to be added:

undecorated 1

I hope it helps someone else too :smiley:

drwr and ThomasEgi, thanks and you rock :smiley:

In case you need something about digital art, like photoshop or illustrator, do not hesitate to contact me :smiley: (that’s my field of expertise :stuck_out_tongue:)

For the record, there should be no need to adjust the cameras explicit (as you do with camList[1] and camList[2]). The cameras should automatically be offset and facing inwards slightly, due to the handling of stereo rendering internally by Panda (and the fact that you set the two DisplayRegions to SCLeft and SCRight). By setting these apart explicitly, you are interfering somewhat with the good stereo matrices that Panda has already set up.

If you want to increase the stereo effect, you should instead adjust the values of default-iod (the interocular distance, or the distance between the eyes) and default-converge (the convergence distance, or the distance of the point at which both eyes are rotated inwards to look at).

Also, there’s no need to set framebuffer-stereo in your example, because you’re not taking advantage of hardware stereo. You’re explicitly creating two cameras.

Furthermore, you can use, instead of creating two new cameras with your two calls to base.makeCamera(). Using just one camera instead of two will be more optimal, because it will avoid an extra cull pass.

Congratulations! If you are interested in pursuing further work like this, I do recommend working your way through the programming tutorials to help you understand what the purpose of each line of your code is. :slight_smile:


I received today an e-mail from my teacher in which he mentioned that the patchwork code I made ( :laughing: ) works only with certain samples.

He mentioned that it works fine with Roaming Ralph and Looking and Gripping (others as well) but it doesn’t work with samples such as Chessboard and Carousel.

He says that in the programs the code does not work, the screen is spanned to the second screen, but it doesn’t split in two cameras. The code however remains the same in every sample. Why does it work only with some of the programs and not all?

What could be the conflicting code?

I don’t know, but it’s possible to find out. That would mean researching your code in conjunction with the sample applications that work and the ones that don’t. There are lots of approaches to answer this kind of programming question; the most successful is likely to be a kind of systematic A/B comparison, in which you start from case A (a program that works) and gradually change it to be the same as case B (a program that doesn’t work) until you discover the thing that makes it stop working.

Questions like these are why it is important not just to know what code to type to produce a particular effect, but to understand precisely what that code does and why it works. When you understand why it works, then you can also understand the circumstances in which it doesn’t work.

If your professor is asking you to discover why it is that your code doesn’t work in certain circumstances, perhaps he is really asking you to understand precisely what the code is doing when it does work and why it works then.

Could it be that your professor is encouraging you to learn fundamental programming and debugging techniques? :slight_smile:


I don’t think so, he knows I don’t really get on with programming :laughing:

Besides, he doesn’t know python either, what we did was use our reason to mess with the code.

Now messing with two different codes, with the only common point being the “import” commands, is way beyond my league, and way beyond his time.

I thought maybe someone (yes you drwr :stuck_out_tongue:) could help me with that, since guys here probably know about the codes of the samples.

OK, now seriously, Panda is a programmer’s tool. This doesn’t mean you have to be a professional programmer to use it, but it does mean you have to be prepared to employ standard programming techniques, such as basic code design and basic debugging. If you’re not already familiar with these techniques, you’ll have to learn to use them, or you won’t be able to make use of Panda. Really, I’m not just saying this.

It’s like you walked into an art store and told the clerk your professor asked you to paint a picture of a daisy. “Well, you’ll need a paintbrush, a canvas, and some basic paints,” says the clerk. “Great,” you say. “I’ll take them. Oh, and I don’t know how to paint, and I have no interest in learning how. I just need a picture of a daisy. Would you paint one for me? I’ll come back tomorrow to pick it up.”

I’m not here to write your code. I’ll be more than happy to help you write and debug your own code. I’m delighted to help you learn how to use Panda, which means I’m willing to help you learn how to employ basic programming techniques. But I’m not going to just do the work for you.

If you really have no interest in doing the work yourself, then perhaps you can find someone on these boards who will be willing to do this kind of work for hire.

Now, all that said, it does seem that the sort of effect you are trying to achieve–a stereo pair rendered in two side-by-side DisplayRegions–is a common enough technique that it would be convenient for developers if Panda supported it more-or-less automatically, in the same way that Panda already supports shutter-glass stereo, and anaglyph stereo, more-or-less automatically. So, I’ve just added the necessary code to low-level Panda.

So, if you pick up the latest code (not just 1.7.0, it must be tomorrow’s buildbot release or later), then all you will have to do is put the following in your Config.prc file:

side-by-side-stereo 1
win-size 2048 768
undecorated 1

No additional Python code is required. Panda will automatically render a left/right stereo pair into the two halves of your graphics window. It will work for most Panda applications, although a few applications will still fail to render correctly, due to the nature of the application itself. I leave the discovery of these applications as an exercise to the reader. (Here’s a hint: good luck getting a stereo rendering out of Asteroids.)