tumbler example is incorrect

[GoogleCodeExporter]

This is a bug report from Assaf Raman (in cc) who has ported Ogre3D to Native 
Client. See below:

===============================================================
Hi,

I just fixed a very annoying bug that corrupted the OGRE demo colors.
Here is how the image should have looked (and the way it looks now):
https://sites.google.com/site/assafogre3dforumfiles3/home/good.jpg (also this 
picture is available as an attachment to this issue)

And this is the way it looked before my fix:
https://sites.google.com/site/assafogre3dforumfiles3/home/bad.jpg (also this 
picture is available as an attachment to this issue)

The fix was to change init attributes for pp::Graphics3D.

The source for my code was the tumbler example.
Original code:
    int32_t attribs[] = {
        PP_GRAPHICS3DATTRIB_ALPHA_SIZE, 8,
        PP_GRAPHICS3DATTRIB_DEPTH_SIZE, 24,
        PP_GRAPHICS3DATTRIB_STENCIL_SIZE, 8,
        PP_GRAPHICS3DATTRIB_SAMPLES, 0,
        PP_GRAPHICS3DATTRIB_SAMPLE_BUFFERS, 0,
        PP_GRAPHICS3DATTRIB_WIDTH, size_.width(),
        PP_GRAPHICS3DATTRIB_HEIGHT, size_.height(),
        PP_GRAPHICS3DATTRIB_NONE
    };
    context_ = pp::Graphics3D(instance, pp::Graphics3D(), attribs);

The code that fixes the issue looks like this:
    int32_t attribs[] = {
        PP_GRAPHICS3DATTRIB_ALPHA_SIZE, 0,
        PP_GRAPHICS3DATTRIB_BLUE_SIZE, 8,
        PP_GRAPHICS3DATTRIB_GREEN_SIZE, 8,
        PP_GRAPHICS3DATTRIB_RED_SIZE, 8,
        PP_GRAPHICS3DATTRIB_DEPTH_SIZE, 24,
        PP_GRAPHICS3DATTRIB_STENCIL_SIZE, 8,
        PP_GRAPHICS3DATTRIB_SAMPLES, 0,
        PP_GRAPHICS3DATTRIB_SAMPLE_BUFFERS, 0,
        PP_GRAPHICS3DATTRIB_WIDTH, mWindow->getWidth(),
        PP_GRAPHICS3DATTRIB_HEIGHT, mWindow->getHeight(),
        PP_GRAPHICS3DATTRIB_NONE
    };

    context_= pp::Graphics3D(instance, pp::Graphics3D(), attribs);

The attributes don't really have good documentation, it took me a very long 
time to find this solution.
I recommend to the NaCl SDK dev team to modify the tumbler sample code to my 
code - it is the starting point for 3D engines porting work and this is an 
issue that is hard to find if you just copy the code from that sample and 
assume that it is good.

=======================================

Original issue reported on code.google.com by krasin@google.com on 29 Sep 2011 at 9:43

Attachments:

• good.jpg
• bad.jpg

[GoogleCodeExporter]

Original comment by krasin@google.com on 29 Sep 2011 at 9:43

[GoogleCodeExporter]

Just to make clear what fixed it:
I changed PP_GRAPHICS3DATTRIB_ALPHA_SIZE to be 0 and added the following 
attributes:
        PP_GRAPHICS3DATTRIB_BLUE_SIZE, 8,
        PP_GRAPHICS3DATTRIB_GREEN_SIZE, 8,
        PP_GRAPHICS3DATTRIB_RED_SIZE, 8,

Original comment by assafRa...@gmail.com on 29 Sep 2011 at 9:47

[GoogleCodeExporter]

https://groups.google.com/d/msg/native-client-discuss/DQvA8VyvEKY/rljYZc4qfQgJ
Nicholas:
"
Hi Assaf, sorry for your troubles.  I believe this is due to the compositing 
going on -- after you have finished rendering into the framebuffer, it is 
composited to the page using the alpha channel of the framebuffer.  Also, I 
believe it is assuming pre-multiplied alpha when performing this blend.  As you 
have found, one way around this is to configure the framebuffer to not have 
alpha, but this might be a limit if your engine needs to use framebuffer alpha 
for other special effects.

There are a couple of other solutions that might also work for you.  First 
solution: at the end of the frame, in NaCl code before calling SwapBuffer, set 
the pixel mask to only update the alpha channel, then clear the screen using a 
clear color of (1.0f, 1.0f, 1.0f, 1.0f) -- effectively setting alpha channel in 
the framebuffer to 1.0f while leaving the other color channels unchanged.  
Second solution: you can modify your html to place a solid black rectangle 
behind the output of your NaCl / Graphics3D.  Since the blend is using 
pre-multiplied alpha, a black background should effectively make the source 
appear to be opaque, regardless of what is left in the framebuffer's alpha 
channel.  Either of these solutions should allow you to re-enable the alpha in 
the framebuffer.
"

The black background solution is a better solution I guess.

You can change the last lines of the tumbler.js file in the sample to be (add 
the style):
  contentDiv.innerHTML = '<embed id="'
                         + tumbler.Application.DomIds_.MODULE + '" '
                         + 'src=tumbler.nmf '
                         + 'type="application/x-nacl" '
                         + 'width="480" height="480" '
                         + 'style="border:0px;background: black" />'

Original comment by assafRa...@gmail.com on 29 Sep 2011 at 10:24

[GoogleCodeExporter]

Original comment by mli...@google.com on 3 Oct 2011 at 5:49

• Changed state: Accepted

[GoogleCodeExporter]

Tumbler is correct.  I think the disconnect here is understanding that the 3D 
Pepper context gets composited into the page using the compositing rules in 
effect.  Tumbler draws alpha, but clears the buffer each frame with opaque 
white.  Neither the approach in tumbler nor in Assaf's code are wrong, they are 
just different.

That begin said, I would suggest we heavily comment the attributes in the 
tumbler example (and provide some alternatives, such as Assaf's).  We should 
especially concentrate on explaining that the 3D context is composited into the 
page, and the contents of the alpha channel affect the output.

Original comment by dsprin...@chromium.org on 3 Oct 2011 at 7:36

• Changed state: WontFix