I’m guessing that the texture is in fact intact in the screenshot, but the alpha channel on those pixels is 0. When you save a screenshot, it also saves the alpha channel of the framebuffer (if you specify a file format that supports alpha, such as png), but the alpha channel is normally invisible, and if you haven’t been thinking about setting the alpha channel to a specific value when you set up the scene, it might have surprising values in it. In particular, it might have 0 where you want to see detail in your image, and many image-display programs will interpret 0 as transparent or plain white.
Solution: either use an image format that doesn’t support alpha (such as bmp or jpg), or take care that your alpha values are set to non-0 in your scene, or remove the alpha channel after you have saved the screenshot.
In practice, you have to go out of your way to really control alpha, but the key points are:
(a) make sure your clear (that is, background) color is (0, 0, 0, 1) instead of (0, 0, 0, 0) or anything else ending in 0.
(b) make sure you don’t have alpha on any of your models or textures. If you are not using transparency, this is easy. If you are using alpha for transparency, then use a blend mode that doesn’t copy the alpha value to the framebuffer. This precludes the use of multisample alpha, which is an advanced alpha mode anyway.
However, changing the last coordinate to 0 didn’t fix it.
I need opacity on the pictures of my streetlamps, because they aren’t rectangular textures. They need to only be opaque at mask coordinates. The key features of the snippet are setTexture to a texture that was loaded in the two-argument constructor, texture and opacity. Then I set an Attrib of:
Before you go too far down this route, make sure that my analysis is correct: that if you remove the alpha channel from the screenshot image, it looks as you expect it to. Note that you can use the command “image-trans -chan 3 -o output.png input.png” to strip the alpha channel.
And, if that sort of process is sufficient, I’d say stick with it, and don’t worry about what goes into the framebuffer–it’s probably not worth it, unless you really want to put specific alpha values at specific points in the resulting screenshot.
If bytes 0…N are defined to be “a PNG file”, then the PNG file format is well defined, but somewhat useless.
Less sarcastically, if 1 byte in every pixel is defined to be “assorted purpose”, then the format is well defined, but also useless. Or, if the purpose of the idolated “fourth channel” is one of two things, but no bytes indicate which of the two, then the format is well defined but only as useful as our best guess.
I take you to say that the latter is the case; specifically, that the syntax is defined, but the semantics is not.
Yeah. PNG does do a pretty good job of defining the semantic interpretation of the RGB channels, but I don’t believe it says anything about the alpha channel. If anything, it implicit says that alpha channel means transparency, where the background depends on the context in which the image is displayed.
This means, of course, that when Panda writes a value into the alpha channel that doesn’t necessarily mean transparency, then Panda is violating convention. But maybe the alpha channel should mean transparency; Panda doesn’t really know what you have in mind for the alpha channel.
Sure, image-trans is just using the PNMImage interface, which you can access directly from Panda. For that matter, you can use base.win.getScreenshot() instead of base.win.saveScreenshot() or base.screenshot() to retrieve the screenshot directly into a PNMImage, instead of writing it to disk, and then you can strip off the alpha channel yourself before writing it wherever you want it.