Has Anyone Experienced This?

I was working on creating a simple railing for a balcony. The railing itself is one flat surface mesh with a png image mapped, so I can have transparency between each individual rail. (png transparency)

I had the transparency set to TransparencyAttrib.MDual. There was no issues with this until I added a pole at the end of the railing; since the railing was flat, I figured some “end caps” would be nice.

I noticed jerking in the graphics when moving along the railings. I thought there was something wrong with the poles I added to the railings end points; that was hard to believe since the poles were a very simple mesh…practically a 10 vertice cylinder with some simple modification.

So I ended up dumping the first pole model and made a yet simpler one; and I hate that I did that, because it turns out…the poles were not the issue at all. I even thought scaling the railing texture down would help, but to no avail.

The Jerking was being caused because I had the railing alpha mode set to TransparencyAttrib.MDual. This is what I don’t understand. The railings with the poles are dirt simple models, so there’s no geometry strain at all there, but yet the TransparencyAttrib.MDual setting for the png file transparency will cause Jerking…?

This is where P3D pisses me off!!

Now I have no choice but to “can” the TransparencyAttrib.MDual setting, but that leaves a poor visual effect with the railings, on some angles where you see railing behind railing, because the transparency isn’t blended smoothly.

Anyone experienced anything like this before? WTF is up with P3D and TransparencyAttrib.MDual? I know that setting can eat up some fps, but the “JERKING”…why the jerking?

“Got’dam’it!!!”

:laughing:

What do you mean by “jerking”? Perhaps you’re referring to the effect known as “tearing”, which can happen when you have disabled sync-video in your Config.prc?

I don’t know what else you might be referring to.

David

Nope. Imagine if you could take hold of the visuals on your screen with both hands, and then you quickly move the visuals to the left and then back to the right…really fast. If you repeated that over and over, the screen would look like it is quickly shaking or “jerking.”

That’s what my visuals are doing.

What ever the issue is…it’s somewhere down the pipeline. It seems like every time I update an egg file or add a new one…the “jerking” starts or gets worst. I restarted my PC and everything is running good again. But I’m afraid that if I make another update…that “jerking” might come back.

How do you Dump Panda’s Cache, so it can rebuilt itself?

That sure does sound like a hardware issue to me, or maybe a driver bug. Does the same thing still happen if you switch to tinydisplay?

You can clean out panda’s cache by emptying the cache directory, which is whatever directory is named by model-cache-dir in your Config.prc file. But it’s hard for me to see how this could be related to what you describe.

David

I think I solved the issue, but I’m going to keep testing. I must say though… “WOW!” I had no idea Panda was so delicate! (and pushy)

Using this code:

base.cam.setY(+40)
base.cam.setY(-40)

Was causing Panda to drop a claw in my “arse.” Why the hell did the screen start going crazy…I don’t know. What’s even more strange is the fact that code has been every since the start of the project and caused no problems at all, but I had to change it to the following:

base.cam.setPos(base.cam.getPos() + camvec*(camdist-self.camCloseFar))
base.cam.setPos(base.cam.getPos() - camvec*(self.camCloseNear-camdist))

This new code made Panda happy and it removed its sweet tooth from my anal. (for now) Panda was so happy with this change, my fps…which was bouncing below 60 a little, hit 60 flat without movement!!

I am still scratching my head from that one. I understand using the built in APIs to simplify code is much faster than doing it mostly with Python alone. That’s why I changed my python driven code to include more of the Panda.

Simple stuff like changing this:

self.PheShad.setX(self.PheX+self.PheSpeedR*sin(self.PheDir*pi/180))

To this:

self.PheShad.setFluidX(self.PheShad, +(self.PheSpeedR)*globalClock.getDt())

That second piece of code is more Panda friendly as well as faster. I am only limited by the amount of Panda API I know and since I’m new to Panda still, it’s no surprise if I write something in python that could be faster if combined with more Panda driven APIs calls.

I wish the C++ was well documented.