Bugs found in 1.5.0 so far.

We’ve found the following significant bugs in 1.5.0 so far:

  • The x-file parser is not case-insensitive as it should be.
  • Some users having DLL hell problems with regard to the Cg DLL.
  • Attempts to compile on 64-bit linux not working.
  • Somehow, animation interpolation getting turned on by accident.
  • No way to control stream vs sample in OpenAL audio manager.
  • Start menu shortcuts are missing the -E command-line option.
  • Add support for “python default constructors”.
  • David found a fix for the whole python+maya2egg issue.
  • PGMM not in distro. (not exactly a bug, but it’s a reminder for me)
  • Maybe add ODE support.
  • Something to do with crimity and maya2008.

Remind me if I forgot anything.

maybe a bug tracker might be a good idea?

We had a bug tracker for a while, and the effect it had was this: 10% of the bugs got posted to the tracker, and the other 90% got posted to the forums. It just ended up being one more place we had to look for bug reports.

I would also add the slow animation bug :slight_smile:

If I understand correctly, the nature of that bug is that the animation-interpolation has become decoupled from the value of the config variable interpolate-frames. Ie, it doesn’t matter how you set the config variable: in the latter versions, it interpolates, and in the earlier versions, it doesn’t, and we don’t know why. Is that a correct summary of the problem?

So far, yes, though I still don’t understand how that’s even possible, and haven’t been able to reproduce it.


Is the animation interpolation flag stored in the BAM file? If so, could a corrupted model-cache be to blame?

Doh! Yes, that’s it exactly! Of course the interpolate-frames flag gets set in the PartBundle at the time it is first created, and then baked into the bam cache. I totally forgot about the bam cache. Thenceforth, changes to the interpolate-frames variable mean nothing.

birukoff, can you try emptying your model cache to see if the problem goes away?


YES!!! It works now!!! I emptied the modelcache folder, and now it works like dream.
I think it must be added to FAQ somewhere (that after changing interpolate-frames value one has to empty the modelcache folder).

Yes. Actually, I’m not sure if we should really be recommending setting interpolate-frames in the manual anyway, since that’s a global setting; it’s probably better to recommend achieving this same effect via actor.setBlend(frameBlend = True), which is a per-actor setting (and doesn’t get baked into the model cache).


Well, maybe we just need to document it better. interpolate-frames affects the egg loader, not the animation system.

I’ve been thinking about this more. I think this really belongs in the egg file.

fps { 24 }
interpolate-frames { 1 }

And give maya2egg, egg-trans, and the like a command-line option to set the flag for all animation bundles in that egg file.

You’re right, it does. But we also need a way to specify exceptional frames: frames between which you don’t want any interpolation.

Only reason we don’t have both of those is expediency: no one has asked for it yet, and we’ve got other things to worry about in the meantime.


Does panda support a non-fixed frame rate yet? If each frame had its own timestamp, you could express exceptional frames (ie, discontinuities) as two frames that both have the same timestamp, or very nearly the same timestamp.

I would be tempted to implement non-fixed frame rate, not for that reason, but as a means of animation compression (ie, simply discard frames whose values are equal to the interpolated positions of the two adjacent frames).

Panda doesn’t currently support non-fixed frame rates. It would be a useful feature, for this and other reasons.


Don’t know if this really is a bug, but if I enable bloom in the shadows example, the teapot glows, the lights and shadows dont work anymore, but the worst is that the Panda hangs somewhere above the camera and I can just see his feet moving in the air.

EDIT: It works correctly when I switch the bloom on before the rest of the buffers are created.

I think that should be classified as half-bug. The CommonFilters class will move the rendering of the scene into an offscreen buffer, and will turn on shader generation for the scene. Part of the problem might be that the shader generator is overriding the manually-written shaders. That’s not good, that’s a bug. The other part of the problem is that the shadow sample already uses offscreen buffers. Class CommonFilters is creating an offscreen-buffer rig, which may not be compatible with the sample program’s offscreen-buffer rig. I wouldn’t classify that as a bug, just a limitation of what class CommonFilters could realistically be expected to do.

Ok, thanks for the explanation.

I have another tiny something (unrelated). I see the GraphicsOutput class has a way to get a second render texture using getTexture(1), but getTextureCard takes no parameters. How would I get a card for the second texture? This time I’ve created manually a CardMaker, set the frame and applied the texture, but it seems odd to me why getTextureCard doesn’t also provide a way to not only get a card for a the first texture that is not depth/stencil.

You would just do this:

card = win.getTextureCard()

Yeah, but it’s a tiny 2-seconds fix anyway and it wouldn’t do any harm adding it.

Also, if there is no texture that is not depth/stencil in the output, getTextureCard won’t put any texture at all on the card.

I can send you a diff if you want it, but the fix is a 2-line fix anyway.