It's [[R,G,B,A],[R,G,B,A],...] for RenderLayer.rect, which is the Combined pass. For other channels such as Z, write to the corresponding RenderPass.rect.
Brecht. On Fri, Dec 17, 2010 at 3:57 PM, Doug Hammond <doughamm...@hamsterfight.co.uk> wrote: >> For render layers and passes you can already write pixels, the "rect" >> property is an array of pixel values. >> > > Really!? Then this appears to be mostly a documentation issue. > > How should the data in this array be formatted? [RGBRGBRGB...] ? > What about adding A and Z channels ? > > Cheers, > Doug. > > >> >> Brecht. >> >> On Fri, Dec 17, 2010 at 2:20 PM, Doug Hammond >> <doughamm...@hamsterfight.co.uk> wrote: >> > Another +1 request here too, especially if the pixel write extends to >> > RenderLayer >> > >> > Cheers, >> > Doug. >> > >> > >> > On 17 December 2010 10:51, Alberto Torres <kungfoo...@gmail.com> wrote: >> > >> >> A function for reading/writing pixels of image buffers from python >> >> would be *VERY* useful. I already made 2 scripts which writes raw BMPs >> >> and I can't read existing image buffers. >> >> >> >> >> >> On Thu, Dec 16, 2010 at 8:06 AM, Hart's Antler <bhart...@yahoo.com> >> wrote: >> >> > Daniel raises a good point here, and i'm sure there are others who >> need >> >> the functionality. >> >> > There is another problem, lets imagine that even if PIL was available >> for >> >> Python3, then the user must install Python3, and PIL - what a pain and >> error >> >> prone process. And not very portable either since Ubuntu is going to >> come >> >> with its own version of Python3 that may not be compatible with whatever >> >> version blender was compiled with. >> >> > The solution seems to be ctypes, and for some basic commonly used libs >> >> (like libpng for example) to be precompiled for all platforms, >> >> and distributed right along with blender by default. The ctypes python >> >> wrappers themselves do not need to be included with blender as those are >> >> likely to rapidly evolve over time, but the precompiled libs should be >> >> included - why not it will hardly inflate the download size? >> >> > Scripters should not have to ship their scripts with libs compiled for >> >> every platform. It should be pretty easy to add a few extra libs to the >> >> cmake build process, i'm sure there is already so many libs that blender >> >> already uses that could be exposed by ctypes. >> >> > -brett >> >> > >> >> > --- On Tue, 12/14/10, Daniel Salazar - 3Developer.com < >> zan...@gmail.com> >> >> wrote: >> >> > >> >> > From: Daniel Salazar - 3Developer.com <zan...@gmail.com> >> >> > Subject: Re: [Bf-committers] Getting pixel color for a vertex (the >> stupid >> >> way) >> >> > To: "bf-blender developers" <bf-committers@blender.org> >> >> > Date: Tuesday, 14 December, 2010, 11:30 PM >> >> > >> >> > Damn... this is bad, specially since Python 3 has no image module >> >> > (PIL), there's just no way.. unless you pick a simple format like a >> >> > BMP and read the data straight from file.. still procedurals would be >> >> > left out. Also the Fracture Tools script need access to texture values >> >> > for cracking objects based on textures and I have needed it >> >> > personally. I hope this gets fixored >> >> > >> >> > Daniel Salazar >> >> > www.3developer.com >> >> > >> >> > On Wed, Dec 15, 2010 at 1:19 AM, Hart's Antler <bhart...@yahoo.com> >> >> wrote: >> >> >> Getting a UV texture's pixel value per vertex, the stupid way. >> >> >> (this should be rewritten as a C function exposed to Python) >> >> >> This script does the following hack to get the pixel value: >> >> >> 1. copy the object >> >> >> 2. apply a displace modifier >> >> >> 3. for each RGB set the ImageTexture.<color>_factor to 1.0 and >> others >> >> to 0.0 >> >> >> 4. for each RGB bake a mesh (apply the displace modifier) >> >> >> 5. for each RGB find the difference of vertex locations >> >> >> 6. apply the differences as vertex colors >> >> >> >> >> >> http://pastebin.com/FJWKSGBR >> >> >> >> >> >> for some reason the values are off and always tinted green. >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> Bf-committers mailing list >> >> >> Bf-committers@blender.org >> >> >> http://lists.blender.org/mailman/listinfo/bf-committers >> >> >> >> >> > _______________________________________________ >> >> > Bf-committers mailing list >> >> > Bf-committers@blender.org >> >> > http://lists.blender.org/mailman/listinfo/bf-committers >> >> > >> >> > >> >> > _______________________________________________ >> >> > Bf-committers mailing list >> >> > Bf-committers@blender.org >> >> > http://lists.blender.org/mailman/listinfo/bf-committers >> >> > >> >> _______________________________________________ >> >> Bf-committers mailing list >> >> Bf-committers@blender.org >> >> http://lists.blender.org/mailman/listinfo/bf-committers >> >> >> > _______________________________________________ >> > Bf-committers mailing list >> > Bf-committers@blender.org >> > http://lists.blender.org/mailman/listinfo/bf-committers >> > >> _______________________________________________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers