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.
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.
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?
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.