[FIXED] 1.5.0 RC: strange slowdowns when looping animation

EDIT: This issue has been fixed. See FAQ in the manual for solution.

Testing 1.5.0 release candidate (February 28 ), I have found strange slowdowns when looping animation.
I test with my Roaming Ralph modification (see this thread: discourse.panda3d.org/viewtopic.php?t=3830)
With Panda 1.4.2 I get steady 200+ fps with that code, both when Ralph is standing and animated. With 1.5.0 RC I get same 200+ fps when he is standing, and as soon as he is animated, frame rate falls to 130-140 fps (when standing still again, 200+ fps are back). It seems 1.5.0 plays animations much slower then 1.4.2.

I’ve been trying to reproduce this, and I’ve been seeing some very strange results. First, I wrote a simple program where there’s nothing but ten animated characters in the middle of the screen, and a button to start and stop the animation. What surprises me is that 1.4.2 and 1.5.0 both give me very weird results.

When the character is not animating, I get a steady 375-378 FPS from either version.

When the character starts animating, it goes to about 215-220 FPS. It stays in that range for a few minutes, then all of a sudden jumps to 310-315 FPS. Then, after a few minutes, it jumps back down to 215-220 FPS. It continues to vacillate like that indefinitely. This bimodal behavior exists in both versions. I have no idea what’s happening.

Here’s a pstats readout. You can see it shifting from the faster framerate to the slower framerate:

Unfortunately, pstats shows that its pstats itself which is acting bimodally. But that’s nonsense, the bimodal behavior existed before I even turned pstats on.

Note that egg files describe animations as a series of frames that are to be played back at a specific frame rate, typically 24 or 30 fps. By default, when you play an animation, Panda will only recompute the animation when it changes, and do nothing on the other frames.

This means that if you are rendering at frame rates higher than the animation frame rate, there will be some frames where the animation does not change. These frames are much faster to compute than those in which the animation does change.

This sort of oscillating weirdness can happen because of this. It’s the sort of oscillation you get when two waves of slightly different frequency are interfering with each other. It’s the same thing you hear when two band instruments are slightly out tune with each other.

Try setting either:
even-animation 1
or:
interpolate-frames 1

The even-animation variable forces Panda to recompute the animation even if it doesn’t think it needs it, which makes every frame run the same slow speed. This reduces your average frame rate substantially, but it should remove the weird oscillation effect.

The interpolate-frames variable tells Panda that you want to interpolate the animation between each specific frame given in the egg file. This amounts to about the same thing as even-animation, except that it is computing a new frame each time, instead of recomputing the same animation over and over again.

David

Hmm, I have some concerns about this. Are you sure this is really true? No matter how good our animation system is, it will certainly require more than 0 time, so I would expect your frame rate to drop at least a little bit when you start animating a model.

When Ralph is standing, is he truly unanimated, or is he playing an idle animation? If he’s playing an idle animation, then the change in frame rate isn’t due to the animation system, since it takes the same amount of time to play an idle animation as it does to play a running animation. Instead, the change is probably due to the collision system.

But we need more information in order to diagnose the situation more fully.

David

I tested with the Panda3D 2008.03.04, the problem remains.
I wrote the code specially to test the animation; it contains no collisions or anything to affect the results. Here is it:

from direct.actor.Actor import Actor
from direct.showbase.DirectObject import DirectObject
from direct.task.Task import Task
from pandac.PandaModules import loadPrcFileData

#loadPrcFileData("", "even-animation 1")
#loadPrcFileData("", "interpolate-frames 1")

import direct.directbase.DirectStart

modelsDir = "Roaming-Ralph/models/"

class World(DirectObject):

    def __init__(self):
        self.actor = Actor(modelsDir+"ralph",
                                     {"run" : modelsDir+"ralph-run"})
        self.actor.reparentTo(render)
        self.actor.setScale(.3)

        self.keyMap = {"animate" : 0}
        self.accept("a", self.setKey, ["animate", 1])
        self.accept("z", self.setKey, ["animate", 0])

        self.animationLoops = 0

        taskMgr.add(self.updateWorld, "updateWorldTask")

    def setKey(self, key, value):
        self.keyMap[key] = value

    def updateWorld(self, task):
        if self.keyMap["animate"] and not self.animationLoops:
            self.actor.loop("run")
            self.animationLoops = 1
        if not self.keyMap["animate"]:
            self.actor.stop()
            self.animationLoops = 0
            
        base.camera.setPos(10, 10, 10)
        base.camera.lookAt(self.actor)

        return Task.cont

w = World()

run()

As you can see, when Ralph is idle, he is not animated (all animations are stopped).

When I launch this code in 1.4.2, my fps are above 200: when Ralph is animated, the fps are a bit lower then when he is not animated, but still, fps are above 200+. Something like 210 fps without animation, and 200 fps with animation.

In 1.5.0 RC, when Ralph is not animated, I get the same 200-210 fps, as in 1.4.2. But as soon as I start animation, fps fall below 150. This issue appears all the time, not just occasionally.

Josh, I tried to run this code for some long time but I didn’t notice the bimodal behavior you described (neither in 1.4.2 nor 1.5.0). I don’t know, maybe I ran it not long enough :confused:

David, neither “even-animation 1” nor “interpolate-frames 1” help. In 1.5.0 with an animated model I get much slower frame rate then in 1.4.2.

I’m testing this on my own computer, and I don’t see the same thing. I get 976 FPS when ralph is standing still, and 973 FPS when he’s running, both versions of panda.

Could it be graphics card or driver related? It’s possible, for instance, that the latest version of Panda is more efficient in terms of collecting more vertices into fewer vertex pools, which means better performance for most modern graphics cards. But it also might mean more vertices have to be uploaded when the character animates, which could translate to poorer performance for certain older graphics cards.

What kind of graphics card are you running on, and what kind of operating system?

David

Windows XP Home Edition SP2, ATI Radeon X1600 with drivers v8.1 (January). This is not old. Quite slow card but still I wouldn’t say it’s old.
I have downloaded drivers v8.3 (March). I will tell if the problem is still there after installing them.
EDIT: I have checked with the new drivers. The problem is still there.

960 frames per second?! :smiley:
You must have a new computer!
Mine’s barely a year old and I’m thinking I should just
donate it to a thrift store or something and get a new one.
Dual core is fine if you have a lot of time on your hands to wait around
for it to finish processing, and get a measly 150 frames per second.

Hmm. What is the output of:

self.actor.ls()
self.actor.analyze()

for each version of Panda?

David

I will check. Right now I am installing different Panda builds from the download page. Buids 1.4.2, panda3d-2007.12.11, panda3d-2008.02.12 and panda3d-2008.02.27 work excellent, no slowdowns. The panda3d-2008.02.28 build has the problem.

The output of Panda3D 2008.02.27 (no slowdowns):

PandaNode Ralph T:(scale 0.3)
  Character __Actor_modelRoot
    GeomNode  (2 geoms: ColorAttrib CullFaceAttrib TextureAttrib)
3 total nodes (including 0 instances); 0 LODNodes.
1 transforms; 0% of nodes have some render attribute.
2 Geoms, with 2 GeomVertexDatas and 2 GeomVertexFormats, appear on 1 GeomNodes.
4748 vertices, 4748 normals, 0 colors, 4748 texture coordinates.
GeomVertexData arrays occupy 158K memory.
GeomPrimitive arrays occupy 21K memory.
2374 vertices are unreferenced by any GeomPrimitives.
1 GeomVertexArrayDatas are redundant, wasting 5K.
3550 triangles:
  112 of these are on 36 tristrips (3.11111 average tris per strip).
  3438 of these are independent triangles.
1 textures, estimated minimum 768K texture memory required.

The output of Panda3D 2008.02.28 (with slowdowns):

PandaNode Ralph T:(scale 0.3)
  Character __Actor_modelRoot
    GeomNode  (2 geoms: ColorAttrib CullFaceAttrib TextureAttrib)
3 total nodes (including 0 instances); 0 LODNodes.
1 transforms; 0% of nodes have some render attribute.
2 Geoms, with 2 GeomVertexDatas and 2 GeomVertexFormats, appear on 1 GeomNodes.
4748 vertices, 4748 normals, 0 colors, 4748 texture coordinates.
GeomVertexData arrays occupy 158K memory.
GeomPrimitive arrays occupy 21K memory.
2374 vertices are unreferenced by any GeomPrimitives.
1 GeomVertexArrayDatas are redundant, wasting 5K.
3550 triangles:
  112 of these are on 36 tristrips (3.11111 average tris per strip).
  3438 of these are independent triangles.
1 textures, estimated minimum 768K texture memory required.

As far as I can see, they are identical.
I hope the posted information will help to hunt down the bug :slight_smile:
Since it’s almost 5 am here, I go to sleep.

I have a dell optiplex 755 quad-core. We paid $1200 for it. It’s not top-of-the-line, but it’s a very fast computer for the price. The video card is a radeon x700: quite average.

My motherboard is upgradeable to quad core,
but I haven’t yet because I used to think my computer was fast enough.:smiley:

Right now, Panda3D only uses one core anyhow. You’re not going to see any framerate improvements by switching to quad-core.

Are you using integrated video? That can be really slow.

No I still haven’t tried to use video,
I was thinking about using some for a loading screen though,
which is probably really clever for quick loadup times.
I thought you had a secret way to utilize 4 processors :smiley:

The discussion goes a little bit off-topic :wink:
Back to the subject, as far I can see, changes made on 27th and 28th of February were related to animation system, and slowed Panda significantly. Can something be done about it? If there is anything I could help with, please, let me know (although my abilities are limited since I don’t know C++).

Josh, are you able to determine the code changes between those two builds? Are there tags in the CVS tree corresponding to the builds, or can we rely on the checkout date?

David

There are no CVS tags. However, you could download both versions off the panda website and then do a “diff.” You’d only need “source code, part 1 of 3.”

Hmm, there are a number of changes between those two releases, but mostly having to do with texture and offscreen buffer management, and some shader stuff. Certainly nothing to do with the animation system. The only thing that looks even remotely possibly related is my change to DXGeomMunger.

Birukoff, are you running in OpenGL or DirectX? Does it demonstrate the same behavior if you switch to the other API?

Is it possible for you to use PStats to determine what section of the frame the slowdown is occurring in?

David