Hi Guys,

I'm trying to re-make an old scene with a transparent background and 
after trying different things, I realised that I was not getting the 
same output depending on the use of the +ua option or not. I attached a 
minimal scene with the two images.

Do you get the same ? Is it the expected behaviour ? And if so, what is 
the explanation please ?


Nico


// povray +Iscene.pov +fn      +oscene.png
// povray +Iscene.pov +fn +ua  +oscene-ua.png

camera {
   location  <0,0,-3>
   look_at  0
   direction 1.5*z
   right     x*image_width/image_height
}

#macro Glow(Color)
   media {
     emission 1
     density {
       spherical
       poly_wave 5
       density_map {
         [0 rgb 0]
         [1 rgb Color]
       }
     }
     method 3
   }
#end


box {-10, 10 hollow}

sphere {
   0, 1
   hollow on
   pigment {rgbt 1}
   interior {Glow(<1.0, 0.1, 0.2>*44)}
}

Post a reply to this message

Attachments:
Download 'scene.png' (18 KB) Download 'scene-ua.png' (18 KB)

Preview of image 'scene.png'

Preview of image 'scene-ua.png'

> Do you get the same ? Is it the expected behaviour ? And if so, what is
> the explanation please ?


This is probably the same problem that I was having in the thread "alpha
output color problem" on 1/1/05, and that Zeger Knaepen mentioned in the
thead "possible bug?" on 11/28/04.

In short, the developers haven't commented on the issue yet (so there's no
news on whether it's a bug or intended behavior, hopefully the former). But
version 3.5 didn't have this problem, so if you're not depending on any of
the changes in version 3.6, then you can use version 3.5 for your
alpha-output images.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Ok, thanks, I will use version 3.5 then.

What is weird though with version 3.6 is when you add a dummy radiosity 
block like:

global_settings {
   radiosity {
	pretrace_start 0.08
	pretrace_start 0.01
   }
}

You can clearly see that the image is ok during pretrace but then, the 
final trace goes wrong.


Nico

Slime wrote:
>>Do you get the same ? Is it the expected behaviour ? And if so, what is
>>the explanation please ?
> 
> 
> 
> This is probably the same problem that I was having in the thread "alpha
> output color problem" on 1/1/05, and that Zeger Knaepen mentioned in the
> thead "possible bug?" on 11/28/04.
> 
> In short, the developers haven't commented on the issue yet (so there's no
> news on whether it's a bug or intended behavior, hopefully the former). But
> version 3.5 didn't have this problem, so if you're not depending on any of
> the changes in version 3.6, then you can use version 3.5 for your
> alpha-output images.
> 
>  - Slime
>  [ http://www.slimeland.com/ ]
> 
>

Post a reply to this message

"Nicolas Rougier" <rou### [at] loriafr> wrote in message
news:41e4e85a$1@news.povray.org...
>
> Ok, thanks, I will use version 3.5 then.
>
> What is weird though with version 3.6 is when you add a dummy radiosity
> block like:
>
> global_settings {
>    radiosity {
> pretrace_start 0.08
> pretrace_start 0.01
>    }
> }
>
> You can clearly see that the image is ok during pretrace but then, the
> final trace goes wrong.

you don't need radiosity for that, just adding +sp8 +ep4 to your ini will show
you the same thing :)

cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)               // ZK http://www.povplace.be.tf

Post a reply to this message

Among other things, Slime saw fit to write:

> But version 3.5 didn't have this problem, so if you're not depending on
> any of the changes in version 3.6, then you can use version 3.5 for your
> alpha-output images.

If the alpha channel is OK, you could render twice (once with +ua and once
without) and use the alpha channel of the "transparent" picture for the
"opaque" one.

-- 
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby

Post a reply to this message

But I will get aliasing problem depending on the background, no ?

Nicolas


Jellby wrote:
> Among other things, Slime saw fit to write:
> 
> 
>>But version 3.5 didn't have this problem, so if you're not depending on
>>any of the changes in version 3.6, then you can use version 3.5 for your
>>alpha-output images.
> 
> 
> If the alpha channel is OK, you could render twice (once with +ua and once
> without) and use the alpha channel of the "transparent" picture for the
> "opaque" one.
> 
w

Post a reply to this message

Nicolas Rougier wrote:
> But I will get aliasing problem depending on the background, no ?

Yes.

When the alpha channel is turned on, the rgb values are divided with the 
alpha value, such that when the rgb values are later multiplied with the 
alpha value in an image viewer it will balance out.

If the dividing step is not done, you will get traces of the background 
color at the edges of antialiased objects, and the background color will 
also be visible behind all semi-transparent surfaces.

Rune
-- 
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message