Excellent, thanks!
When you get the chance, could you maybe look at this bug report:
bugs.launchpad.net/panda3d/+bug/321348
I’m not so sure about the proposed patch, though, since it requires the vectors to be normalized while the current doesn’t. (that said, I don’t have a clue what the difference is between relative_angle_deg and angle_deg).
I can smell 1.6.0 already 
I’m investigating a bug regarding FBO’s and cubemaps – the code somewhere contains this:
if (get_rtm_mode(i) != RTM_bind_or_copy) {
continue;
}Meaning when the mode isn’t RTMBindOrCopy, it will throw funny errors and do weird stuff. When I uncomment these lines, it appears to work. Can I safely remove these lines (I have no clue why Josh put them there) or is there a specific reason why we should force RTMBindOrCopy?
(I should point out that base.saveCubeMap doesn’t work currently with FBO’s for this reason, since it doesn’t use RTMBindOrCopy).
I have no idea why that is there either. I guess we can comment it out for now and see if anything breaks.
David
It can’t break any more than it already is broken. Just checked it in.
Hmm, there’s still some path weirdness. In a makepanda build, if I run the Media Player sample, I’m getting this error:
:gobj(error): Texture::read() - couldn't read: /home/pro-rsoft/Projects/panda3d/samples/Media-Player/PandaSneezes.avi
:gobj(error): Texture "/home/pro-rsoft/Projects/panda3d/samples/Media-Player/PandaSneezes.avi" exists but cannot be read.VLC can play it without any problems. Could this be related to the removal of model-path or so?
(My makepanda 1.6.0 install can’t auto-locate my /etc/Confauto.prc and /etc/Config.prc anymore either, but I always assumed it was my weird setup. Might be related?)
It doesn’t sound like a path problem. It says “texture exists but cannot be read.” That sounds like it was unable to open the file, or the ffmpeg library balked on it.
David
Hmm, to revisit the old scaling bug: I’m still experiencing some similar issues. I can’t seem to get a texture from a 800x600 window applied to a card without problems. (It’s set to RTMBindOrCopy, so I don’t see how panda itself could do any rescaling. How is it done there?)
I explicitly need to call colortex.setTexturesPower2(0) to get it working. CardMaker.setUvRange(colortex) doesn’t help me.
Could you maybe explain a bit how scaling works with buffer textures and what the cause of the original bug was?
I can try to create a small sample to repro if you want.
In this case, Panda is supposed to create a 1024x1024 texture, and only use the bottom 800x600 part of it. I’m surprised that cardMaker.setUvRange(tex) doesn’t work for you; that should be exactly the correct solution (though it might be necessary to render at least one frame of the texture buffer before you do this; because before then, the texture hasn’t been created and the texture sizes haven’t been set up).
The bug that I fixed was in GLGSG::framebuffer_copy_to_texture(); in the case of a newly-created texture, it was not creating the full texture size before subloading the smaller region into it, but instead attempting to create the texture directly at the smaller size.
David
We’re seeing the vertex color problem on all our machines. Vertex colors don’t appear when using shaders, even when ‘ColorAttribs’ are set on all nodes. I ran the ‘Toon-Shading’ demo to make sure there wasn’t something weird in our code, but the problem shows up there too. The dragon is white.
Is anyone else still seeing this? My build is a week or two out of date by now.
Are you sure it’s missing vertex colors? If you assigned not more than a ColorAttrib it is passed to the shader as uniform float4 attr_color.