This is day 2 of my use of POV, so I won't be startled if there's just 
something I'm missing. I'm trying to render a very simple scene - 2 objects, 
3 lights - and it works exactly as I'd expect until I turn on +UA. This is 
on Vista, 2 Intel cores, way more than enough memory.

The scene is a glass sphere floating just above a slab of marble. It's 
viewed from directly above, giving the false impression of a half-sphere 
sitting on the slab. There's a light inside the sphere, and a couple outside 
it as well. The light inside refracts the way I'd hoped, giving the 
impression of an glowing sphere.

But I want the background transparent, with the eventual goal of cutting 
away at the slab's corners and having a non-rectangular object to use in 
openGL code. So I specify
+A +Q11 Output_File_Type=N  +UA

What I get is a jet black circle where the sphere was. When I display the 
.png file in other tools, I get my slab of marble with a circular hole cut 
through it. I've tried Output_File_Type=S  +UA in the vague hope of some 
sort of nonstandard .bmp file working out, and that's not better.

If I'm doing this wrong, what's the right way? Suggestions very welcome, 
thanks.


// +A +Q11 Output_File_Type=N with  +UA added,  makes the sphere act 
unexpectedly. -UA is fine.
#include "colors.inc"
#include "textures.inc"
#include "shapes.inc"
//#include "metals.inc"
#include "glass.inc"
#include "stones.inc"

global_settings {max_trace_level 12}

//look down
camera {
   location <0,0,3>
   look_at <0,0,0>
}

//stolen from samples
#declare Dist=80.0;
light_source {< 50, 25, 50> color White
     fade_distance Dist fade_power 2
   area_light <-40, 0, -40>, <40, 0, 40>, 3, 3
   adaptive 1
   jitter
}
light_source {< 50, 10,  4> color White
     fade_distance Dist fade_power 2
   area_light <-40, 0, -40>, <40, 0, 40>, 3, 3
   adaptive 1
   jitter
}

/*
sky_sphere {
    pigment {
        gradient y
        color_map {
            [0, 1  color White color White]
        }
    }
}
*/

//darkish marble
#declare T_StoneA =
texture{T_Grnt15 scale <.5, .5, .5> rotate <0, 0, -30>
        finish{ambient 0.3 diffuse 0.6  crand 0.003}
}
texture{
pigment {
 granite
  turbulence 0.05
  color_map
   {[0.0, 0.3 color White color DimGray]
    [0.3, 0.4 color DimGray color DimGray]
    [0.4, 0.6 color DimGray color Black]
    [0.6, 1.0 color DimGray color DimGrey]
   }
 }
 finish {
  crand 0.02 diffuse 0.5 phong .7}
}

//glass ball with dispersion, over slab of rock
union {
        box {<-0.5, -0.5 ,0>, <0.5, 0.5, 0.25> texture {T_StoneA} }
        sphere {<0,0,0.501>, 0.25 texture {T_Glass1} 
interior{I_Glass_Dispersion1} }
}

//light the sphere from within
light_source {< 0, 0,  0.333> color <255/255, 255/255,248/255> }

Post a reply to this message

Am 28.02.2011 03:32, schrieb Scott M:

> If I'm doing this wrong, what's the right way? Suggestions very welcome,
> thanks.

With the scene and settings you specified, I can't confirm that 
behaviour for POV-Ray 3.6.2: No jet black sphere in the preview, and no 
"hole" in the output PNG. Everything looks like I guess it should: +UA 
and -UA preview & output look virtually identical, except that with +UA 
the slab is surrounded by transparency rather than blackness.

Are you sure that's exactly the code & settings you tried with?

Exactly what version of POV-Ray are you using?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 28.02.2011 03:32, schrieb Scott M:
>
> > If I'm doing this wrong, what's the right way? Suggestions very welcome,
> > thanks.
>
> With the scene and settings you specified, I can't confirm that
> behaviour for POV-Ray 3.6.2: No jet black sphere in the preview, and no
> "hole" in the output PNG. Everything looks like I guess it should: +UA
> and -UA preview & output look virtually identical, except that with +UA
> the slab is surrounded by transparency rather than blackness.
>
> Are you sure that's exactly the code & settings you tried with?
>
> Exactly what version of POV-Ray are you using?

clipka <ano### [at] anonymousorg> wrote:
> Am 28.02.2011 03:32, schrieb Scott M:
>
> > If I'm doing this wrong, what's the right way? Suggestions very welcome,
> > thanks.

> Are you sure that's exactly the code & settings you tried with?
>
> Exactly what version of POV-Ray are you using?

3.6.2.msvc9-sse2.win32. The platform is Vista Home Premium SP2, Intel Core(2)
T7200 @2Ghz, 2 Gig memory.

The settings are 512x384, no AA and +A +Q11 Output_File_Type=N  +UA

I pasted the script from the bug report back into POV and re-ran. This time it
broke differently, and I've posted a screen shot to

http://ikrast.game-host.org/Badness.jpg

This time, instead of an all-black sphere, I get random black bands across the
display window where the sphere is. (In Window's photo viewer they are
transparent, not black.)

I ran it again, simply by clicking Run, and it came up as an all black sphere
that time.

I moved the sphere to <0,0,1> and ran, and got 4 black bands across the sphere.

I moved the sphere to <0,0,2> and ran, and the sphere occludes the box and is
consistently all black.

At <0,0,0.4>, which overlaps the box and sphere a little, I ran a bunch of
times. I got either 1 or 2 black bands (when 1, it was usually near the equator)
the first ten or so times, and then it started rendering as all black, and
stayed that way consistently thereafter. Figuring memory corruption, I exited
POV and restarted it by double-clicking on the script, and rendered. This time
it rendered closer to what I'd expect, except the "transparency checkerboard"
was visible on the sphere in the preview window (maybe that's an expected
refraction effect?) and there are *chunks* missing from the sphere. That image
is at:

http://ikrast.game-host.org/experiment.png

The out of the box scenes, biscuit and woodbox, transform without a hitch. The
laptop's in a cool room and I don't think I'm having overheat or stability
problems.

Scott

Post a reply to this message

Am 28.02.2011 13:34, schrieb Scott M:

> I pasted the script from the bug report back into POV and re-ran. This time it
> broke differently, and I've posted a screen shot to
>
> http://ikrast.game-host.org/Badness.jpg
>
> This time, instead of an all-black sphere, I get random black bands across the
> display window where the sphere is. (In Window's photo viewer they are
> transparent, not black.)

Weird. Looks like /something/ related to transparency isn't properly 
initialized.

I'm not a POV-Ray 3.6 expert though - all I do is 3.7.

Maybe you want to go for the current 3.7.0 release candidate instead. 
Faster (supporting multi-core CPUs), better, nicer, and I did some work 
on the alpha handling there myself, so if there happens to be something 
wrong as well, I'm right here to take the blame :-)

3.7.0 release proper is just a few weeks ahead, so if you're new into 
POV-Ray anyway, I suggest to skip 3.6.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> Maybe you want to go for the current 3.7.0 release candidate instead.
> Faster (supporting multi-core CPUs), better, nicer, and I did some work
> on the alpha handling there myself, so if there happens to be something
> wrong as well, I'm right here to take the blame :-)

Ah, then you're the man to ask about this, as well. POV is letting me specify
Output_File_Type=S  +UA
which on Windows should be giving me a 32 bit deep .bmp file with 8 bits of
alpha. Microsoft has apparently been iffy about formally supporting all the
possible variants of transparency in a .bmp file, but this form at least should
be solid.

But when I specify S +UA, and render, the preview window shows the transparency
checkboard, but the actual .bmp is being written 24 bits deep, which I'm pretty
certain means there's no possible way the .bmp file has any alpha in it.

Am I missing something? The messages window is promising

Output Options
  Image resolution 512 by 384 (rows 1 to 384, columns 1 to 512).
  Output file: C:\Users\Scott\Documents\POV-Ray\v3.6\scenes\experiment.bmp, 32
bpp with alpha (system format)

But the generated .bmp is very definitely 24 bits deep with a "compression"
format of BI_RGB and a header size of 40 bytes, which means the data word that
describes the alpha width isn't even available.

I really, really need .bmps with transparency. I'll try my luck with 3.7

Post a reply to this message

"Scott M" <nomail@nomail> wrote:

> I really, really need .bmps with transparency. I'll try my luck with 3.7

OK, 3.7 installed. Much good news, some bad news.

No more corruption of my images with mysterious black bands. Goodness reigns.

The .bmp file reports a color depth of 32 bits when I specify S +UA. More
goodness.

But it's not a proper .bmp, at least according to the sources at
http://en.wikipedia.org/wiki/BMP_file_format

To contain transparency, you are supposed to move up to the 108 byte header, and
specify the masks for red, green, blue and alpha. Without those masks, there's
no way to tell which bits represent which colors. I'm willing to bet there's
code out there that assumes it must be 8.8.8.8.0 if there's no masks present, so
probably many tools will work with these .bmps anyway, but that doesn't make it
right.


Still.. I can work with this. Many thanks.

Post a reply to this message

Am 01.03.2011 06:14, schrieb Scott M:

> No more corruption of my images with mysterious black bands. Goodness reigns.

Good to know. So whatever it was, I must have fixed it ;-)


> But it's not a proper .bmp, at least according to the sources at
> http://en.wikipedia.org/wiki/BMP_file_format
>
> To contain transparency, you are supposed to move up to the 108 byte header, and
> specify the masks for red, green, blue and alpha. Without those masks, there's
> no way to tell which bits represent which colors. I'm willing to bet there's
> code out there that assumes it must be 8.8.8.8.0 if there's no masks present, so
> probably many tools will work with these .bmps anyway, but that doesn't make it
> right.

You live and learn - I didn't even know that there /is/ some official 
way of supporting an alpha channel with bmp. I was always convinced it 
was a hack format that makes use of the padding byte of the 
pad-to-32-bit variant of BMP (Well, in the case of POV-Ray it apparently 
is).

Thanks for the pointer, I'll keep that in mind when I re-visit file output.

Post a reply to this message

Am 02.03.2011 01:19, schrieb clipka:
> You live and learn - I didn't even know that there /is/ some official
> way of supporting an alpha channel with bmp. I was always convinced it
> was a hack format that makes use of the padding byte of the
> pad-to-32-bit variant of BMP (Well, in the case of POV-Ray it apparently
> is).
>

Note that BMP files with a BitmapV4Header

http://msdn.microsoft.com/en-us/library/dd183380%28v=vs.85%29.aspx

(or its successor BitmapV5Header) are not recognized as such (and 
usually are rejected with a "not a valid BMP file" error) by most 
applications even within the Windows world - at least this was true two 
years ago when I myself would have preferred to write a V4-header as it 
also supports gamma information.
IIRC even Windows XP SP2 build-in-viewer did not handle it.

-Ive

Post a reply to this message