Hello,
I'm trying to learn how the POV exporter for blender 2.5 is working, and tring
to "improve". I started by focusing at having the right background color and
alpha.
In my export I use blender World.horizon_color as color for povray background
{<x,x,x>}. Correct me if I'm wrong but I believe it's possible to have this
"background" coincide with the alpha layer in povray's output just like Blender
does.

During my tests I managed to make it use beta 35a but something seems to have
changed in the way PNG output files alpha and colours are handled
It could be related to this:

Change 4886 on 2009/09/09 by clipka@cli-pc-xp64

  Fix FS#55 "Output_Alpha=on doesn't work as documented"

I can't say if the change is for better or worse but anyway I sill can't make it
behave how I'd want to:

-how it was in 3.62:
The Alpha channel used to be applied but colours under it were not retrievable

-How it now is in beta 35a:
The colours of the image are preserved, but the alpha channel is no longer
reachable by blender's image buffer.

-What I'd like to achieve: Just the same behaviour as Blender native renderer,
in which the background has a colour, but still shows an alpha transparency
channel when we toggle its display.

Can someone see where I'm mistaken or if one of the two softwares should be
changed?

Post a reply to this message

I'm not sure I completely understand the behavior you want
and I don't know blender. If you wish to have color information
*and* alpha channel in the background portions you can do it
in 3.7 using a background color with transparency, e.g.

   background {color rgbt <x,y,z,0.5>}

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> I'm not sure I completely understand the behavior you want
> and I don't know blender. If you wish to have color information
> *and* alpha channel in the background portions you can do it
> in 3.7 using a background color with transparency, e.g.
>
>    background {color rgbt <x,y,z,0.5>}

Wow! exactly what I needed I hadn't tried because of a post saying it didn't
work but it was 3.6 related. This software really is adorable! And you guys are
up to it :)

This has allowed me to make my first contribution to a script, I'm so proud of
myself! even if it's probably not to be added to the official release, it will
work for me and encourages me to go further.

Post a reply to this message

Following my previous attempt, I am now trying to do the same thing with a
sky_sphere with a gradient pigment in it instead of the flat "background" (maybe
I can use a gradient with background?) Anyway, It doesn't seem to behave the
same:
when I put RGBT colors with value 1 for transmit of both colors in the colormap,
it results in a non colored background what I would want is a colored gradient
from horizon to zenith but still a flat sky matte in the alpha channel...

Here is an instance of the kind of current output I am trying:

sky_sphere {
  pigment {
    grandient z //(Blender coordinates system has Z upwards)
    color_map {
      [0.0 rgbt<0.9, 0.5, 0.8, 1>]
      [1.0 rgbt<0.3, 0.9, 0.9, 1>]
    }
  }
}

Post a reply to this message

Mr schrieb:
> Following my previous attempt, I am now trying to do the same thing with a
> sky_sphere with a gradient pigment in it instead of the flat "background" (maybe
> I can use a gradient with background?)

No, "background" is only useful for cases where you want a single color 
for the background. That's what sky_sphere is for.

> Anyway, It doesn't seem to behave the
> same:
> when I put RGBT colors with value 1 for transmit of both colors in the colormap,
> it results in a non colored background what I would want is a colored gradient
> from horizon to zenith but still a flat sky matte in the alpha channel...

Same does (or at least should) happen with "background" when you use 
RGBT colors with 1 for transmit.

Maybe what you really want to achieve needs filter instead of transmit?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Same does (or at least should) happen with "background" when you use
> RGBT colors with 1 for transmit.

Well maybe I have been using a bug of the background feature that does just what
I needed then.

> Maybe what you really want to achieve needs filter instead of transmit?

I tried and it didn't work. I'll try again. Here is the script that exports
blender's default scene with its background:
http://pastebin.fr/7175
For official Blender 2.5 alpha
it needs to be placed into .Blender/scripts/io directory, then you can chose
povray from the renderer drop down instead of blender internal.
With both render engines, the blender buffer shows a background color that can
be removed by the "draw image with alpha" (tooltip on mouse over) button.
This behaviour is what I would want with a skysphere, but it seems like it can
behave the same just for one color out of all those int the sky_sphere gradient
colormap.

Thanks for answering already.

Post a reply to this message

Mr schrieb:
> clipka <ano### [at] anonymousorg> wrote:
>> Same does (or at least should) happen with "background" when you use
>> RGBT colors with 1 for transmit.
> 
> Well maybe I have been using a bug of the background feature that does just what
> I needed then.
> 
>> Maybe what you really want to achieve needs filter instead of transmit?

I just tried it myself (using POV-Ray only - God forbid that blender 
ever finds its way onto my computer ;-)), and came to the conclusion 
that (A) transmit is indeed what you want; (B) tga output differs 
slightly under some circumstances (at least when viewed with IC; I 
suspect some pitfalls regarding gamma handling with respect to the alpha 
channel); but also that aside from these small discrepancies, (C) my 
current POV-Ray beta development version does it right (to the best of 
my knowledge it should match official beta.36 regarding output file 
alpha handling), so that (D) from my seat it appears that there's some 
issue with blender's alpha channel handling.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Mr schrieb:
> > clipka <ano### [at] anonymousorg> wrote:
> >> Same does (or at least should) happen with "background" when you use
> >> RGBT colors with 1 for transmit.
> >
> > Well maybe I have been using a bug of the background feature that does just what
> > I needed then.
> >
> >> Maybe what you really want to achieve needs filter instead of transmit?
>
> I just tried it myself (using POV-Ray only - God forbid that blender
> ever finds its way onto my computer ;-)), and came to the conclusion
> that (A) transmit is indeed what you want; (B) tga output differs
> slightly under some circumstances (at least when viewed with IC; I
> suspect some pitfalls regarding gamma handling with respect to the alpha
> channel); but also that aside from these small discrepancies, (C) my
> current POV-Ray beta development version does it right (to the best of
> my knowledge it should match official beta.36 regarding output file
> alpha handling), so that (D) from my seat it appears that there's some
> issue with blender's alpha channel handling.

I have been trying all that with PNG, not TGA
Maybe my beta version is not the same, I will try with POV 3.6 (was using
official 3.7 beta 36 till now). And if I still meet the problem, I'll try
explaining it better when I have the time and less internet connexion problems.
That time I will try to post with pictures and files.

Post a reply to this message

Here it is: to Witness the issue of the colored transparency default handling in
POVRAY 3.7 (beta 36)
render the following scene with +UA, one time with the background and another
with the sky_sphere
Depending on the output formats you render to and the application with which you
open the rendered image, here is what happens:


                                 PNG              |               TGA
____________________________________________________________________________
POVwin render window         non colored          |         non colored
under WINXP 32           transparent areas        |      transparent areas
                         with both keywords       |      with both keywords
____________________________________________________________________________
Photoshop                   non colored           |      colored background
                         transparent areas        |      but not sky_sphere
                         with both keywords       |
____________________________________________________________________________
Maya Fsheck              colored background       |      colored background
                         but not sky_sphere       |      but not sky_sphere
____________________________________________________________________________
Blender                  colored background       |      colored background
UV/image editor          but not sky_sphere       |      but not sky_sphere


So it can't be called a blender bug, but actually more of a feature, for which I
would renew a request, to make better exchange between the two softwares. The
same thing for EXR files would also be nice of course!
Thanks for reading.


camera {
  location  <0.0, 0.5, -4.0>
  direction 1.5*z
  right     x*image_width/image_height
  look_at   <0.0, 0.0,  0.0>
}
/*
sky_sphere {
  pigment {
    gradient y
    color_map {
      [0.0 rgbt <0.6,0.7,1.0,1>]
      [0.7 rgbt <0.0,0.1,0.8,1>]
    }
  }
}
*/
background { color rgbt <0.1, 0.3, 0.8, 1> }

light_source {
  <0, 0, 0>            // light's position (translated below)
  color rgb <1, 1, 1>  // light's color
  translate <-30, 30, -30>
}

// ----------------------------------------

plane {
  y, -1
  pigment { color rgb <0.7,0.5,0.3> }
}

Post a reply to this message

IIRC, POV-Ray 3.5 mishandled alpha transparency against the background
in that with antialiased edges and semi-transparent surfaces it blended
the surface's color with the background color and then saved the resulting
color with an alpha value. This caused object borders to have a pixel-wide
halo of the wrong shade, and especially semi-transparent surfaces would have
the wrong color.

  This was fixed in POV-Ray 3.6, where it's calculated correctly (iow. the
background color has no effect on the pixel colors when using +UA).

  Last time I checked (it has been some time, though), the same problem had
resurfaced in POV-Ray 3.7 beta. Someone had undone the fix in POV-Ray 3.6.

  Has this been corrected already?

-- 
                                                          - Warp

Post a reply to this message