Feature Requests.

I now have a standing offer: anybody who wants to add a small feature to panda can ask me for help, and I’ll walk you through the process. I’ll help you find the classes you need in the source tree, I’ll explain how they work, I’ll explain how to extend them - I’ll even go so far as to work on the code side-by-side with you through VNC. My hope is that you’ll get the hang of working on panda, and that in time, you’ll become a panda developer yourself.

If you want a new feature but aren’t willing to implement it, you can post it here, but be aware - Panda3D only has a few full-time developers, and they are very overworked. We generally don’t have time to do requests.

Collision Solid: Box
Shouldn’t be much work to do… perhaps if I have some spare time I may look into it, if its not already done by then

Hey, even though I’m one of the devs, I guess I can ask too.

How about reimplementing CollisionGeom? It’s very inefficient at present.

I am wondering if using Bullet for collision detection in panda would be a good idea. It’s opensource, cross platform, actively developed:
continuousphysics.com/Bullet/

Laurens, ODE is also pretty good.

It is slowly being integrated with panda i dont know if bullet will be next on the list.

I didn’t know ODE has integrated collision detection, but reading their website cured that . ODE is fine with me! And it has boxes too:
ode.org/ode-latest-userguide.html#sec_10_7_0

Bullet has built-in continuous collision detection, while ODE doesn’t. ODE user has to figure out the best way to do that based on the nature of the scene.

All physics packages have two major parts: physics itself, and collision detection.

For Bullet:

• poor physics.
• good collision detection, including convex shapes and hulls.

For ODE:

• good physics
• poor collision detection via third-party OPCODE library.

There have been rumors for about one year that ODE is going to drop OPCODE and replace it with Bullet.

Maybe it would be best to give ODE developers some time and let them do the integration of ODE (physics) and Bullet (collision).

enn0x

Some way to draw scalable curves (like for a HUD) would be nice. Maybe something like SVG?

another one that shouldn’t be too much work to implement (though it would not be supported under dx9) is geometry shader support.

shouldnt be much to implement either:
-vertical align for gui objects
-The operands TextureStage.COSrcRed, TextureStage.COSrcGreen and TextureStage.COSrcBlue. I really need them, cuz then I can replace my shaders with combine modes, which is wayyy faster.

Sorry, you’ll have to talk to the graphics card manufacturers about adding new combine operands. Panda just exposes the options that the graphics API gives us, we don’t make up the list.

David

Actually, I suspect that modern cards don’t even have fixed-function hardware any more. I bet they translate everything into shaders.

+1 for Cyan SVG request. SVG could be just like svg2egg importer only that would be 2d and have a little more smarts in it.

I’d love to see consoles (xbox(360), wii, ps3) supported by panda3d

Vector graphics could be nicely supported by making pyamanith (or a similar lib) working with panda3d…

I’d love to see support for them as well, but at least the Wondrous Wii

…yes. I have one and am LOVING Wii Tennis being a tennis player of many years…the Wii mote is just tons-a-fun and panda working there would be amazing and another avenue for panda

cheers
nl

What about merging PNMImage into Texture? Dunno whether this is a reasonable idea…

What do you mean? The PNMImage class manages reading and writing image files from disk. The Texture class manages copying images to and from the graphics engine. They’re related, but fundamentally different operations, and I don’t think you want them to be handled by the same class.

Or maybe you’re really just asking for methods like setXel() added to Texture?

David

Actually, I dont know why they can’t be handled by the same class. And, it could indeed be nice too if functions like setXel are added to the Texture and make PNMPainter paint on Textures as well, so I dont have to convert them every frame in my Terrain Painter code.

Mainly for modularity. As it is now, with the classes separate, you can write a program that uses PNMImage (for instance, image-trans or image-resize) and link it with just a small part of Panda3D. If PNMImage were the same thing as Texture, then such a program would have to link with pretty much all of Panda3D, including all of the graphics context and rendering code, even though it’s never going to do any rendering.

This is the function of classes, to separate different concepts from each other. To take an extreme example, we could technically combine all of the different classes in Panda into one enormous class definition that did everything. But then it wouldn’t be very object-oriented any more, would it?

Though this is technically possible, it would be difficult. One of the properties of PNMImage is that all images are laid out (almost) the same way in memory, regardless of their properties. This makes it very easy to write a class like PNMPainter, which can paint equally well on grayscale, grayscale/alpha, 24-bit, 32-bit, or 64-bit images. However, the memory in a Texture is laid out differently according to its texture properties, to match the format the graphics hardware expects, for fast upload to the graphics hardware. Thus, to make a PNMPainter paint directly onto a Texture, there would have to be an interface layer that does the conversion to the appropriate format. But that’s exactly what a PNMImage is, isn’t it?

I suppose you could have a class that did this automatically, without the need to explicitly call Texture.load() from your PNMImage. But that doesn’t sound that useful, and it wouldn’t run any faster than if you made the call yourself. It would just hide the underlying operation from you.

David