This content has been marked as final. Show 2 replies
Hi Conrad,Your two examples should be producing the same result. You are seeing a bug either the construction of the AGAL code in the pb3dlib or in the AGALuploader in the version of molehill we were using for our first public drop. Channel by channel vector generation had a number of problems earlier on and I suspect you're seeing that. We will need to investigate.Your color values do not need to add up to be one. The numbers in the channels don't need to be 0..1 at all... or positive. You can run the numbers higher for doing HDR calculations. On a desktop 3D system, you can read back these floating point values and make use of them, but when they are drawn to the surface they will be clamped to 0..1 with 256 possible levels per channel. RGB=1,1,1 is white and 0,0,0 is black. Alpha controls opacity with 0 being clear and 1 being completely opaque. Molehill allows readback into a Bitmap, but the values are clamped and represented as an unsigned char per channel rather than as a float.As for specifying float4 literals, pb3d currently handles something of the form float(r,g,b,a) best as will recognize that as a constant right off. Building up the constant means more time in temporary registers as we have yet to write optimization patterns for the type of construction you usedbelow.Chuck.
This problem has been fixed in preview 3 of Pixel Bender 3D