On 12/31/2011 09:03 AM, Jim Holsenback wrote:
> On 12/31/2011 08:23 AM, Cousin Ricky wrote:
>> Alain<aze### [at] qwertyorg> wrote:
>>> Effectively, if I remember correctly, the background now need a filter
>>> or transmit value to allow alpha transparency.
>>
>> Except that anti-aliasing doesn't appear to work properly.
>>
>>
> look at the bottom of this section:
>
http://wiki.povray.org/content/Documentation:Reference_Section_1.3#Anti-Aliasing_Options
>
>
> perhaps the problem you are seeing can be mitigated by specifying +AG1.0
> which effectively gives neutral behavior ... 2.5 is the default. Haven't
> tried this ... maybe for a shot ;-)

LOL ... should be "maybe worth a shot" ... still sounds funny ;-)

Post a reply to this message

Am 31.12.2011 14:23, schrieb Cousin Ricky:
> Alain<aze### [at] qwertyorg>  wrote:
>> Effectively, if I remember correctly, the background now need a filter
>> or transmit value to allow alpha transparency.
>
> Except that anti-aliasing doesn't appear to work properly.

Can you be more specific?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 31.12.2011 14:23, schrieb Cousin Ricky:
> > Except that anti-aliasing doesn't appear to work properly.
>
> Can you be more specific?

See post in povray.binaries.images.

Post a reply to this message

Am 16.01.2012 02:20, schrieb Cousin Ricky:
> clipka<ano### [at] anonymousorg>  wrote:
>> Am 31.12.2011 14:23, schrieb Cousin Ricky:
>>> Except that anti-aliasing doesn't appear to work properly.
>>
>> Can you be more specific?
>
> See post in povray.binaries.images.

Ah, yes - this actually has nothing to do with anti-aliasing, but is a 
side effect of various changes to the alpha channel handling introduced 
with 3.7.beta.38, which apparently break down in case the resulting 
transparency is exactly 1.0 (as opposed to e.g. 0.9999), and generally 
don't play nice with colored yet transparent background colors.

I guess it's back to the drawing board for me.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 16.01.2012 02:20, schrieb Cousin Ricky:
> > clipka<ano### [at] anonymousorg>  wrote:
> >> Am 31.12.2011 14:23, schrieb Cousin Ricky:
> >>> Except that anti-aliasing doesn't appear to work properly.
> >>
> >> Can you be more specific?
> >
> > See post in povray.binaries.images.
>
> Ah, yes - this actually has nothing to do with anti-aliasing, but is a
> side effect of various changes to the alpha channel handling introduced
> with 3.7.beta.38, which apparently break down in case the resulting
> transparency is exactly 1.0 (as opposed to e.g. 0.9999), and generally
> don't play nice with colored yet transparent background colors.

Workaround:

sphere
{  0, HUGE_RADIUS
   pigment { rgb BACKGROUND_COLOR }
   finish { ambient 0 diffuse 0 emission 1 }
   no_image
}

Post a reply to this message

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> sphere
> {  0, HUGE_RADIUS
>    pigment { rgb BACKGROUND_COLOR }
>    finish { ambient 0 diffuse 0 emission 1 }
>    no_image
> }

That sphere should be declared hollow.

What happened to that warning about the camera being inside a non-hollow object?
 That could have saved me days of banging my head against the wall.

Post a reply to this message

Am 16.02.2012 11:43, schrieb Cousin Ricky:
> "Cousin Ricky"<rickysttATyahooDOTcom>  wrote:
>> sphere
>> {  0, HUGE_RADIUS
>>     pigment { rgb BACKGROUND_COLOR }
>>     finish { ambient 0 diffuse 0 emission 1 }
>>     no_image
>> }
>
> That sphere should be declared hollow.
>
> What happened to that warning about the camera being inside a non-hollow object?
>   That could have saved me days of banging my head against the wall.

There's no reason to warn about such a situation. The "hollow" keyword 
only affects how the object interacts with media.

BTW, instead of a huge sphere you could just as well use a sky_sphere - 
it /should/ do exactly the same (provided you're using "#version 3.7"). 
There /is/ a difference between specifying a background and specifying a 
single-colored sky sphere.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> There's no reason to warn about such a situation. The "hollow" keyword
> only affects how the object interacts with media.

That was exactly my situation.

The warning is (was) useful.

Post a reply to this message

On 17/02/2012 6:01 PM, Cousin Ricky wrote:
> The warning is (was) useful.

I agree.

-- 
Regards
     Stephen

Post a reply to this message

Cousin Ricky wrote:
> clipka <ano### [at] anonymousorg> wrote:
>> There's no reason to warn about such a situation. The "hollow" keyword
>> only affects how the object interacts with media.
> 
> That was exactly my situation.
> 
> The warning is (was) useful.

I think the point of clipka's comment was that the old warning
also did not test whether the media container was inside a non-hollow
object (the situation creating the problem). It only warned for the
camera position (not related to the problem, although you could get
lucky if the culprit was an enclosing room or environment object).

Of course, it does beg the question whether a warning couldn't just
be printed when some media is encountered but not rendered due to the
non-hollowness (it has to be checked somewhere to have an effect?).

Post a reply to this message