Skip navigation
piercer2
Currently Being Moderated

Not understanding how float4 works

Apr 5, 2011 8:21 AM

Hi all,

 

I am trying to learn from the exaples and documantation, but I seem to be stuck at one point where I don not understand what is going on.

 

I am trying to simplify the examples for myself massively so that I understand what is going on and so am trying to remove the texturing on the cylinder and shade it as a completely flat colour.

 

Problem 1:

 

If I take phongShaderCylinderSphereTextured.pbmk and change its evaluateFragment to this

 

    void evaluateFragment()

    {

        float4 color1 = sample(inputImage, float2(interpolatedCoord.x, interpolatedCoord.y));

        color1.r = 0.5;

        color1.g = 0.0;

        color1.b = 0.0;

        color1.a = 1.0;

        result = color1;

   }

 

Then I get, as I would expect, a completely flat red cylinder. However changing color1.a has absolutely no effect whatsoever - if I set it to 0 then the flat red cylinder still shows. What is going on?

 

Problem 2:

 

If I write instead

 

 

    void evaluateFragment()

    {

        float4 color1 = float4(0,0,0,0);

        color1.r = 0.5;

        color1.g = 0.0;

        color1.b = 0.0;

        color1.a = 1.0;

        result = color1;

   }

 

then I see nothing at all. Again I have absolutely no idea what is going on.

 

so

 

1) What is wrong with my extremely simple code?

2) What is the correct way to specify a float4 literal?

3) What are the ranges for the r, g, b and a values of a float4 (it seems that r, g and b have to add up to one - is that correct?)

 

Thanks for any help

 

Conrad Winchester

 

 

 

 
Replies
  • Currently Being Moderated
    Apr 5, 2011 1:07 PM   in reply to piercer2
    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 AGAL
    uploader 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 used
    below.
    Chuck.
     
    |
    Mark as:
  • Currently Being Moderated
    Sep 26, 2011 11:55 AM   in reply to AIF Chuck

    This problem has been fixed in preview 3 of Pixel Bender 3D

     

    Bob

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points