I am having the exact same problem that SheepWillPrevail mentions.
I am running a pretty strange system though, Windows XP x64 with two ATI HD 3600 with Crossfire support enabled.
Using Panda 1.6.2
Actually, now that I recall, I used to have those same problems with some demos in the “demoMaster” application from chleung. I only have those problems when loading certain samples, usually when loading the standard world background with grass and skydome that some demos come with it… it started flickering like mad if I remember correctly.
One interesting thing about it its that when I run demomaster, ad turn the GUI on, that flickering instantly disappears.
Maybe I am wrong, but could be these two issues related? Or maybe I am just making stuff up
Hope this can get fixed… it is kinda strange indeed
May be SheepWillPrevail can run demomaster with the “GUI on” as suggested by Edwood, to see if the problem is gone ? Yarr is also included in demomaster.
It looks like the flickering is actually caused by the camera rapidly alternating view directions; it has nothing to do with the shader or the offscreen buffer.
Something in either the move task or the controlCamera task is going berserk. When I print out the camera.getNetTransform() each frame, it looks like this:
I have no idea why the presence of the gui should affect this. Maybe that just changes the frame rate, which changes the amount of “elapsed” time computed each frame, which in turn changes the scale of the camera motion; or something like that.
I don’t have more time to research it further right now, so I leave it in your capable hands to figure out exactly what the code is doing wrong in there.
Demomaster is working without incident. Thank you for the hint about the camera transform, I’m sure I’ll figure it out. When I do I’ll post the updated Yarr.
I’m trying to restart learning Panda3D after a long time working on other stuff. Panda’s looking better than ever. This code example is very interesting to me so I thought I would try to find the bug. This is primarily just to help other newbies figure out what is going on.
The code is trying to look at ralph and the floater in the move function but also setting the camera heading and pitch in controlCamera. We can make it not flash between two views (meanwhile doing the least damage?) by commenting out 4 lines. To make the camera behave more like the original roaming ralph, comment lines:
423, look at ralph
548, set camera hpr
556, set camera position
579, change camera focus
To make the camera behave more like the author intended, with mouse control to look around (but not move in and out), comment lines:
423, look at ralph
531, look at floater
556, set camera position
579, change camera focus
( I’m not clear yet why it’s necessary to comment the last two lines in both cases. Just one of many things I don’t understand. )
Now the camera doesn’t start out looking at ralph. We could put that line in the init section instead of the move function. Due to the steep terrain, the camera has a clipping problem. One fix is to check the z height for the camera similar to what was done for ralph. We can replace the camera collision code in lines 512 to 523 with this:
x = base.camera.getX()
y = base.camera.getY()
z = self.terrain.getElevation(x,y)*self.terrain.getRoot().getSz()
if base.camera.getZ() < (z + 2.0): base.camera.setZ(z + 2.0)
That’s it so far. Lots more to learn. The current camera is now somewhat broken. I’m going to make a 1st/3rd person chase camera for this as an exercise. (Reinventing the wheel, lol)
I suspect the code in this sample was lifted from the original Roaming Ralph sample. As I recall, in that original program, the camera code was written by a student who presumably understood matrix arithmetic much better than he/she understood Panda’s higher-level interfaces for transforms. The resulting code was incredibly hard for anyone else to read and comprehend, which made it a particularly bad choice for a sample program that was alleging to illustrate how to use Panda.
That code was replaced in more recent releases with a much clearer camera-movement system that takes better advantage of Panda’s high-level interfaces, and doesn’t muck around so much in the matrix math.
It might be worthwhile comparing this sample to the current Roaming Ralph sample in the distribution, and/or lifting the new camera code from the new Roaming Ralph.
For those who are interested, here is a new version of Yarr.py with the camera view thrashing fixed. I also got rid of the obscure matrix calls thanks to David’s suggestion. I ended up merging the controlCamera functions into move since both were trying to control the camera. I also changed to a 1st/3rd person chase camera with mouse look, mouse wheel zooming, y-axis mouse invert, and typical wasd movement. Zoom in far enough and it becomes a 1st person view. I haven’t touched (or looked at yet) the terrain, water, or shader code, although there seems to be something in the water reflections that is very sensitive to mouse movement. The camera code suffers a bit from feature creep and is not elegant, particularly when trying to keep the camera from clipping into the terrain. The view distance is reduced when necessary to try to maintain the desired camera pitch, so it will zoom in and out depending on the terrain.
This file should go into the same folder as the old Yarr.py file. I called it Yarr_new.py although this is my first experience with Mediafire’s free file hosting and don’t quite know what to expect. lol.
